What goes on/what's going on:2021年04月06日分

2021/04/06(Tue)

[プログラミング厳語C] intwidest_t

kbkさんのしばらく前に復活した 雑記帳より、ワイの 先日の記事と同時発生的にUTF-8のBOMネタがフェイク技術情報発生源ことQiiiiiiiiiiiiiiitaの記事を発端にhateブや火ウイッヒ-で発生してたことを知るなど。

ワイはQiiiiiiiiiiiiiiitaもhateブも火ウイッヒ-も基本視界からシャットアウトしてるので空飛ぶスパゲッティモンスターに誓って完全に偶然なのだけども、怖いもの見たさで検索かけたらいまだにBOMは有益的な論説があってガチで進撃の復権派の「うおおおおおおおおおお!」じゃねーかと思いましたまる。

前回UTF-8Nに触れた記事は 2006年あたりまで遡るのだが、もはや復権派が何やらかしたのか覚えてねえな…

その副作用により某方面のアレな四月莫迦commitネタを知り、さぞかし寒い反応だろうなとsource-changes(某の意味がない)を何年かぶりに開いたら、滝沢先生でもないのにlint(1)の修正をしているdeveloperの方がいて、こっちの方が四月莫迦commitじゃないのかとすら思った(おい)。

以前 debugging lint(1)という記事でも書いたように、gccやclangなどのコンパイラがlint(1)より懇切丁寧に文法チェックをしてくれる時代で、LINTコマンドとコンパイラの属性情報(__attribute__とか)の両方を併記するのもめんどいわけで、OもFもとっくの昔にビルドプロセスからlint(1)による文法チェック(ただしコメントアウトだらけ)にはご退場いただいてるのになといいう感想なのだが、まぁC90から30年進歩が止まってるlint(1)がもうじき登場するであろうC2Xにも対応して

#if defined(__lint__)
...
#end

という世にもおぞましいkludgeが消えてくれるならまぁいいか(たぶんその日は来ない)。

ところでワイがかろうじて動向を追ってたC11(まだC1Xと呼ばれてた)の段階(えぇ…もう10年前なの…)で、FALLTHROUGHやNORETURNあたりに相当する機能を言語仕様に入れよう的な話があったと記憶してるのだが(ペーパー番号までは失念)、C2Xどうなってんだろうな。 ちょっと前にのぞいた時はintmax_tのABI互換性とかいう、libc開発者なら20年前には気づいてないとならない今更そこ問題にするの莫迦なのという話題で延々と無限ループしてたようだが。だいたいお前らABIに関知する場じゃねえだろと。

そんでワイはもうintN_t増やすごとにlong long long long long long long long long intとかintmaxmaxmaxmaxmaxmaxmaxmaxmaxmaxmax_tとか増やせとジョークをいってたのだが、マジモンの提案でintwidest_t導入しようぜ( N2465)とかいってて俺は限界だと思った。

そもそもintmax_tで騒ぐなら32it time_tの2038年問題対応の時に騒いでおけ、intmax_tなんてtime_tよかよっぽどインパクト小さいはずやで。

基本的にlibcのsonameを変更しろって話だし、それを回避したいならstrtoimax/strtoumaxあたりをELF symverなりNなら__RENAMEマクロで変名処理すりゃいいだけだし、あとは古いintmax_tを使うライブラリと新しいintmax_tを使うライブラリをチャンポンで使わなきゃ問題ないはずなのだが。

いやたぶんチャンポンで使おうと虫のいいこと考えてるからこの騒動なんだろうなぁ、libcのsoname変更なんてO方面みたいに毎日やってもいい文化もあるというのに。