問題タブ [integer-promotion]

この記事には次のように書かれています。

元の型のすべての値が int として表現できる場合は、小さい方の型の値が int に変換されます。それ以外の場合は、unsigned int に変換されます

signed/unsigned charとのすべての値はsigned/unsigned shortとして表すことができるintため、型が に昇格するのはunsigned intいつですか?

Javaでは、次のコードスニペットがあるとします

K&R による C プログラミング言語の機能を試していhtoi(char*)ます (Excercise 2-3、43 ページ)。

この関数は、16 進文字列を基数 10 に変換するためのものです。

私はそれが機能していると信じています。これは私のコードです:

私の問題は、htoi(char*)関数の次の行にあります。

ではなくにするshortために削除すると、無限ループが発生します。firstIndexunsigned intunsigned short int

sそのため、 inの後ろから開始すると、htoi(char* s)がi >= firstIndexfalse と評価されることはありません。

なぜこれが起こるのですか？ささいなことを見逃しているのでしょうか、それともこの未定義の動作を引き起こすために何かひどく間違ったことをしたのでしょうか?

そのため、フィールドの問題があり、何日もデバッグした後、問題をこの特定のコードに絞り込みました。ここでは、while ループの処理が行われていませんでした。

numberA + 1uint16 の制限である 65535 に達するまで、これは問題なく実行されていました。後で別の一連の print ステートメントを実行したところ、値が であることが65536わかりましnumberBた0。これはチェックに失敗し、処理は行われませんでした。

これが気になったので、これを確認するために簡単な C プログラム (GCC 4.9.2 でコンパイル) を作成しました。

結果は次のとおりです。

そのため、 の結果がnumberA + 1uint32_t に昇格されたようです。これはC言語が意図したものですか？それとも、これはコンパイラ/ハードウェアの奇妙さですか?

私の C コンパイラは、値に単項マイナスを使用すると警告を出したunsignedので、代わりに 0 からの減算を行うことで警告を修正しました。

ここで、現在のコードが元のコードと同等であるかどうか疑問に思います。

私の質問は次のとおりです。同じ値の場合b、コードの両方の行で同じ結果が得られaますか?

次のコードがあります。

最初のアサーションは失敗し、2 番目のアサーションは失敗しないと思います。ただしgcc 4.9.2、clang 3.6反対のことを行います。コードで auto の代わりに uint16_t を使用すると、適切なアサーションが失敗し、別のアサーションが成功します。

PS最初は、1代わりにstatic_cast<uint16_t>(1)、数値リテラルがint型であるという事実が問題の原因であると考えていましたが、1ここで明示的にキャストした後でも間違ったアサーションが失敗しました。

一部のデータのバイト単位のサイズを見つけることは、一般的な操作です。

考案された例:

ここでの明らかなエラーは、int がオーバーフローすることです (たとえば、23171x23171 RGBA バイト バッファ)。

3 つ以上の 値を乗算する場合の昇格のルールは何ですか?
(値のペアを乗算するのは簡単です)

安全にプレイして、キャストするだけです。

もう 1 つの方法は、括弧を追加して、乗算と昇格の順序が予測可能であることを確認することです (ペア間の自動昇格は期待どおりに機能します) ...

...うまくいきますが、私の質問は.

3 つ以上の値を乗算して自動的に昇格させる決定論的な方法はありますか?
（オーバーフローを避けるため）

それとも、これは未定義の動作ですか?

ノート...

• ここで使用してもオーバーフローは防止size_tされません。その型の最大値のオーバーフローが防止されるだけです。
• 与えられた例では、引数もそうsize_tである可能性があることは理にかなっていますが、それはこの質問のポイントではありません.