Bug#582698: libc6-dev: INTMAX_MAX definition yields build failure in 32-bit C90 mode though intmax_t is supported
Package: libc6-dev
Version: 2.10.2-8
Severity: minor
The INTMAX_MAX definition in /usr/include/stdint.h yields build
failure in 32-bit C90 mode (x86_64 machines with the -m32 gcc
switch and x86 machines).
$ cat intmax-test.c
#include stdint.h
int main (void)
{
intmax_t x;
x = INTMAX_MAX;
return 0;
}
$ gcc -m32 -ansi -pedantic-errors intmax-test.c
intmax-test.c:5:1: error: use of C99 long long integer constant
Support for intmax_t is not expected to work in C90 mode, but in
such a case, the failure should probably occur on the stdint.h
inclusion or intmax_t x; line. Otherwise I wonder whether the
failure on INTMAX_MAX is intended and/or fixable.
The consequence of this inconsistency is the following: for a
software that uses intmax_t optionally (such as MPFR), as intmax_t
works fine, autoconf detects that intmax_t is supported, but then
the build of the software fails if it uses INTMAX_MAX.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6-dev depends on:
ii libc-dev-bin 2.10.2-8 Embedded GNU C Library: Developmen
ii libc6 2.10.2-8 Embedded GNU C Library: Shared lib
ii linux-libc-dev2.6.32-12 Linux support headers for userspac
Versions of packages libc6-dev recommends:
ii gcc [c-compiler] 4:4.4.3-1 The GNU C compiler
ii gcc-4.1 [c-compiler] 4.1.2-29 The GNU C compiler
ii gcc-4.3 [c-compiler] 4.3.4-10 The GNU C compiler
ii gcc-4.4 [c-compiler] 4.4.4-1The GNU C compiler
Versions of packages libc6-dev suggests:
ii glibc-doc 2.10.2-8 Embedded GNU C Library: Documentat
ii manpages-dev 3.24-1 Manual pages about using GNU/Linux
-- no debconf information
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100522204951.ga17...@xvii.vinc17.org
Bug#582698: libc6-dev: INTMAX_MAX definition yields build failure in 32-bit C90 mode though intmax_t is supported
On Sat, May 22, 2010 at 10:49:51PM +0200, Vincent Lefevre wrote:
The INTMAX_MAX definition in /usr/include/stdint.h yields build
failure in 32-bit C90 mode (x86_64 machines with the -m32 gcc
switch and x86 machines).
$ cat intmax-test.c
#include stdint.h
int main (void)
{
intmax_t x;
x = INTMAX_MAX;
return 0;
}
$ gcc -m32 -ansi -pedantic-errors intmax-test.c
intmax-test.c:5:1: error: use of C99 long long integer constant
Support for intmax_t is not expected to work in C90 mode, but in
such a case, the failure should probably occur on the stdint.h
inclusion or intmax_t x; line. Otherwise I wonder whether the
failure on INTMAX_MAX is intended and/or fixable.
The consequence of this inconsistency is the following: for a
software that uses intmax_t optionally (such as MPFR), as intmax_t
works fine, autoconf detects that intmax_t is supported, but then
the build of the software fails if it uses INTMAX_MAX.
Is this patch what you want?
--- a/sysdeps/generic/stdint.h
+++ b/sysdeps/generic/stdint.h
@@ -236,15 +236,23 @@
# define UINTPTR_MAX (4294967295U)
# endif
-
+# if __WORDSIZE == 64
/* Minimum for largest signed integral type. */
-# define INTMAX_MIN (-__INT64_C(9223372036854775807)-1)
+# define INTMAX_MIN (-__INT64_C(9223372036854775807)-1)
/* Maximum for largest signed integral type. */
-# define INTMAX_MAX (__INT64_C(9223372036854775807))
+# define INTMAX_MAX (__INT64_C(9223372036854775807))
/* Maximum for largest unsigned integral type. */
-# define UINTMAX_MAX (__UINT64_C(18446744073709551615))
+# define UINTMAX_MAX (__UINT64_C(18446744073709551615))
+# else
+/* Minimum for largest signed integral type. */
+# define INTMAX_MIN (-__INT32_C(2147483647)-1)
+/* Maximum for largest signed integral type. */
+# define INTMAX_MAX (__INT32_C(2147483647))
+/* Maximum for largest unsigned integral type. */
+# define UINTMAX_MAX (__UINT32_C(4294967295U))
+# endif
/* Limits of other integer types. */
Bug#582698: libc6-dev: INTMAX_MAX definition yields build failure in 32-bit C90 mode though intmax_t is supported
On 2010-05-22 21:36:14 +, Clint Adams wrote: Is this patch what you want? No, that would be incorrect, as when __WORDSIZE isn't 64, /usr/include/stdint.h defines: __extension__ typedef long long int intmax_t; __extension__ typedef unsigned long long int uintmax_t; i.e. intmax_t and uintmax_t are still 64 bits. INTMAX_MAX and so on should match the intmax_t and uintmax_t definitions. BTW, notice that the fact that intmax_t and uintmax_t are 64 bits is against the principle that unsigned long is the largest integer type in C90. So, perhaps this shouldn't be hidden by __extension__ above (this would solve the problem in another way). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2010051625.gg1...@xvii.vinc17.org
Bug#582698: [patches] Re: Bug#582698: libc6-dev: INTMAX_MAX definition yields build failure in 32-bit C90 mode though intmax_t is supported
The natural approach to fix this would seem to be to use __extension__ in the definitions of __INT64_C and __UINT64_C and the associated INT64_C etc. macros, when those use long long suffixes. That should avoid the failures for strict C90 when using a compiler recent enough to have the (partial) fix for GCC PR 7263. I see no reason this should be unacceptable for FSF glibc (though one can never entirely predict how the FSF glibc maintainers will react to a given patch). -- Joseph S. Myers jos...@codesourcery.com -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1005230029190.15...@digraph.polyomino.org.uk
