From: Andrew R. <and...@us...> - 2005-04-15 11:46:45
|
On Sun, Apr 10, 2005 at 01:39:59AM -0500, mj...@ga... wrote: > Alan W. Irwin writes: > > And thus ends the (nearly) half-year experiment of using PLINT==long. :) > > You posited at the time that I'd reversed myself on the issue at least once -- > I frankly couldn't remember at the time but now consider it likely that it did > have something to do with 64 bit architectures. I've been back in 32 bit land > for the last few years so it didn't occur to me this time around. > > Anyway, this looks like a fine way to go, and as vendors increasingly include > stdint.h, it should be a no-brainer (aside: stdint.h is part of the C99 > standard, but I've read that conformance has been rather slow to arrive). And > if vendor-specific treatment is required, it can just be added to the #else > stanza as needed. > > Apparently the following typedefs are guaranteed, for a conforming stdint.h: > typedef signed char int8_t; > typedef signed int int16_t; > typedef signed long int32_t; > typedef unsigned char uint8_t; > typedef unsigned int uint16_t; > typedef unsigned long uint32_t; > > Also I found the following article to be informative: > http://www.embedded.com/shared/printableArticle.jhtml?articleID=17300092 I've only just picked up this thread having been away. To me it seems this is the way to go though. Using stdint.h should also avoid possible problems with other 64 bit issues in the future. I can for example think of issues to do with metafiles which might not be portable. For now I suggest a configure check for stdint.h. At least for 64bit AMD / itanium systems we can be reasonably sure of a modern C compiler. For other systems the current status quo is probably sufficient. Andrew |