気持ち悪いので調べてはおきたいが後にしとこ、と思ったこと。

Python が size_t ではなく ssize_t を使うようになった、という説明のくだりで

という表現がされていて、ちょっと違和感があって。

C89, C90 までの定義は確か「char は最低でも 8 bit、short は少なくともこれ以上、int は少なくともこれ以上、long が少なくともこれ以上」というもので、ほとんど(というより現存するほとんど全て)の 32 bit プラットフォームでは「char は 8 bit、short は 16 bit、int は 32 bit、long は 32bit」であったと。ここまではいい。そしてワタシの理解は「64 bit プラットフォームでは char は 8 bit、short は 16 bit、int は 32 bit、long は 32bit (のまま) で、多くは代わりのベンダ依存 long long (や __int64 など)で 64 bit、「だった」」。

だから「long int が 32bit のままで」という表現ならまだしも、「int が 32bit のままで」はなんか誤解してやしないか、と。それとここでの議論は「size_t って実態はなんだったの?」にスコープされるべきであって、その点もちょっと論点がズレてる気がする。これも理解がアヤフヤで、確か…「size_t は C 言語規格範疇になくベンダ依存だったが標準的には int、「だった」が、long に「なってきた」」とかだったか? C++ も絡んで「ポインタのオフセット」をストレートに表現出来るように変わっていった(ptrdiff_t とかだっけ?)とかそんなだった記憶もある。

古い知識も結構いい加減な理解なんだけれど、一番わかんなくなったのが C99 との関係。「fixed size」が欲しければ stdint.h (C++ からは cstdint) を使いなはれ、はいい。では元となる int や long は C99 ではどうなった?

くだんの引用部分は Python 2.5 での話で、これは 2006 年 8 月頃の話である。CPython は今でも C99 を採用してないとはいえ、当時既に C99 コンパイラはまぁまぁ使えたし、少なくともプログラマの理解もそれなりに進んでいたはず。だからそれへの言及がないのもやや気になる。

てなわけでわかんなくなったことばっかりなんだけど、調査は保留。これ真面目にやるとなると規格書熟読しないといけないし、「各コンパイラ・ベンダのそれへの準拠度」も調べないといけないしでかなり鬱陶しいが、「些細でどうでもいい」ことでもあるので。(どうでもいいというのは最近では普通は「fixed size がお望みなら stdint.h 使うべし、で理解としては十分だから。)

まぁ気が向いたら調べよう。(気が向かない可能性大。)