Not only is the Internet dead, it's starting to smell really bad.:2018年10月25日分

2018/10/25(Thu)

[プログラミング幻語C] intmax_tはいうほどクソか?

open-std.orgのintmax_tの話、そもそもintN_tと混同してABI安全な型だと勘違いしてたのが間違いに気づいて逆ギレして騒いでるだけなんじゃねかなこれ。 ちゃんとlibcの実装に関わったことのある開発者ならいまさらこんなこといいだすはずがないと思いたいんですけどねぇ…

そもそもこれってtime_tを32→64bitに変更するような部類のものでlibcのsoname変更は当然という認識がlibc開発者には元よりあったはず、無いならちょっと不勉強すぎてだな… つかABI破壊なんてlibc開発者にはチャメシインシデントで、OpenBSDなんかリリース出るたびにABI破壊しとったぞ、Nとかglibcは__RENAMEとかsymverで可能な限り回避はしておるけど。

この話って元々はint128_tを追加したい→intnmax_tのABI変わるで→ワーワーギャーギャーという流れなんだろうけど、そもそもgccの__int128とか使ってる人いるんですかねアレ、SSEなら自前の__m128あるしな。 焼いたクッキーの枚数を数えるのに欲しいとかならJavaのBigIntegerみたいなもの実装するほうがいいだろうし。

そんでこの話はABI壊れるなんて話よりintN_tはそもそもプリミティブ型ではないのでそれぞれ対応するプリミティブ型のtypedefとして実装する必要があるってところの方が重要よな。

まず最初に思いつくであろうアイデアとしてはlong long intを128bit化してしまえなんだけど、生憎IPL32な環境においてはlong intは32bitだからlong long intを64→128bitに変更するとint64_tに対応するプリミティブ型がシステム上に存在しなくなってしまう。 そこを無理矢理にIPL32環境はレガシーと切り捨てて(無理やろうけどな)、LP64環境だけでええんや!と主張したとしても今度はsizeof(long long int)が4から8になることでABIが崩れるだけでなくマナーの悪いソースが動かなくなる。

となると新たにlong long long int型 *1を追加するしかない、まぁstrtolll/llldiv/lllabsといった新規関数の追加とprintfのフォーマット指定子に"lll"を追加せんとならんけど、intmax_t関連以外にABIへの影響は無いしソース互換はバッチリなのよな。

ただここでひとつ問題があって、C99あたりからの傾向だけども型は追加するのはOKだけど、その型を扱うためのAPIを増やすのは嫌がられるという傾向があるのよね。 なのでintN_tの導入時にstrtoiN/iNdiv/iNabsは実装されなかったし *2、char16/32_t導入時に至っては本来はwchar_tの為のAPI(isw*とか)を乗っ取ろうとするムーブまであった。

とはいえ必要になるならしゃーないので戦力の逐次投入は負け戦だし一気にドーンと

typedef long long long int				int128_t;
typedef long long long long int				int256_t;
typedef long long long long long int			int512_t;
typedef long long long long long long int		int1024_t;
typedef long long long long long long long int		int2048_t;
typedef long long long long long long long long int	int4096_t;

くらいは追加しておけばいいんじゃないですかね(マジキチスマイル)、strto*/*abs/*divについてはC99 tgmath.hの尻拭いに導入されたC11の_Generic(Generic Selection)みたいな紛い物ではない、本物のジェネリックプログラミングをCに導入をだな…

ネタはおいといて、いっそのことintN_tの方をプリミティブ型にしてint/long int/long long int/の方をtypedefにしてしまう方がいろいろスッキリするのだけども、そうするとこいつらの実装が難しい36bitワードみたいな変態アーキテクチャ(今となっては)の立場が無いのよな。 おいおいNですら諦めたPDP-10みたいな過去の亡霊どうでもええやろ…とお思いでしょうが、UNISYS社の現役メインフレームの Cコンパイラのマニュアルの4-11ページの4.5. Size and Range of C VariablesにあるTable 4-6. Summary of the Size and Range of Data Typesの表をみると、まだ36bitワード現役なのですわ。 やはり UTF-9/UTF-18は決してエイプリルフールのジョークではない(マジキチスマイル)。

*1:電磁ナイフのドグ「3回もlongって言いやがった!」
*2:そもそもstrtoiすら無いので未だにatoiが使われてしまうのもアレだよな…