sizeof(long), sizeof(short) （処理系依存と言うけれど・・・）

　
数値（整数）型の定義サイズについて、質問です。

ANSIの規格では、

sizeof(short) ≦ sizeof(int) ≦ sizeof(long)

としか定義されていないので、実際にこれらの型が取る大きさは処理系依存だ、と聞きます。
しかし、VC++、BCCなど、知名度の高いコンパイラでは、いずれも、

sizeof(short) → 2
sizeof(int) → 2
sizeof(long) → 4

となっているようです。（手元にないので、gccでは確認していませんが・・・）
実際のところ、上記のサイズにならない処理系は実在するのでしょうか？

何故こんな質問をするのかというと、あるテキスト（事情があって、書名等の情報は出せないのですが）に

> 次の sizeof 演算子の返す値として正しいものはどれですか。
>
> long hoge[32];
> sizeof(hoge);
> ------------------------------------------------------
> A. 32
> B. 64
> C. 128
> D. 256
> E. 512

という問題が掲載されており、解説が、

> 正解は C 。
>
> long 型は 4 バイトで構成されるので、32 個の要素がある配列では、 128 バイトになります。

となっていたのです。（short型のサイズを問う類題あり）
特定の処理系が前提条件とされていないので、適切な設問、解説とは思えないのですが、誤りと断言できるほどの自信がないため、作者に指摘すべきか否か、迷っています。
sizeof(short) → 2、sizeof(long) → 4 にならない処理系が実在しなければ、規格の定義上は正しくなくても、実務上は誤りとは言えないような気もしますが、どうでしょうか？
コメントをお待ちしております。
　

No.1 ベストアンサー 回答者： hiroyapapa 回答日時： 2003/08/24 21:56

64ビットマシン向けの商用UNIXのほとんどでは、

sizeof(long)は 8
となっているはずです。(LP64モデルを採用)

ちなみに、
Win64では 4 のままです。(LLP64モデルを採用)

さらに重箱の隅をつつくようで申し訳ないですが、IA32向けのVC++や、BCCでは、sizeof(int)は 2 ではなく 4 を返しますね。ご確認を。

参考まで。

この回答へのお礼

コメントありがとうございます。

> 64ビットマシン向けの商用UNIXのほとんどでは、
> sizeof(long)は 8
> となっているはずです。(LP64モデルを採用)

ということは、

> 規格の定義上は正しくなくても、実務上は誤りとは言えないような気もします

はとんでもない話で、この内容では、テキスト（教材）としての品質に大いに問題がありそうですね。
クレーム（修正要求）を付けた方がいいかな？


> IA32向けのVC++や、BCCでは、sizeof(int)は 2 ではなく 4 を返します

おっしゃる通りです。
ご指摘ありがとうございます。
　

お礼日時：2003/08/24 22:25

No.4 回答者： ryuta_mo 回答日時： 2003/08/25 07:59

学校で

char=1Byte
int=2Byte
long=4Byte
short型なんて一言も触れないと言う授業やってます。
int型は大体ＣＰＵの通常の整数演算の型に合わせることが多いです。
ＶＣ++6で確認したら
sizeof(char)=1
sizeof(short)=2
sizeof(int)=4
sizeof(long)=4
sizeof(hoge)=128
という結果が出ました。
Windows９５以降は３２ＢｉｔＣＰＵです。
質問にはint=2と書いてありますがそうではないようです。

char,short,longが1,2,4Byteでない処理系は聞いたことありませんが（下の回答見てるとあるようですが）intは昔は２Ｂｙｔｅ今は４Ｂｙｔｅが多いようです。
学校で使われてる教科書はint=-32768～32767なんて書いてあるから２Ｂｙｔｅでしょう。
しかも処理系によって換わるなんて一言も書いてありません。
Ｃ言語のint型は２Ｂｙｔｅみたいに書いてます。
おそらくほとんどの処理系が１６Ｂｉｔだったころに編集した教科書を今でもそのまま使ってるのでしょう。

このような教科書を作るのも問題だしこのような教科書を使ってそのまま授業やってｉｎｔ＝２Ｂｙｔｅという間違った知識を教えてる学校も問題だと思います。

