Re: AC_TYPE_LONG_LONG_INT

[Bruno Haible]

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],