Zahlenformatierung in C

[Der Martin]

Hallo,

Die Größe eines Speicherbereichs in Byte *ist* ein ganzzahliger Wert. Deswegen ist size_t ja identisch zu int deklariert.
Nein, ist es nicht. Auf bestimmten Systemen stimmt das im Spezialfall

ja, stimmt. Nämlich dann, wenn Daten- und Adressbus die gleiche Breite haben.

aber nimm zum Beispiel Linux oder Windows auf x86_64 (64 bit) und da ist size_t äquivalent zu einer 64bit-Ganzzahl (unter Linux/x86_64 wäre das also äquivalent zu long, unter Windows/x86_64 äquivalent zu long long) während int auf diesen Systemen weiterhin eine 32bit-Ganzzahl ist.

Dann wären 64bit-Windows oder 64bit-Linux Mogelpackungen - denn die "Bittigkeit" leitet sich ja von der Datenbusbreite ab, und int soll die "natürliche" Datenbreite eines Systems wiedergeben. x86-64 sind echte 64bit-Prozessoren mit einem 64bit-Datenbus und 64bit-Registern. Wenn ein Compiler für diese Prozessoren int mit nur 32bit definiert, würde man sie de facto wieder auf 32bit-Systeme degradieren (ich hatte noch nie einen 64bit-Compiler in den Fingern und kann das nicht nachprüfen).

Allein schon das Bestreben, hier einen eigenen Typ zu definieren, ist in meinen Augen eine unnötige Verkomplizierung.
Es geht hier um Portabilität:

Dass wir hier grundsätzlich unterschiedliche Ansichten haben, ist ja bekannt.

Der Typ size_t ist laut Standard so festgelegt, dass das *immer* für Puffergrößen u.ä. verwendet werden kann, während z.B. ptrdiff_t *immer* für Differenzen zwischen zwei Pointern verwendet werden kann. Genauso gibt's off_t für Positionen in Dateien (was z.B. auch auf einem 32bit-OS eine 64bit-Größe sein kann weil Dateien ja > 4 Gig sein können) und so weiter. Wenn man diese Typen an den korrekten Stellen verwendet, stellt man sicher, dass man den Code überall dort verwenden kann, wo es eine standardkonforme C-Implementierung gibt.

Das heißt aber auch, dass derselbe Code, wenn er auf unterschiedlichen Plattformen compiliert wird, auch unterschiedliche Datenstrukturen erzeugt. Das ist nicht das, was ich unter Portabilität verstehe.

So long,
 Martin