size_tとuintptr_tの比較

C標準でsize_tは、任意の配列インデックスを保持できる型であることを保証しています。つまり、論理的には、size_t任意のポインタ型を保持できる必要があります。これは合法であり、常に機能するはずであるとGoogleで見つけたいくつかのサイトで読んだことがあります。

void *v = malloc(10);
size_t s = (size_t) v;

そのため、C99では、標準によりintptr_tおよびuintptr_t型が導入されました。これらは、ポインタを保持できることが保証されている符号付きおよび符号なしの型です。

uintptr_t p = (size_t) v;

だから、使用しての違いは何であるsize_tとはuintptr_t？どちらも符号なしであり、どちらも任意のポインタ型を保持できるはずなので、機能的には同じように見えます。明快さ以外に、aよりもuintptr_t（またはもっと良いのはa void *）を使用する本当に説得力のある理由はありますsize_tか？フィールドが内部関数によってのみ処理される不透明な構造で、これを行わない理由はありますか？

同様に、ptrdiff_tポインタの違いを保持できる符号付きの型であり、したがってほとんどのポインタを保持できるので、それはどのように区別されintptr_tますか？

これらのタイプはすべて、基本的に同じ機能のわずかに異なるバージョンを提供しているのではないですか？そうでない場合、なぜですか？それらの1つを使用して、他のユーザーを使用してできないことは何ですか？もしそうなら、なぜC99は2つの本質的に不必要な型を言語に追加したのですか？

関数ポインターは現在の問題には当てはまらないため、無視してもかまいませんが、「正しい」答えの中心となるのではないかという疑惑があるので、遠慮なく触れてください。

size_t任意の配列インデックスを保持できるタイプです。つまり、論理的には、size_tは任意のポインタ型を保持できる必要があります。

必ずしも！たとえば、セグメント化された16ビットアーキテクチャの時代を振り返ってみましょう。たとえば、配列が単一のセグメントに制限される場合があります（16ビットの場合size_tはそうなります）。ただし、複数のセグメントを使用することもできます（選択するには32ビットintptr_tタイプが必要です）セグメントとその中のオフセット）。私はこれらのものが均一にアドレス可能な非セグメント化アーキテクチャの最近では奇妙に聞こえることを知っていますが、標準は「2009年の通常」よりも幅広い多様性に対応しなければなりません。

あなたの声明について：

「C標準でsize_tは、これが任意の配列インデックスを保持できる型であることを保証しています。つまり、論理的にsize_tは、任意のポインター型を保持できるはずです。」

これは実際には誤りです（誤った推論による誤解）^（a）。後者は前者に続くと思うかもしれませんが、実際はそうではありません。

ポインタと配列インデックスは同じものではありません。配列を65536要素に制限し、ポインターが任意の値を巨大な128ビットアドレス空間にアドレス指定できるようにする準拠実装を想定することは非常に妥当です。

C99では、size_t変数の上限はによって定義されてSIZE_MAXおり、これは65535まで低くすることができます（C11で変更されていないC99 TR3、7.18.3を参照）。ポインターは、最新のシステムでこの範囲に制限されている場合、かなり制限されます。

実際には、おそらくあなたの仮定が成り立つことがわかるでしょうが、それは標準がそれを保証しているからではありません。それは実際にはそれを保証しないからです。

^（a）これは、何らかの形での個人的な攻撃ではなく、批判的思考の文脈でステートメントが誤っている理由を述べているだけです。たとえば、次の推論も無効です。

すべての子犬はかわいいです。これはかわいいです。したがって、これは子犬でなければなりません。

最初の2つの文は子犬ではないかわいいものの存在を可能にするため、2つの事実が結論につながらないということは、ここでは子犬のかわいらしさは関係ありません。

これは最初のステートメントに似ていますが、必ずしも2番目のステートメントを必須とするわけではありません。

セグメントの制限、エキゾチックなアーキテクチャなどの推論については、他のすべての回答をそのまま示しておきます。

名前の単純な違いは、適切な型を適切なものに使用するのに十分な理由ではありませんか？

サイズを保存する場合は、を使用しますsize_t。ポインタを保存する場合は、を使用しますintptr_t。コードを読んだ人は、「ああ、これはおそらくバイト単位のサイズです」、「ああ、なんらかの理由で、ここにポインタ値が整数として格納されている」とすぐにわかります。

それ以外の場合は、すべてを使用できますunsigned long（または、ここでは現代unsigned long long）。サイズはすべてではありません。タイプ名には意味があり、プログラムを説明するのに役立ちます。

最大の配列のサイズがポインターよりも小さい可能性があります。セグメント化されたアーキテクチャを考えてみてください-ポインタは32ビットかもしれませんが、単一のセグメントは64KBしかアドレス指定できない場合があります（たとえば、古いリアルモード8086アーキテクチャ）。

これらはデスクトップマシンでは一般的に使用されていませんが、C標準は、小規模で特殊なアーキテクチャをサポートすることを目的としています。たとえば、8ビットまたは16ビットCPUを使用して開発されている組み込みシステムはまだあります。

私は（そしてこれはすべての型名に当てはまります）、コードであなたの意図をよりよく伝えると想像します。

にもかかわらず、例えばunsigned shortおよびwchar_tWindows上で同じ大きさ（と思う）、使用しているwchar_t代わりにunsigned short、あなたがいうだけで、いくつかの任意の数よりワイド文字を格納するためにそれを使用するという意図を示しています。

後方と前方の両方を見て、さまざまな奇妙なアーキテクチャーがランドスケープに散在していたことを思い出すと、それらはすべての既存のシステムをラップし、また可能なすべての将来のシステムを提供しようとしていると確信しています。

確かに、物事が解決する方法として、これまでそれほど多くのタイプを必要としていませんでした。

しかし、かなり一般的なパラダイムであるLP64でさえ、システムコールインターフェイスにsize_tとssize_tが必要でした。完全な64ビットタイプを使用するとコストが高く、4 GBを超えるI / O演算をパントしたいが64ビットポインターを使用する、より制約のあるレガシーまたは将来のシステムを想像できます。

私はあなたが不思議に思う必要があると思います：何が開発されたのか、将来何が起こるのか。（おそらく128ビットの分散システムのインターネット全体のポインターですが、システムコールでは64ビット以下、あるいは「レガシー」32ビットの制限でさえあります。:-)レガシーシステムが新しいCコンパイラを取得する可能性があるというイメージ。 。

また、当時存在していたものも見てください。ジリオン286リアルモードメモリモデルに加えて、CDC 60ビットワード/ 18ビットポインターメインフレームはどうですか？クレイシリーズはどうですか？通常のILP64、LP64、LLP64を気にしないでください。（マイクロソフトはLLP64を使用していると思っていましたが、P64でなければなりませんでした。）委員会がすべてのベースをカバーしようとしていることは確かに想像できます...

int main(){
  int a[4]={0,1,5,3};
  int a0 = a[0];
  int a1 = *(a+1);
  int a2 = *(2+a);
  int a3 = 3[a];
  return a2;
}

intptr_tは常にsize_tの代わりに使用する必要があり、その逆も同様です。