bug-gnulib
[Top][All Lists]
Advanced

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

Re: simplification rewrite of stdint module installed into gnulib


From: Paul Eggert
Subject: Re: simplification rewrite of stdint module installed into gnulib
Date: Tue, 04 Jul 2006 22:20:41 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Bruno Haible <address@hidden> writes:

>  -- Macro: AC_TYPE_LONG_LONG_INT
>      If the C compiler supports a working `long long int' type, define
>      `HAVE_LONG_LONG_INT'.
>
> Requiring at least 64 bits would be a change in semantics.

Yes.  Whether this is a good thing depends on what one means by
"working".

For quite some time, the coreutils/gnulib long-long checker has
rejected a 'long long' implementation that does not support long-long
division or remainder (which are limitations of some pre-C99
implementations).  So if we have code that relies on HAVE_LONG_LONG
meaning "the type 'long long' exists", such code is already broken.

> The difference matters: vasnprintf needs to understand the "ll" or "L" size
> specifier, if the platform has a 'long long' type, regardless whether it
> is 64-bit (ISO C 99 compliant) or not (likely only 32-bit).

I must be missing something, since programs that don't think "long
long" works shouldn't use the "ll" size specifier.  And portable
programs should use "L" only for floating-point conversion.

Or is the problem that different parts of your program might disagree
about whether 'long long' works?  Surely the solution is to get on the
same page with respect to whether 'long long' works, as this would in
general be needed in in any event.

> If your change doesn't introduce a bug in vasnprintf, as I can tell
> after looking at the code for 10 minutes, it's because the way the
> code is written and by luck.

I hope our luck holds.  But how serious is the issue?  What platforms
have 32-bit long long?  Traditionally, 'long long' has always been at
least 64 bits.  That was the point of 'long long', and by now many
applications must assume it, so I suspect that in practice we will
solve more problems than we cure by requiring 'long long' to be 64
bits.

For what it's worth, the gnulib macro was originally intended to check
for 64-bittedness as well (hence the 63-bit shift).  I think that
check was inadvertently dropped when it was changed from a run-time to
a link-time test.




reply via email to

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