they're not quirky types in the least...
But much C code is bringing in library headers which contain their author's own pet choices for these, which inevitably are not the same and the result is extremely confusing when you have that in play as well as the stdint.h ones.
The kernel contains a mixture of "pet" types like u32 and stdint ones, it's already confusing.
He also does make a "crazy" choice later to call his string class "s8" which clashes with his nomenclature here.
How?
I beg to disagree. In D:
byte - 8 bits
short - 16 bits
int - 32 bits
long - 64 bits
Lest we forget: https://web.archive.org/web/20170403130829/http://www.bobbem...
stdint already has that covered though: (u)int128_t
ubyte - 8 bits
ushort - 16 bits
uint - 32 bits
ulong - 64 bits
ucent - 128 bits
float - 32 bits
double - 64 bits
real - maximum precision hardware allows (80 bits on x87).Or, you know, we could just name them all by bit length and completely future-proof this system.
Of course, none of it worked on 32 bit machines because the programmers had never written 32 bit code before and did the portability measures all wrong.
But they are buggy (correct code cannot depend on the sign of `char`), which is usually the result of typedefing primitive types to save typing 3 characters on each use.