> Date: Fri, 7 Dec 2001 15:34:56 -0500 (EST) > From: Keith Bostic <[EMAIL PROTECTED]>
> > Here's an idea for fixing things. Very early in 'configure' you check > > for the problem, and if so, you inform autoconf that there is no > > inttypes.h. > > How would I do that? Explicitly set ac_cv_header_inttypes_h to "no"? Pretty much, yes. > > Perhaps we should fix this within Autoconf, by modifying Autoconf by > > adding wchar.h to the standard headers, and check for it before > > checking for inttypes.h (as wchar.h is the more senior include file). > > That would be an easy change to make. But I'd like to know the > > answers to the above questions before advocating such a change. > > Agreed -- Michael should be able to let you know soon. OK. Looking forward to the info. > So, perhaps we should just include <stdint.h> and forget about > <inttypes.h>? No, because: > Are there platforms that have <inttypes.h> but not <stdint.h>? Yes. Solaris 8, for example. In my experience, <inttypes.h> is a bit more reliable than <stdint.h> because it has been around longer. <stdint.h> is a creation of the C99 committee, whereas <inttypes.h> exists on many pre-C99 platforms. C99 says that freestanding C99 platforms must have <stdint.h> but may lack <inttypes.h>, which is the only reason I'd worry about <stdint.h> at all. I've never used such a platform, but I wouldn't be surprised to come across one someday. > my guess is that turning off autoconf's use of <inttypes.h> and > <stdint.h> durign configuration, and then dropping them from our > created include file, would be a good solution -- if we can easily > convince autoconf that's what we want to do. OK, but I would suppress <inttypes.h> and/or <stdint.h> only if you detect the header incompatibility. I think this will give you better results on future platforms. On some platforms, for example, I wouldn't be surprised if intmax_t is wider than long long.
