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: Bruno Haible
Subject: Re: simplification rewrite of stdint module installed into gnulib
Date: Tue, 4 Jul 2006 18:56:24 +0200
User-agent: KMail/1.9.1

Paul Eggert wrote:
>       * m4/longlong.m4 (AC_TYPE_LONG_LONG_INT): Backport from Autoconf 2.60,
>       but fix a bug, by requiring at least 64 bits.
>       * m4/ulonglong.m4 (AC_TYPE_UNSIGNED_LONG_LONG_INT): Likewise.
>       * m4/longlong.m4 (gl_AC_TYPE_LONG_LONG): Now just call
>       AC_TYPE_LONG_LONG_INT.  This macro is obsolete and will go soon.
>       * m4/ulonglong.m4 (gl_AC_TYPE_UNSIGNED_LONG_LONG) Likewise.

Well, this is a semantic change. It causes the vasnprintf, gettext, allocsa,
strtoimax and maybe other modules to ignore the 'long long' type if it has
less than 64 bits - on some older platforms that are not C99 compliant.

Likewise if you want to push this into autoconf. Autoconf documents this
macro

 -- 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. Likely to break
programs.

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

So I propose to revert longlong.m4 and ulonglong.m4 to their previous state,
and move your new macros to files longlong64.m4, ulonglong64.m4, or integrate
them into stdint.m4.

Bruno




reply via email to

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