size_t vs. uintptr_t

Der C-Standard garantiert, dass dieser size_tTyp jeden Array-Index enthalten kann. Dies bedeutet, dass logischerweise size_tjeder Zeigertyp enthalten sein sollte. Ich habe auf einigen Websites, die ich auf den Googles gefunden habe, gelesen, dass dies legal ist und / oder immer funktionieren sollte:

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

In C99 führte der Standard die Typen intptr_tund uintptr_tein, die signierte und nicht signierte Typen sind, die garantiert Zeiger enthalten können:

uintptr_t p = (size_t) v;

Was ist der Unterschied zwischen size_tund uintptr_t? Beide sind nicht signiert und sollten in der Lage sein, jeden Zeigertyp zu halten, sodass sie funktional identisch zu sein scheinen. Gibt es einen wirklich zwingenden Grund, a uintptr_t(oder besser noch void *) a anstelle von a zu verwenden size_t, außer Klarheit? Gibt es in einer undurchsichtigen Struktur, in der das Feld nur von internen Funktionen behandelt wird, einen Grund, dies nicht zu tun?

Aus dem gleichen Grund war ptrdiff_tes ein vorzeichenbehafteter Typ, der Zeigerunterschiede aufnehmen kann und daher fast jeden Zeiger aufnehmen kann. Wie unterscheidet er sich also von intptr_t?

Sind nicht alle diese Typen grundsätzlich trivial unterschiedliche Versionen derselben Funktion? Wenn nicht, warum? Was kann ich mit einem von ihnen nicht machen, was ich mit einem anderen nicht machen kann? Wenn ja, warum hat C99 der Sprache zwei im Wesentlichen überflüssige Typen hinzugefügt?

Ich bin bereit, Funktionszeiger zu ignorieren, da sie nicht für das aktuelle Problem gelten, aber ich kann sie gerne erwähnen, da ich den Verdacht habe, dass sie für die "richtige" Antwort von zentraler Bedeutung sind.

size_tist ein Typ, der jeden Array-Index enthalten kann. Dies bedeutet, dass size_t logischerweise jeden Zeigertyp enthalten kann

Nicht unbedingt! Erinnern Sie sich beispielsweise an die Zeit segmentierter 16-Bit-Architekturen: Ein Array ist möglicherweise auf ein einzelnes Segment beschränkt (ein 16-Bit-Array size_twürde dies tun), ABER Sie könnten mehrere Segmente haben ( intptr_tfür die Auswahl wäre also ein 32-Bit- Typ erforderlich das Segment sowie den Versatz darin). Ich weiß, dass diese Dinge in diesen Tagen von einheitlich adressierbaren, nicht segmentierten Architekturen seltsam klingen, aber der Standard MUSS eine größere Vielfalt als "was 2009 normal ist" berücksichtigen, wissen Sie! -)

Zu Ihrer Aussage:

"Der C-Standard garantiert, dass dieser size_tTyp einen beliebigen Array-Index enthalten kann. Dies bedeutet, dass logischerweise size_tjeder Zeigertyp gespeichert werden kann."

Dies ist tatsächlich ein Irrtum (ein Missverständnis, das sich aus falschen Überlegungen ergibt) ^(a) . Sie können denken Letzteres aus Ersterem folgt, aber das ist eigentlich nicht der Fall.

Zeiger und Array-Indizes sind es nicht dasselbe. Es ist durchaus plausibel, sich eine konforme Implementierung vorzustellen, die Arrays auf 65536 Elemente beschränkt, es Zeigern jedoch ermöglicht, jeden Wert in einem massiven 128-Bit-Adressraum zu adressieren.

C99 gibt an, dass die Obergrenze einer size_tVariablen durch definiert istSIZE_MAX und diese bis zu 65535 betragen kann (siehe C99 TR3, 7.18.3, unverändert in C11). Zeiger wären ziemlich begrenzt, wenn sie in modernen Systemen auf diesen Bereich beschränkt wären.

In der Praxis werden Sie wahrscheinlich feststellen, dass Ihre Annahme zutrifft, aber das liegt nicht daran, dass der Standard dies garantiert. Weil es das eigentlich nicht garantiert.

^(a) Dies ist übrigens keine Form von persönlichem Angriff, sondern nur die Begründung, warum Ihre Aussagen im Kontext des kritischen Denkens falsch sind. Zum Beispiel ist die folgende Argumentation ebenfalls ungültig:

