Paul Eggert wrote on 2006-07-05:
> > 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?
That is indeed my fear. The user of the vasnprintf function may see that
'long long' exists and decide to use "%lld" in his format strings. If
'long long' exists but has only 32 bits (and thus AC_TYPE_LONG_LONG_INT
will not be defined), we have to treat "ll" like "l", rather than calling
abort() or similar.
> 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.
Probably.
> 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.
The same point would hold for 'long double' - yet on some platforms
'long double' is still the same as 'double'...
I've now verified the oldest platforms I've access to, and they all have
a compiler that groks 'long long' - except MSVC, which gives an error
on it. Also, the change of semantics of AC_TYPE_LONG_LONG_INT in
autoconf-2.60 didn't cause bug reports. So, I'm now also buying into
AC_TYPE_LONG_LONG_INT.
I'm also adding some comments to the m4 macros.
Bruno
diff -c -3 -r1.9 longlong.m4
*** m4/longlong.m4 22 Aug 2006 21:16:36 -0000 1.9
--- m4/longlong.m4 11 Oct 2006 15:35:56 -0000
***************
*** 1,4 ****
! # longlong.m4 serial 7
dnl Copyright (C) 1999-2006 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
--- 1,4 ----
! # longlong.m4 serial 8
dnl Copyright (C) 1999-2006 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
***************
*** 10,15 ****
--- 10,19 ----
# This fixes a bug in Autoconf 2.60, but can be removed once we
# assume 2.61 everywhere.
+ # Note: If the type 'long long int' exists but is only 32 bits large
+ # (as on some very old compilers), AC_TYPE_LONG_LONG_INT will not be
+ # defined. In this case you can treat 'long long int' like 'long int'.
+
AC_DEFUN([AC_TYPE_LONG_LONG_INT],
[
AC_CACHE_CHECK([for long long int], [ac_cv_type_long_long_int],
diff -c -3 -r1.10 ulonglong.m4
*** m4/ulonglong.m4 2 Jul 2006 06:49:07 -0000 1.10
--- m4/ulonglong.m4 11 Oct 2006 15:35:56 -0000
***************
*** 1,4 ****
! # ulonglong.m4 serial 5
dnl Copyright (C) 1999-2006 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
--- 1,4 ----
! # ulonglong.m4 serial 6
dnl Copyright (C) 1999-2006 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
***************
*** 10,15 ****
--- 10,20 ----
# This fixes a bug in Autoconf 2.60, but can be removed once we
# assume 2.61 everywhere.
+ # Note: If the type 'unsigned long long int' exists but is only 32 bits
+ # large (as on some very old compilers), AC_TYPE_UNSIGNED_LONG_LONG_INT
+ # will not be defined. In this case you can treat 'unsigned long long int'
+ # like 'unsigned long int'.
+
AC_DEFUN([AC_TYPE_UNSIGNED_LONG_LONG_INT],
[
AC_CACHE_CHECK([for unsigned long long int],
