size_t vs. uintptr_t

Das garantiert die C-Norm size_t ist ein Typ, der jeden Array-Index enthalten kann. Das bedeutet logischerweise, size_t sollte jeden Zeigertyp aufnehmen können. Ich habe auf einigen Websites gelesen, die ich bei Google gefunden habe, dass dies legal ist und / oder immer funktionieren sollte:

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

Also wurde dann in C99 der Standard eingeführt intptr_t und uintptr_t Typen, die signierte und unsignierte Typen sind, die garantiert Zeiger enthalten können:

uintptr_t p = (size_t) v;

Was ist also der Unterschied zwischen der Verwendung von size_t und uintptr_t? Beide sind nicht signiert und beide sollten in der Lage sein, jeden Zeigertyp aufzunehmen, sodass sie funktional identisch erscheinen. Gibt es einen wirklich zwingenden Grund für die Verwendung? uintptr_t (oder besser noch a void *) eher als ein 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 Grunde, ptrdiff_t war ein vorzeichenbehafteter Typ, der in der Lage ist, Zeigerunterschiede zu halten, und daher in der Lage, fast jeden Zeiger zu halten, also wie unterscheidet er sich von intptr_t?

Bieten nicht all diese Typen im Grunde trivialerweise unterschiedliche Versionen derselben Funktion? Wenn nicht, warum? Was kann ich mit einem von ihnen nicht tun, was ich mit einem anderen nicht tun 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 auf das aktuelle Problem zutreffen, aber Sie können sie gerne erwähnen, da ich den leisen Verdacht habe, dass sie für die “richtige” Antwort von zentraler Bedeutung sein werden.

size_t ist ein Typ, der jeden Array-Index enthalten kann. Dies bedeutet, dass size_t logischerweise in der Lage sein sollte, jeden Zeigertyp aufzunehmen

Nicht unbedingt! Erinnern Sie sich zum Beispiel an die Tage segmentierter 16-Bit-Architekturen: Ein Array kann auf ein einzelnes Segment beschränkt sein (also ein 16-Bit size_t tun würde), ABER Sie könnten mehrere Segmente haben (also eine 32-Bit intptr_t Typ wäre erforderlich, um das Segment sowie den darin enthaltenen Offset auszuwählen). Ich weiß, dass diese Dinge in diesen Tagen von einheitlich adressierbaren unsegmentierten Architekturen seltsam klingen, aber der Standard MUSS für eine größere Vielfalt sorgen als “was 2009 normal ist”, wissen Sie!-)

Zu deiner Aussage:

„Das garantiert die C-Norm size_t ist ein Typ, der jeden Array-Index enthalten kann. Das bedeutet logischerweise, size_t sollte jeden Zeigertyp aufnehmen können.”

Dies ist eigentlich ein Trugschluss (ein Missverständnis, das sich aus einer falschen Argumentation ergibt).^(a). Du könntest denken Letzteres folgt aus Ersterem, aber das ist nicht wirklich der Fall.

Zeiger und Array-Indizes sind nicht das gleiche. Es ist durchaus plausibel, sich eine konforme Implementierung vorzustellen, die Arrays auf 65536 Elemente begrenzt, Zeigern jedoch erlaubt, jeden Wert in einen massiven 128-Bit-Adressraum zu adressieren.

C99 besagt, dass die Obergrenze von a size_t Variable wird definiert durch SIZE_MAX und das kann so niedrig wie 65535 sein (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 eigentlich nicht garantiere es.

^(a) Das ist nicht Übrigens eine Art persönlicher Angriff, der nur erklärt, warum Ihre Aussagen im Kontext des kritischen Denkens falsch sind. Ungültig ist beispielsweise auch die folgende Begründung:

Alle Welpen sind süß. Das Ding ist süß. Also muss das Ding ein Welpe sein.

Die Niedlichkeit von Welpen spielt hier keine Rolle, ich behaupte nur, dass die beiden Tatsachen nicht zu dem Schluss führen, weil die ersten beiden Sätze die Existenz von niedlichen Dingen zulassen, die es sind nicht Welpen.

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

Ich lasse alle anderen Antworten bezüglich der Argumentation mit Segmentbeschränkungen, exotischen Architekturen usw. für sich stehen.

Ist das nicht einfach Unterschied in den Namen 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, das 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önntest du einfach verwenden unsigned long (oder, in diesen hier modernen Zeiten, unsigned long long) für alles. Größe ist nicht alles, Typnamen haben Bedeutung, was nützlich ist, da es hilft, das Programm zu beschreiben.

Es ist möglich, dass die Größe des größten Arrays kleiner als ein Zeiger ist. Denken Sie an segmentierte Architekturen – Zeiger können 32 Bit groß sein, aber ein einzelnes Segment kann möglicherweise nur 64 KB adressieren (z. B. die alte Real-Mode-8086-Architektur).

Während diese in Desktop-Rechnern nicht mehr häufig verwendet werden, soll der C-Standard sogar kleine, spezialisierte Architekturen unterstützen. Es werden zum Beispiel immer noch eingebettete Systeme mit 8- oder 16-Bit-CPUs entwickelt.

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

Obwohl zum Beispiel unsigned short und wchar_t sind die gleiche Größe unter Windows (glaube ich), mit wchar_t Anstatt von unsigned short zeigt die Absicht, dass Sie es verwenden werden, um ein breites Zeichen zu speichern, und nicht nur eine willkürliche Zahl.

Wenn ich sowohl nach hinten als auch nach vorne schaue und mich daran erinnere, dass verschiedene seltsame Architekturen über die Landschaft verstreut waren, bin ich mir ziemlich sicher, dass sie versuchten, alle bestehenden Systeme zu verpacken und auch für alle möglichen zukünftigen Systeme zu sorgen.

So sicher, wie sich die Dinge ergeben haben, haben wir bisher nicht so viele Typen benötigt.

Aber selbst in LP64, einem ziemlich verbreiteten Paradigma, brauchten wir size_t und ssize_t für die Systemaufrufschnittstelle. Man kann sich ein eingeschränkteres älteres 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 setzen 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 der Zukunft kommen. (Vielleicht 128-Bit-Zeiger für verteilte Systeme im Internet, aber nicht mehr als 64 Bit in einem Systemaufruf oder vielleicht sogar eine “alte” 32-Bit-Grenze. 🙂 Bild, dass alte Systeme neue C-Compiler bekommen könnten. .

Schauen Sie sich auch an, was es damals gab. Abgesehen von den zig 286 Real-Mode-Speichermodellen, was ist 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 wäre mit LLP64 anmaßend, es hätte P64 sein sollen.) Ich kann mir durchaus vorstellen, dass ein Komitee versucht, alle Grundlagen abzudecken …

size_t vs. uintptr_t

Neben anderen guten Antworten:

size_t ist darin definiert <stddef.h>, <stdio.h>, <stdlib.h>, <string.h>, <time.h>, <uchar.h>, <wchar.h>. Es ist mindestens 16-Bit.

uintptr_t ist darin definiert <stdint.h>. es ist Optional. Eine konforme Bibliothek definiert es möglicherweise nicht, wahrscheinlich weil es keinen ausreichend breiten Integer-Typ gibt, um a umzuwandeln void*–uintptr_t–void *.

Beide sind vorzeichenlose Ganzzahl Typen.

Beachten Sie das Optional Begleiter intptr_t ist ein vorzeichenbehaftete Ganzzahl Typ.