Re: inttypes.h incompatibility with iostream [#5060]

[Michael Cahill]

Hi Paul,

Keith has asked me to follow up on this.

> > > 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.

> Is this a known glibc bug?  If not, could you please report it?

I've read through the latest glibc Changelog and it has now been fixed.
This problem was only in the development version of glibc for a about a
month, but unfortunately that's when Mandrake picked their base for 8.1.
What made this worse was that in this case they didn't even hint that
they were using a development version (as they do by calling gcc 2.96).

RedHat 7.2 also uses a development version but from a week later, and by
then this problem was fixed. Mandrake haven't released an updated glibc,
so this will bite some folks.

> Let's try to reproduce the problem in the C language only.
> Do you get the same problem with this program?
> 
>   #include <inttypes.h>
>   #include <wchar.h>
>
> How about this program?
>
>   #include <wchar.h>
>   #include <inttypes.h>

Both of these have more or less the same problem (in the first case, the
problem shows up in wchar.h, but it's the same cause). This only occurs
when they are compiled with g++ -O, not with gcc (regardless of
optimization level).

There is a combination of factors at work - what ends up happening with
g++ is that there is a __gwchar_t typedef in inttypes.h that ends up not
assignment compatible with wchar_t under the stricter C++ casting rules.
The offending inlined code is only included with optimization turned on.

> Do you get the same problem with the above two programs if you
> substitute stdint.h for inttypes.h?

No - this only happens with inttypes.h - there are no function
prototypes in stdint.h, only typedefs and #defines. The fixed glibc adds
a special case to inttypes.h for C++.

So, where to from here? Should we make the configure change to force
ac_cv_header_inttypes_h to "no" in this case, or does this belong in
autoconf?

Michael.