問題タブ [stdint]

問題は、あるプラットフォーム (windows、mvsc2015)uint64_tでは定義されてunsigned long longおり、別のプラットフォーム (ubuntu、clang) では次のように定義されておりunsigned long、次のようなコードがあることです。 sprintf(buffer, "%#llx", u64key);

C99 と C11 (少なくともそれらの最終ドラフト) の両方で、 、 、 、 in の存在がuint_least8_t署名uint_least16_tさuint_least32_tれuint_least64_tた<stdint.h>バリアントと共に必要であることがわかりました。

1 から 64 までuint_least{N}_tのすべてのNが利用可能であるという要件は合理的だと思います。これが当てはまらない正当な理由はありますか？実装が 8、16、32、および 64 を提供する必要がある場合、 Nのすべてのより小さい値の実装が実現可能であることは確かです (たとえばtypedef uint_least16_t uint_least15_t;、x86 の場合などは明らかです)。

私が尋ねているuint_least21_tのは、単一の Unicode コードポイントを格納する型が必要であることに気付いたからです。これは、その値U+0000をU+10FFFF含む (Unicode 4.0 で導入された制約) の間の任意の値を持つことができます。一部のターゲット アーキテクチャに (たとえば) 高速な 24 ビット整数が含まれている場合は、これがより正確な選択になると思います。現在、私は大きなプリプロセッサ セクションで立ち往生しており、適切な型を選択するために 21 から 32 までのNdefined(UINT_LEAST{N}_MAX)をテストしています。

c inlineに基づいて Python コードで使用するためのモジュールを開発していますswig。numpyそのために、 で配列にアクセスできるようにしたいと思いますC。今までは C のような型を使用していましたが、 fromunsigned shortのような型を使用して、モジュールが遭遇するコンパイラを保存したいと考えています。uint16_tstdint.h

残念ながら、型c++を使用する場合、関数は正しくラップされませんstdint.h。与えられたエラーは次のとおりです: _setc() takes exactly 2 arguments (1 given)。つまり、関数はnumpy配列を受け入れるようにラップされていません。を使用すると、エラーは発生しませんunsigned short。

numpyswigマップ配列をどのように作成できるか、アイデアはありますstdint-typesか?

interface.i動作していません:

c++機能しない:

interface.i働く：

c++機能作業:

この小さなコードサンプルでここに示されているように、inttypes にいくつかの問題があります。

私に与えます

fscanf でSCNu8toを変更すると、取得するはずのものが得られます。SCNo8

問題はどこだ？最初のコードでは機能しない理由がわかりませんが、そのバイトを 8 進数値として解釈すると機能します。

stdin から全行を読み取る必要があります。私が使用するfscanfと、スペースの前の文字列のみが読み取られます。スペースを含む行全体を読む必要があります。どうすればこれを達成できますか？

のシーケンスについて

cppcheck は以下の警告を出します:

警告: フォーマット文字列 (1 番目) の %lld には 'long long' が必要ですが、引数の型は 'signed int' です。

マクロ PRIi64 は lld によって解決されます。これは正しいですが、64 ビット整数型は long long int として受け入れられません。

これを解決する方法があることを願っています。私たちのプロジェクトではこのような警告がたくさん出ており、実際のバグはもう見られないからです。

x32 ABIは、特に x86_64 アーキテクチャ用に生成されたコードの 32 ビット ポインターを指定します。これは、x86_64 アーキテクチャ (64 ビット CPU レジスタを含む) の利点と、32 ビット ポインターの削減されたオーバーヘッドを組み合わせたものです。

<stdint.h>ヘッダーは typedef int_fast8_t、int_fast16_t、int_fast32_t、およびint_fast64_t(および対応する unsigned 型など) を定義します。uint_fast8_tそれぞれは次のとおりです。

少なくとも指定された幅を持つすべての整数型の中で、通常最も高速に動作する整数型

脚注付き:

指定されたタイプは、すべての目的で最速であるとは限りません。ある型を別の型よりも優先して選択する明確な根拠が実装にない場合、実装は単純に、符号と幅の要件を満たす整数型を選択します。

（N1570 C11ドラフトより引用）

問題は、x32 ABI の有無にかかわらず、x86_64 アーキテクチャに対してどのよう[u]int_fast16_tに[u]int_fast32_t型を定義する必要があるかということです。これらのタイプを指定する x32 ドキュメントはありますか? それらは 32 ビット x86 定義 (両方とも 32 ビット) と互換性があるべきですか、それとも x32 は 64 ビット CPU レジスタにアクセスできるため、x32 ABI の有無にかかわらず同じサイズである必要がありますか? (x32 ABI が使用されているかどうかに関係なく、x86_64 には 64 ビットのレジスタがあることに注意してください。)

__x86_64__これはテストプログラムです (gcc 固有のマクロに依存します):

でコンパイルするとgcc -m64、出力は次のようになります。

でコンパイルするとgcc -mx32、出力は次のようになります。

(最初の行とは別に、gcc -m3232 ビット x86 コードを生成する と出力を一致させます)。

これは glibc (<stdint.h>ヘッダーを定義する) のバグですか、それとも x32 ABI 要件に従っているのでしょうか? x32 ABI ドキュメントまたはx86_64 ABI ドキュメント[u]int_fastN_tのいずれにもタイプへの参照はありませんが、それを指定する別のものがある可能性があります。

64ビットのレジスタが利用可能であるため、fast16およびfast32タイプはx32またはx32で64ビットにする必要があると主張することができます。それは現在の動作よりも理にかなっていますか?

(x32 ABI についてのみ尋ねた元の質問を大幅に編集しました。この質問では、x32 の有無にかかわらず x86_64 について尋ねています。)