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