Alle Welpen sind süß. Dieses Ding ist süß. Deshalb muss dieses Ding ein Welpe sein.

Die Niedlichkeit oder das Gegenteil von Welpen spielt hier keine Rolle. Ich sage nur, dass die beiden Tatsachen nicht zu einer Schlussfolgerung führen, da die ersten beiden Sätze die Existenz von niedlichen Dingen zulassen, die es nicht sind Welpen sind.

Dies ähnelt Ihrer ersten Aussage, die nicht unbedingt die zweite vorschreibt.

Ich werde alle anderen Antworten in Bezug auf die Argumentation mit Segmentbeschränkungen, exotischen Architekturen usw. für sich stehen lassen.

Ist der einfache Unterschied in den Namen nicht Grund genug, den richtigen Typ für das Richtige zu verwenden?

Wenn Sie eine Größe speichern, verwenden Sie size_t. Wenn Sie einen Zeiger speichern, verwenden Sie intptr_t. Eine Person, die Ihren Code liest, wird sofort wissen, dass "aha, dies ist eine Größe von etwas, wahrscheinlich in Bytes" und "oh, hier ist ein Zeigerwert, der aus irgendeinem Grund als Ganzzahl gespeichert wird".

Ansonsten könnte man einfach unsigned long(oder in diesen hier modernen Zeiten unsigned long long) für alles verwenden. Größe ist nicht alles, Typnamen haben eine Bedeutung, die nützlich ist, da sie zur Beschreibung des Programms beitragen.

Möglicherweise ist die Größe des größten Arrays kleiner als ein Zeiger. Denken Sie an segmentierte Architekturen - Zeiger können 32-Bit sein, aber ein einzelnes Segment kann möglicherweise nur 64 KB adressieren (zum Beispiel die alte 8086-Architektur im Real-Modus).

Während diese auf Desktop-Computern nicht mehr häufig verwendet werden, soll der C-Standard auch kleine, spezialisierte Architekturen unterstützen. Es gibt immer noch eingebettete Systeme, die beispielsweise mit 8- oder 16-Bit-CPUs entwickelt werden.

Ich würde mir vorstellen (und das gilt für alle Typnamen), dass es Ihre Absichten im Code besser vermittelt.

Zum Beispiel, obwohl unsigned shortund wchar_tunter Windows die gleiche Größe haben (glaube ich), zeigt die Verwendung von wchar_tanstelle von unsigned shortdie Absicht, dass Sie damit ein breites Zeichen und nicht nur eine beliebige Zahl speichern.

Wenn ich sowohl vorwärts als auch rückwärts schaue und mich daran erinnere, dass verschiedene seltsame Architekturen über die Landschaft verstreut waren, bin ich mir ziemlich sicher, dass sie versucht haben, alle vorhandenen Systeme zu verpacken und auch alle möglichen zukünftigen Systeme bereitzustellen.

So sicher, wie sich die Dinge eingestellt haben, haben wir bisher nicht so viele Typen gebraucht.

Aber selbst in LP64, einem weit verbreiteten Paradigma, benötigten wir size_t und ssize_t für die Systemaufrufschnittstelle. Man kann sich ein eingeschränkteres Legacy- oder zukünftiges System vorstellen, bei dem die Verwendung eines vollständigen 64-Bit-Typs teuer ist und sie möglicherweise auf E / A-Operationen mit mehr als 4 GB zugreifen möchten, aber immer noch 64-Bit-Zeiger haben.

Ich denke, man muss sich fragen: Was könnte entwickelt worden sein, was könnte in Zukunft kommen. (Vielleicht internetweite 128-Bit-Zeiger für verteilte Systeme, aber nicht mehr als 64 Bit in einem Systemaufruf oder vielleicht sogar ein "Legacy" -32-Bit-Limit. :-) Stellen Sie sich vor, Legacy-Systeme könnten neue C-Compiler erhalten. .

Schauen Sie sich auch an, was es damals gab. Wie wäre es neben den zillion 286 Real-Mode-Speichermodellen mit den CDC-60-Bit-Wort- / 18-Bit-Zeiger-Mainframes? Wie wäre es mit der Cray-Serie? Egal, normales ILP64, LP64, LLP64. (Ich dachte immer, Microsoft sei mit LLP64 vorgetäuscht, es hätte P64 sein sollen.) Ich kann mir durchaus vorstellen, dass ein Komitee versucht, alle Grundlagen abzudecken ...

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;
}

Dies bedeutet, dass intptr_t immer size_t ersetzen muss und umgekehrt.