この回答への補足

　
> このような教科書を作るのも問題だしこのような教科書を使ってそのまま授業やってint = 2Byteという間違った知識を教えてる学校も問題だと思います。

コメントありがとうございます。
一生VBしか使わないなら、その認識でもOKですが。(^-^;
(あっ、VB6.0 → VB.NET でint = 4Byte に変わるからダメだわ(-_-;)
　

補足日時：2003/08/25 21:34

この回答へのお礼

　
結局、この件は、内容の不備として作者に連絡し、修正してもらうことにしました。

コメントを頂いた皆様、ありがとうございました。m(_ _)m
　

お礼日時：2003/08/25 21:42

No.3 回答者： shige_70 回答日時： 2003/08/25 02:28

やはり、そのテキストの記述は間違っているとしか思えません。

そうならない処理系がいまは実在しなくても将来的には存在するでしょうし、C言語の仕様でサイズが決まっていない以上、正しいと言うことは絶対にできません。

絶対的なサイズとしては、char型は1バイト、と言うことしか決められていません。

この回答へのお礼

　
> やはり、そのテキストの記述は間違っているとしか思えません。

コメントありがとうございます。
良質な解説書では、型のサイズの問題に加え、ハードウェアアーキテクチャ（Intel系/モトローラ系）によるエンディアンの相違についても言及されている場合が多いと思うのですが、問題の書籍では、移植性や可搬性への配慮が欠けているような気がします。
　

お礼日時：2003/08/25 21:32

No.2 回答者： V-bravo-U 回答日時： 2003/08/24 23:39

　現在のＣ言語においてはhiroyapapaのおっしゃるとおりlong型が８バイト体型

になっているコンパイラは実在します。私が仕事で使っているのも８バイト体型です。

　で、質問者は「long型３２個の配列による容量は１２８バイトは間違いである可能性もある」
ということを読み取りましたが、私の見解では「まぁ、正しいんじゃないの？」と
読み取っています。

　なぜなら、質問者がお使いの書籍の書版がいつなのかが明記されていないため、
４年あたりくらい前に初めて作られた書籍ならともかく、さらに古くから作られている
本と考えるならlong型が８バイト使うものは当時としてはあまり存在しない、すなわち
long型は４バイトであると決めうちしている時代であったため、問題として適切と判断されるのです。
＃「５年くらい前にはすでにlongは８バイト体型になっているものがあるのを知ってるぞ」なんて
　つっこみはとりあえずなしにして下さい。少なくても自分は３年前あたりからlong８バイト
　体型でコンパイルされるものがあるのを初めて知りました。（＾＾；

　あと、実際問題として、いまだにlong＝４バイトとして広く使われている（≒知名度が高い）
ということもあります。これは質問者も明記されていますよね。実務上の云々とありますが、
学習で使われているコンパイラがlong＝４バイト仕様なら少なくても現段階においては
実務上問題ないのではないでしょうか。質問者がlong型＝８バイト仕様をご存知なら
コンパイル環境が変わったときにコンパイラの仕様を調べるいうことでいかがでしょう。
もっとも、今現在使用しているコンパイル環境がlong型＝８バイト仕様で教科書が４バイト仕様
というのは大問題ではありますが・・・。

　もしよろしければお使いの本の初版と改訂日を確認の上、本の冒頭にある前書きあたりに
あるコンパイル環境を調べてみて下さい。改訂が古ければ書籍自体の間違いに当たりませんし、
たいていは前書きに「前提」が書かれているものと思われます。

この回答へのお礼

　
コメントありがとうございます。

> 　なぜなら、質問者がお使いの書籍の書版がいつなのかが明記されていない

残念ながら、その情報も開示致しかねます。m(_ _)m


> 実際問題として、いまだにlong＝4バイトとして広く使われている

おっしゃる通りですが、現実にlongが8バイトである処理系が存在するとのことですので、やはり教材としては不適切かと思います。

> 前書きに「前提」が書かれているものと思われます。

前書きに前提条件を明示する執筆者なら、この設問で出題するとは思えません。
　

お礼日時：2003/08/25 21:26