NULLを示すビットパターン

C

大体アドレス0に意味のあるデータ(割り込みベクタ)があったのにNULLが0だったPC-98時代の時点で既に、NULLが特別視される必然性も何も無い単なる約束事というのは当たり前だった気もするのですが……。
ポインタにNULLが、floatにNaNがあるなら、intにだって無効値があっていいはずで、たとえば0x8000(16bit) = -32768は、同じ型には対応する正の値が入らないため無効値候補と思うんですが、そうはなっていない。単にビット演算の方が重視されたためかなーと。
別に、not nullだのNullableだのD言語の暗黙の初期値だのそんな話をしたいのではなくて、そもそもポインタの特定のビットパターンを無効値とすることに疑問があるわけですよ。例えばintならbool validxxx;だのbool xxxable;を添えておかないといけないケースがポインタだと……ってのはNullableか。
例えば、C言語では配列要素へのポインタは、1要素先のアドレスまで有効ということになっていますが、これと0x0000がNULLというのを組み合わせると、必然的に0xffff(マイナスsizeof(使用する最大のstruct))も使えなくなります。少なくとも配列変数を割り当てることができなくなります。どっかで全メモリアクセスできる型のつもりでtypedef unsigned char (*x)[1 << (sizeof(void *) * 8)];なんて宣言されたらもう使えるアドレスがなくなってしまいますそれ以前にシフト量が整数型のビット数以上なのでこのシフト演算は無効ですgdgd
何が言いたいかといいますとNULLってのはいろいろ崩壊している約束事ですので深く考えるだけ無駄じゃないかとかそういう。

比較とかそういう

C

unsignedとsignedの比較は、どっちに合わせられるのが規格上正しいんでしょうか。
両方ともをよりビット幅の大きい型に直してから比較するのは勿体無いので無しとしても、unsigned_var > -1がunsigned_var > 0xffffになったりするのは悪夢ですのでsignedで比較する方が安全と思うのですが、unsignedでの比較になるコンパイラもあるんですよねぇ。
勿論、警告出してくれたら一番嬉しいのですけど。
なにやらgccでもunsignedの比較になるのが怖いんですけど。
C++Builderでも警告は出たものの結果は符号無しの比較に……そういう規格なのか！？

似非スマートリンク、あるいはHello Worldのビルド時間世界一への挑戦

gcc

皆さんご存知の通り、ldは、ELFフォーマットでしかスマートリンクのための--gc-sectionsが動いてくれません。WindowsはCOFF/PEですのでとても悲しいです。
そこで、FreePascalのスマートリンクの方法が使えます。.section毎に別々の.oにするだけです。力技です。
個々のグローバルシンボルを別々の.sectionに分けるのは、gccのオプション-ffunction-sectionsと-fdata-sectionsでいけます。
後は.oを細切れにするだけですが……最初、objdump -hして得たセクション名ごとにobjcopy -jでバラせると思ったのですが、そうして.exeまで持っていっても動きませんでした。ひとつの.o内で相互参照していたローカルシンボルが、指すところが無くなったためか自身を指していて、コードを書き換えようとして落ちてました。
というわけで力技に力技をもうひとつ重ねます。
gccに-Sで吐かせたアセンブリソースを、.sectionを目印に切っていって、各シンボルについて.global宣言も付加します。ローカルシンボルも、元ファイル名からハッシュ付けて無理やり公開します。
そうやって分割した.oを全部コマンドラインで渡そうとすると実行できませんでしたのでarでまとめてranlib。色々調整して結局こんな感じで。
こうして……Hello Worldが、82,432バイトから59,904バイト(現行の4.1.1無修正)、または、85,504バイトから60,416バイト(4.3.0＆改造RTL)になりました。結構効くなあ。びっくりです。コンパイルオプションも若干違うんですけどね。ビルド所要時間は約15分です。
約15分では甘すぎる気がする。RISCに向けてランタイム含めて広域最適化するとかそんな条件ならもっと時間かかるのありそう。でもまあ時間対効果比なら世界一かもしれん。
いずれにしろやってられねーので、勝手に同じことをしてくれるスーパーasください。ついでにリードオンリーのセクション同士で内容が被っていればまとめてくれるようなスーパーなやつ。

……。
ツール自体も288256→223232と劇的だなあ……。
これはこれでありな気がしてきた……。

追記
時間については、俺の改造RTLがバカやってただけだった。