bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: verify fails on ia64-hpux11.23 in libunistring-0.9.3


From: Gary V. Vaughan
Subject: Re: verify fails on ia64-hpux11.23 in libunistring-0.9.3
Date: Tue, 3 May 2011 14:09:56 +0700
User-agent: Mutt/1.5.20 (2009-06-14)

Hi Paul,

On Mon, May 02, 2011 at 09:24:46AM -0700, Paul Eggert wrote:
> On 05/02/11 05:09, Gary V. Vaughan wrote:
> >> example, it could be that <limits.h> (which intprops.h includes)
> >> > redefines UINT_FAST8_MAX to the wrong value.
> > That seems to me to be what is happening.  Is this something that gnulib
> > stdint.h can fix?  It looks like a stupid mistake on the part of the
> > HPUX headers.
> 
> The HPUX headers are self-consistent, no?  They define
> UINT_FAST8_MAX to UINT_MAX and uint_fast8_t to unsigned int.
> The gnulib stdint.h is also self-consistent, using unsigned
> long int instead.  The problem is that somehow they clash.

Yes that's true.

> I still don't understand fully how they clash, unfortunately.
> It appears that the problem is that the gnulib stdint.h defines
> UINT_FAST8_MAX one way, and HP-UX limits.h another.  But I don't
> see how that could happen, since gnulib stdint.h includes
> HP-UX limits.h, and then redefines UINT_FAST8_MAX.

It seems like argument packing/unpacking across any libc function
boundary that uses uint_fast8_t is going to go very wrong if gnulib
is in the habit of changing the size of types in system headers, no?

Maybe it's academic if there are no library calls that have a
uint_fast8_t argument.  I've never spotted any other gnulib code
that obviously tries to redefine system declared type sizes though,
and suspect that having it happen here is a mistake?

> Could you investigate that?

Here are the key points as I see them:

 1. HPUX always defines UINT_FAST8_MAX to 2**32-1, irrespective of
    ABI, compiler or OS release, and consistently sets the type of
    uint_fast8_t to a 32bit wide int (unsigned int) to match;
 2. HPUX defines ULONG_MAX to 2**32-1 for the 32bit (default) ABI,
    and 2**64-1 for the 64bit ABI;
 3. gnulib stdint.h redefines UINT_FAST8_MAX to ULONG_MAX, which has
    bad effects when using the 64bit ABI, not least among which is
    that the gnulib redefined ULONG_MAX valued UINT_FAST8_MAX is too
    big to fit into a uint_fast8_t;
 4. The system definition of ULONG_MAX moves from system stdint.h
    to system limits.h between hpux11.23 and hpux11.31, and the
    header inclusion order from test-stdint.c tickles this bug at
    the verify line I originally reported only on hpux11.23 because
    of that change.

However, I'm still none-the-wiser over what needs changing in gnulib
to take this into account correctly.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Attachment: pgpx3r8QemF0t.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]