macです。 Junsuke Kunugiza さん<jk@xxxxxxx> wrote: > int8_t uint8_t > int16_t uint16_t > int32_t uint32_t > > 一応，C99 標準だったかな。sys/types.h あたりで，すでに定義 > されていることが多いみたいですね。 ええ、でもその「多い」と言うのが曲者で、 ない場合はどうするかですね。 math.hにしても、 M_PIがあるか、ないかとか… まあ、#defineで定義されているものは、 #ifndef M_PI #define M_PI 3.14159265358979323846 #endif で、すむでしょうが、typedefで、 定義されていると厄介です。 かえって、「標準で定義してない識別子」を使い、 コンパイラごとに、その識別子を定義するheaderを、 取り替えたほうが、移植性には有利じゃないでしょうか？ その他、libに必要なものがあるかとか、 endianはどうなっているかとか… そのために、Configureで実際試してみる方法が、 Unix系のFree softに多いのですが、 組み込み用でそこまでやるのは、 やりすぎと言うか、その問題が解決して、 コンパイルできるようになったからと言っても、 ハードウエア上の問題がからみ、 素直に移植完了と言うわけにはなかなか… うる覚えなのですが、FORTRANでは、 REAL, INTEGERを同じ長さにするという、 規格があった時代があり、でも多くのマシンでは、 16 bitの整数演算ALUしか用意されてなく、 記憶域を浪費しないよう、かつ規格に反しないよう、 defaultでは、同じ長さにしておき、 // ONE WORD INTEGERS とJCLで呪文を唱える必要があったりしたと、 思うのですが… # MVSのこと、まだ覚えていらっしゃる方、 # 違っているようでしたら訂正お願いします。 言語仕様で、タイトに変数タイプの、 長さを定義してしまうと、 こんなことになると言う「反省」を、 活かした結果、Cでは、実装に任して、 言語仕様で縛らないことにしたら、 今度は移植性に問題を作ってしまった… まあ、そのころに、大抵の家電までCPUが入り、 そのプログラミングにCが使われるようになると、 予想するのは、K&Rでも無理だったのでしょうね。 -- mac
