Woher stammen eigentlich die Bezeichnungen uint8/16/32_t?

Jens schrieb:

> Nun soweit meine Recherche... aaaaber. hat sich das C99 Komitee dies
> einfach so ausgedacht

Das Komitee denkt sich in den meisten Fällen überhaupt nichts selber 
aus.
Sondern da werden Anträge und Vorschläge eingereicht, die vom Komitee 
diskutiert, eventuelle abgesegnet, begutachtet und dann im nächsten 
Standard auftauchen.

> oder war es in anderen Systemen bereits good
> practice und wurde übernommen?

Derartige Typdefinitionen in der einen oder anderen Form gab es, seit 
industriell C programmiert wird. Und sie waren ein konstantes Ärgernis, 
wenn man Code von einem System auf ein anderes portieren musste. Die 
Frage war also nicht ob man so etwas einführen sollte, sondern wie der 
'Wortlaut' sein sollte.

Das angehängte _t war relativ logisch, da es einen Datentyp size_t oder 
auch time_t auch vorher schon gab. Das die Bitzahl darin vorkommen 
würde, es in irgendeiner Art und Weise eine Kennzeichnung für 'mit oder 
ohne Vorzeichen' geben würde, die Datentyp Namen nicht zu kurz aber auch 
nicht zu lang sein sollten, man dafür sorgen wollte, dass älterer Code 
davon nicht beeinträchtigt wird (ist beim C und C++ Komitee immer ein 
wichtiger Punkt), ... berücksichtigt man das alles, dann bleiben nicht 
mehr allzuviele Alternativen. Und dann nimmt man halt denjenigen 
eingereichten Vorschlag, der den meisten gefällt.

Zudem ist der Inhalt der meisten abgesegneten Standards schon Jahre 
vorher in Form von Drafts verfügbar, so dass es nicht wirklich wundert, 
wenn im 1998 Kernel bereits Dingen vorgegriffen wird, die dann erst 1999 
offiziell wurden. Zumal es sich hier im Konkreten nicht wirklich um 
etwas schwierig zu Implementierende handelt, was weitreichende 
Konsequenzen im Compiler hätte.

Ich glaube _t das steht für type oder typedef. Ich benutzte es 
inzwischen selbst sehr oft wenn ich typedefs definiere. Sieht man ja 
auch z.b. bei size_t, time_t..., ist wohl eher ne POSIX-Sache

pks schrieb:
> Besonders nervig finde ich das, wenn die Bezeichnungen sich namentlich
> sehr von den Standardtypen unterscheiden oder die Länge eben nicht aus
> dem Namen ersichtlich ist(z.B. DWORD).

Da musst Du die Historie berücksichtigen. Die Windows-API, der das 
entstammt, ist ein paar Jährchen älter als C99, und nur weil es einen 
neuen Programmiersprachenstandard gibt, bedeutet das nicht, das sämliche 
API-Headerdateien neu geschrieben werden müssten -- ganz zu schweigen 
davon, daß Microsoft sich bislang nur damit großtut, C99 komplett zu 
ignorieren.

Ein semioffizielles Statement dazu ist, daß man doch einfach C++ nehmen 
solle, wenn man C99 benötigt.

♪Geist schrieb:
> Mit uint16_t teilst du dem Compiler mit, dass dir die 16 bit ausreichen
> und belegst nicht gleich unnötig komplette 32Bit.

Nein.  Mit uint16_t teilst du dem Compiler mit, dass du exakt 16 Bits
haben willst, egal was es kostet.  Falls die Zielmaschine keinen
solchen Datentypen darstellen kann, lässt sich das Programm auf ihr
nicht übersetzen.

Wenn dir 16 Bits ausreichen, es dir aber egal ist, wieviel es
wirklich sind, dann solltest du entweder uint_fast16_t (mindestens
16 Bits, aber möglichst schnelle oder einfache Verarbeitung) oder
uint_least16_t (mindestens 16 Bits, aber speichersparend) nehmen.
Auf einem ARM dürfte uint_fast16_t ein 32-bit-Integer sein, da es
schneller/einfacher ist, auf der 32-bit-Maschine gleich damit zu
arbeiten (keine Maskierung etc. nötig).  Der uint_fast16_t dagegen
dürfte dort tatsächlich 16 Bits sein.  Auf einer Maschine, die gar
keine 16-bit-Zahlen darstellen kann (einige ältere DSPs werden gern
als Beispiel angeführt) gibt es hingegen keinen uint16_t (die Maschine
kann das nicht), und der uint_least16_t hat 32 Bits.

Jörg Wunsch schrieb:
> Auf einem ARM dürfte uint_fast16_t ein 32-bit-Integer sein, da es
> schneller/einfacher ist, auf der 32-bit-Maschine gleich damit zu
> arbeiten (keine Maskierung etc. nötig).  Der uint_fast16_t dagegen
> dürfte dort tatsächlich 16 Bits sein.

In der Redlib (arm-none-eabi-gcc, cortex-m3) sind sowohl für 
int_fast8_t, uint_fast8_t als auch für die entsprechenden 16-Bit 
Fast-Typen jeweils 32-Bit Integer definiert.

Ich habe mich auch verschrieben: im zweiten Satz oben waren die
“least”-Datentypen gemeint, also:

„Der uint_least16_t dagegen dürfte dort tatsächlich 16 Bits sein.“