「VC++10 のcstdintはバグっている」にたいするツッコミ

VC++10 の＜stdint.h＞, ＜cstdint＞はバグっている (2) - 危ないRiSKのブログ

C99規格より、

INT_FASTN_MIN    −(2N−1 − 1)
INT_FASTN_MAX    2N−1 − 1

とすれば、INT_FAST16_MINは、int_fast16_tの実際のビット数にかかわらず、-(2^16-1 -1)に置き換わるべきであるし、INT_FAST16_MAXは、2^16-1 -1に置き換わるべきである。

int_fast16_tの具体的な型がなんであるかは、規定されていない。int_fast16_tがintのtypedefであったとしても、全く問題はない。現時点で、MSVC10の実装では、intになっている。

VC++10 の＜stdint.h＞, ＜cstdint＞はバグっている (4) - 危ないRiSKのブログ

何も指定せず、普通に関数のオーバーロードをしているので、もちろんこれはC++のコードである。

ところで、先程も述べたのと同じ理由で、int_least8_tがintであったとしても、何の問題もない。重要なのは、intが8ビット以上あるかどうかだ。intが32bitの環境では、以下の実装は、well-formedである。

namespace std {
typedef int int_least8_t ;
typedef int int_least16_t ;
typedef int int_least32_t ;
}

つまり、std::is_same<int_least8_t, int_least16_t>::valueがfalseである保証はない。

以上の理由で、int_leastN_tで関数をオーバーロードするのは、規格上、おそらくは、undefined behaviorもしくは、unspecified behaviorになると思われる。上記のような実装の場合、オーバーロードすると、結局、どの型もintに過ぎないので、コンパイルエラーとなる。これは、規格が上記のような実装を認めている以上、コンパイラの責任ではない。

ただし、VCの実装では、int_least8_tはsigned charで、int_least32_tは、intなので、INTN_Cの挙動はおかしいと言える。しかし、そもそもcstdintで定義されているtypedefが、違う型である保証はない。とすれば、どうなったところで、文句はいえまい。

そもそもが鼻から悪魔を召喚するコードなのだから、どうなったところで、実装の責任ではないだろう。

なお、UINTN_Cが一部、signed型になるのは、これは仕方が無いのではあるまいか。もし、キャストすると、#ifで使えなくなる。そして、C99規格は、#ifで使えることを要求している。とすれば、何が出来るというのか。実装の問題ではなく、規格の問題である。

ちなみに、これは明らかに、規格の問題なのだが、どうせ劣ったC言語では、特に問題にならない。なぜなら、C99には、関数のオーバーロードはないし、autoもdecltypeもない。実際に違った型であったとして、Cからどうやって利用するというのか。Cの型システムはC++よりはるかに劣っているので、C++のような厳格な型システムを期待するのは無理である。

第一、プリプロセッサを用いている時点で、C規格が根本的に救いようのない劣った言語であることは間違いがない。C言語の規格がクソなのに、実装に文句を言っても仕方がない。