uint\*_t and standards
By fintanr on May 03, 2005
After my post about getting libnjb to compile on Solaris I got a couple of comments around uint\*_t types, and why we defined uint's in the manner that we do. Mainly because the convention we use is a standard, as per Ansi C99, the Single Unix Specification (which supercedes Posix and XPG). Unfortunately all of these specs cost money to download (something of a bone of contention with me, open standards should be free to view), but the best online explanation that I can find is available in this article by Michael Barr over on O'Reilly. From that article I quote
In hindsight, it sure would have been nice if the authors of the C standard had defined some standard names and made compiler providers responsible for providing the appropriate typedef for each fixed-size integer type in a library header file. Alternatively, of course, the C standard could have specified (as Java does) that each of the types short, int, and long has a standard width on all platforms; but that can have an impact on performance, particularly on 8-bit processors that must implement 16- and 32-bit additions in multi-instruction sequences. Interestingly, it turns out that the authors of a 1999 update to the ISO C standard (hereafter "C99") did just that. It seems the ISO organization has finally put the weight of its standard behind a preferred set of names for signed and unsigned fixed-size integer data types. The newly defined type names are as follows: 8-bit: int8_t uint8_t 16-bit: int16_t uint16_t 32-bit: int32_t uint32_t 64-bit: int64_t uint64_tSo there you go. [ update - 05/05/05 ]
A couple of people have commented that you can access the Unix O3 spec here, thanks for the clarification. Anyone got a url for a C99 spec that they can point us at? [update - 07/05/05 ]
Terry Lambert pointed me at a C99 spec.