On Sun, 21 Oct 2007 18:50:57 +0200, Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Paul, > > Paul Eggert wrote on 2007-10-16: > > Thanks for verifying this. I have started by installing the following > > fix to Autoconf, and will follow up on gnulib shortly. > > > > 2007-10-16 Paul Eggert <[EMAIL PROTECTED]> > > > > Check for 64-bit int errors in HP-UX 10.20 preprocessor. > > It exists also in the HP-UX 11.00 preprocessor. > > > Problem reported by H.Merijn Brand in > > <http://lists.gnu.org/archive/html/bug-tar/2007-10/msg00018.html>. > > * lib/autoconf/types.m4 (AC_TYPE_LONG_LONG_INT): > > (AC_TYPE_UNSIGNED_LONG_LONG_INT): > > Check that preprocessor handles 64-bit ints, too. > > The effect is that one of these tests says yes, and the other says no. > Using the stdint.h from gnulib, one then has this: > > $ cat foo.c > #include "config.h" > #include <stdio.h> > #include <stdint.h> > uint64_t uu; > int64_t ii; > int main () > { > fprintf(stderr, "intmax_t size = %d\n", sizeof (intmax_t)); > fprintf(stderr, "uintmax_t size = %d\n", sizeof (uintmax_t)); > fprintf(stderr, "int64_t size = %d\n", sizeof (int64_t)); > fprintf(stderr, "uint64_t size = %d\n", sizeof (uint64_t)); > } > $ cc -Ae -O -I.. -I. foo.c libgnu.a > $ ./a.out > intmax_t size = 8 > uintmax_t size = 4 > int64_t size = 8 > uint64_t size = 8 > > Three things are not good here: > 1) sizeof (uintmax_t) < sizeof (intmax_t). > 2) sizeof (uintmax_t) < sizeof (uint64_t). > 3) sizeof (uintmax_t) < 8. > > 1) is bad because much code assumes that every signed int can be losslessly > casted into its corresponding unsigned counterpart. Also a lot of code > assumes that sizeof (uintmax_t) == sizeof (intmax_t). > One such code is gnulib's vasnprintf: it assumes that %jd and %ju take > as argument an integer of the same size. In this situation it does not do > so any more, and the unit test of the 'fprintf-posix' module fails. > > 2) is bad because a lot code assumes that every unsigned scalar integer type > can be losslessly casted to uintmax_t. > > 3) is bad because ISO C 99 requires the existence of an uint_least64_t type; > thus 64-bit types should be commonplace. > > So the change fixed one problem but opened up three other problems. > > What are the options? > > A) Accept the fact that although 64-bit types may be known to the compiler, > they may not portably be used in preprocessor expressions. > This means: > - In the autoconf tests: undo the last change. > - In gnulib's stdint.h and inttypes.h: Compare the values of UINTMAX_MAX > etc. at configure time, rather than at compile time in the preprocessor. > > B) Turn off the 64-bit types of HP-UX 11 cc. That would be too generic. HP-UX 11.11 (11iv1) and 11.23 are much more reliable in 64bit world than 11.00 and 10.20. 10.20 isn't expected to do any 64bit issues correctly at all. > This means: > - Change AC_TYPE_LONG_LONG_INT so that it says "no" whenever > AC_TYPE_UNSIGNED_LONG_LONG_INT says "no". > - Add a "#define int64_t unusable_int64_t" > and "#define uint64_t unusable_uint64_t" > to config.h, also as part of AC_TYPE_LONG_LONG_INT and > AC_TYPE_UNSIGNED_LONG_LONG_INT. > > C) Some other option I'm missing? I for sure would go for A). -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11, & 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org http://mirrors.develooper.com/hpux/ http://www.test-smoke.org http://www.goldmark.org/jeff/stupid-disclaimers/
