From: Steve Summit (scs@eskimo.com)
Date: Fri Sep 22 2006 - 19:44:55 CDT
I wrote:
>>> Please don't do this! Please do
>>> #include <stdint.h>
>>> instead.
And almost immediately Ken Whistler and Richard Wordingham replied:
>> Well, sure, *if* your compilers are all completely up-to-date.
and
> It will only work if your compiler acknowledges the C99 standard.
> The ones I use don't claim to comply, and the one I use at home would
> simply fail to compile the above.
On the one hand, not all the compilers I use are C99-compatible,
either. But on the other hand, C99 has been out for *seven
years* now, so presuming its features is not completely out of
the question. (And in the case at hand, the <inttypes.h> header
had been in circulation even before C99 came out.)
But in this case, even if your compilers aren't all
C99-compatible, its prescriptions provide a very clear
implementation path. First, begin weeding out all your ad-hoc
project-specific int16 and Uint32 typedef names, and standardize
on uint16_t and uint32_t et al.
Next, if at all possible, move the question of <stdint.h>'s
presence out of your source code and into your build procedure.
What I always do for pre-ANSI compilers lacking ANSI-standard
headers is to provide my own copies of the standard headers
(not necessarily wholly complete, but providing the definitions
my code depends on), and to cause the compiler to additionally
search for my headers in addition to the standard ones, using
a compiler switch such as -I or the like. This ends up being
compiler-specific and a bit of a nuisance, it's true, but it's no
more compiler-specific or nuisancey than explicit #ifdefs in the
source code would be, and by doing it this way, you can confine
the compiler dependencies to the build procedure (which is always
going to be compiler-dependent anyway), leaving all the source
code pristine.
This archive was generated by hypermail 2.1.5 : Fri Sep 22 2006 - 19:47:13 CDT