The stdtypes utility attempts to generate a header file, called "stdtypes.h", which defines several fixed-sized types correctly for the host platform. This header file can then be referenced from C source files so that these types can be used to more easily develop portable C code. For instance, the size of "long" typed integers is different on most i386 and PowerPC platforms than it is on most MIPS-IV or Alpha platforms, but the "word64" type is a 64- bit unsigned integer on all platforms which support a 64-bit type. Using the explicitly-sized types defined in stdtypes.h allows the programmer certain luxuries, like using an integer typed variable to store a pointer function value (using the "fpint" type). It also makes it much easier for different platforms to share data in files or over a network. The files included in this tarball are: Makefile -- the makefile for the stdtypes utility README -- the document you are reading now stdtypes.c -- the source code to the stdtypes utility stdtypes.h -- an example stdtypes.h, generated by stdtypes To build the utility, just type "make", or do it by hand via "cc -o stdtypes stdtypes.c". To generate the stdtypes.h file, run the utility, eg "./stdtypes". It will generate a little spurious output on stdout, and create a "stdtypes.h" file in the current directory (or die trying). The "stdtypes.h" file can then be either copied to /usr/include/ or to application-specific include directories (I do both; hopefully someday checking for /usr/includes/stdtypes.h will be a standard step in autoconf). --------------------------------------------------------------------- The features implemented in this version (1.01) of stdtypes are: STDTYPES_VER A #define'd integer constant, equal to stdtypes version * 100. The entire header file is "wrapped" with "#ifndef STDTYPES_VER", so that stdtypes.h can be #include'd multiple times without error. LEN_CHAR LEN_SHORT LEN_LONG LEN_INT LEN_PTR LEN_FPTR LEN_LONG_LONG Some #define'd integer constants, redundant really but stuck in the file nonetheless. LITENDIAN or BIGENDIAN #define'd (no value) depending on the byte order of the host machine. A stdtypes.h generated on a big-endian host will have "BIGENDIAN" defined, while one on a little-endian host will have "LITENDIAN" defined. ENDIANNESS #define'd value encoding the byte order of the host, very handy to pass to a switch statement, and a portable way to communicate to a remote host what the local host's byte order is. In v1.01, valid ENDIANNESS values are: ((byte)(0x00)) for little-endian ((byte)(0x01)) for big-endian NO_8_BIT NO_16_BIT NO_32_BIT NO_64_BIT NO_128_BIT #define'd (no value) if no type of the given size is supported on the host platform. In practice, I expect 8, 16, 32, and 64 bit types to be supported on all significant hosts between now and the technological singularity. bool byte word8 Unsigned typedef'd integer types guaranteed to be 8 bits long. word16 word32 word64 word128 Unsigned typedef'd integer types guaranteed to be of the given size (in bits). At the time of this release, most platforms did not support a 128 bit type. If the host does not support a 128 bit type, the word128 typedef will be absent and NO_128_BIT will be #define'd (with no value). Programmers should therefore be cautious using the word128 and int128 types, and encapsulate any use of the int128 type with use of "#ifdef NO_128_BIT" preprocessor directives. int8 int16 int32 int64 int128 Signed typedef'd integer types guaranteed to be of the given size (in bits). At the time of this release, most platforms did not support a 128 bit type. If the host does not support a 128 bit type, the word128 typedef will be absent and NO_128_BIT will be #define'd (with no value). Programmers should therefore be cautious using the word128 and int128 types, and encapsulate any use of the int128 type with use of "#ifdef NO_128_BIT" preprocessor directives. ptrint ptrword fptrint fptrword Typedef'd integer types (ints are signed, words are unsigned) that are guaranteed to be the size of the host's native pointer (ptrint, ptrword) and function pointer (fptrint, fptrword) types. --------------------------------------------------------------------- Improvements over previous versions: v1.01: * This README file is new, as is the Makefile. * Adjusted the size of cptr[], which was too small and resulted in buffer overflow (which didn't cause any ill effects on any of the systems I tried it on, which is why it took so long to fix). * Added the ENDIANNESS feature. v1.00: * First public release. --------------------------------------------------------------------- Things to do in future versions: It really should support more endianness types. Right now it does not correctly detect PDP byte order, for instance. I'd like to duplicate some of the functionality of autoconf within the stdtypes utility, so that building an stdtypes-using application on a host that already has a valid /usr/include/stdtypes.h installed could skip running a (often time-consuming) "configure" script. Should support floatingpoint types eventually, but I haven't gotten around to it because I almost never use floatingpoint types. --------------------------------------------------------------------- A short rant: I know that this duplicates much of the functionality of inttypes.h and the similar header defined by the latest ANSI C specification, but it also does some things that inttypes.h does not, this utility can evolve a lot faster and more intelligently as a separate project than it would as part of a larger specification effort, and I trust my own ability to maintain, develop, and moderate such an effort more than I trust some committee, so bleah. --------------------------------------------------------------------- Concluding rant: In my opinion, types of the format int<##>/word<##> should be supported directly in the language the application is written in. The compiler could generate code that "just does the right thing" with variables declared with any bit size, using natively supported types in whatever manner is most optimal for implementing the functionality desired. This would cause compute-intensive applications to take a performance hit when the host did not natively support the declared type, but would be a tremendous boon to code portability, especially for oddball systems (eg, embedded DSP processors). Such a language would allow applications to be written using types native to that oddball system (eg, int12, or int24), and guarantee that the behaviour of that application would remain unchanged when recompiled on a host that supports only different native types. I'd like to implement a compiler for such a language eventually. I consider the stdtypes utility to be a stopgap measure for making portable C development easier until I can get around to making that compiler.