C で、a、b、c が16ビット符号無し整数のとき

質問

C で、a、b、c が16ビット符号無し整数のとき、

a = 0x7FFF * b / c;

の途中結果の 0x7FFF * b は 16ビット符号無し整数として処理されるのですか。32ビットで処理してくれたら便利なのですが。

回答No.2

notnot · ベストアンサー

Cの規格は確認してませんが、普通のCコンパイラだと、1 とか 0x7FFF のような数字定数はint型です。
int型が32bitのコンパイラを使っていれば、全部32bitで計算されます。

お礼

回答ありがとうございます。

回答No.7

chie65536（@chie65535）

＞途中結果の 0x7FFF * b は 16ビット符号無し整数として処理されるのですか。32ビットで処理してくれたら便利なのですが。

0x7FFFは「int型定数」ですから「int型 * 整数型はint型」と言う規則により、int型になります。

「int型が何ビットの整数なのか？」は、処理系に依存するので、何ビットになるかは判りません。

「符号＋15ビット」と言う処理系では「符号＋15ビット」になり、「符号＋31ビット」と言う処理系では「符号＋31ビット」になります。

お礼

回答ありがとうございます。
私が使っている処理系では int型が 32ビットなので、希望どおりの処理になっているようですね。

回答No.6

jacta

32ビットちょうどの整数型が存在するかどうかは処理系によって異なります。
けれども、32ビット以上であればよいのなら、次のようにすることで解決します。

a = (int_least32_t)0x7fff * b / c;

または

a = INT32_C(0x7fff) * b / c;

いずれの場合も <stdint.h> をインクルードしてください。

お礼

回答ありがとうございました。

回答No.5

Tacosan

はい, キャストしようと何しようと「必ず 32ビットで処理してもらう」絶対的な方法は存在しません.

そもそも「ぴったり 32ビットのデータ型」というものが存在することすら保証されていません. 例えば
short: 16ビット
int: 24ビット
long: 48ビット
long long: 96ビット
という処理系があってもかまわないのです.

お礼

回答ありがとうございます。
なるほどそういう意味ですか。

回答No.4

kmee

処理系によります。

型の指示(U 等)がなければ、整数リテラルはint型になります。
つまり
(int)(0x7fff)
です。

整数同士の演算では、基本「大きい」ほうに自動で型変換されます。
(int)(0x7fff) * b
の段階で、7fffが 「int →16ビット符号無し整数」 または、bが「16ビット符号無し整数→int」に、型変換されます。

まわりくどい書き方をしているのは、 intが何ビットか不明だからです。
intが16ビットで、16ビット符号無し整数とは unsigned int のこと、という処理系もあります。

intが32ビット、16ビット符号無し整数とは unsigned short だったとすれば、その式は次のようなキャストしたものと同等になります

a = ( unsigned short) ( (int)0x7FFF * (int)b / (int)c );
/* 32ビットで計算した結果のうち、16ビットをaに代入 */

お礼

回答ありがとうございました。
よく分かりました。

回答No.3

Tacosan

この辺はほとんど処理系定義の世界.

本件については #1 の通り「コンパイラによって異なる」が正解. そして厳密には「必ず 32ビットで処理してもらう」方法も存在しない.

お礼

回答ありがとうございます。

キャストしても、32ビットで処理できるわけではないということですか。

回答No.1

takacy_2010

お使いになられているコンパイラによっても異なると思います．
キャスト演算子を具体的に指定することで回避できると思います．
例えばですが，こんなイメージではどうでしょうか．
a = (unsigned short)((unsigned long)0x7FFF * (unsigned long)b) / c;

お礼

回答ありがとうございます。
やはりキャストが必要ですね。