[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rethinking #if and 64-bit numbers (inttypes.h on Sun platforms)
From: |
Paul Eggert |
Subject: |
Re: rethinking #if and 64-bit numbers (inttypes.h on Sun platforms) |
Date: |
Tue, 13 Nov 2007 00:17:56 -0800 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) |
Bruno Haible <address@hidden> writes:
> Possibly also in autoconf.texi section "Portable C and C++ Programming"?
I installed this into Autoconf:
2007-11-13 Paul Eggert <address@hidden>
Don't worry about preprocessor when testing long long.
See: http://lists.gnu.org/archive/html/bug-gnulib/2007-11/msg00075.html
* doc/autoconf.texi (Preprocessor Arithmetic): New section.
(AC_TYPE_LONG_LONG_INT, AC_TYPE_UNSIGNED_LONG_LONG_INT):
These no longer check for preprocessor flaws.
* lib/autoconf/types.m4 (_AC_TYPE_LONG_LONG_SNIPPET):
Do not check for preprocessor flows.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 8633fa2..12eef55 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -518,6 +518,7 @@ Portable C and C++ Programming
* Varieties of Unportability:: How to make your programs unportable
* Integer Overflow:: When integers get too large
+* Preprocessor Arithmetic:: @code{#if} expression problems
* Null Pointers:: Properties of null pointers
* Buffer Overruns:: Subscript errors and the like
* Volatile Objects:: @code{volatile} and signals
@@ -6123,8 +6124,10 @@ range or precision than the @code{double} type, define
@acindex{TYPE_LONG_LONG_INT}
@cvindex HAVE_LONG_LONG_INT
If the C compiler supports a working @code{long long int} type, define
address@hidden This test also validates that the
-preprocessor can handle integers with the @samp{LL} suffix.
address@hidden However, this test does not test
address@hidden long int} values in preprocessor @code{#if} expressions,
+because too many compilers mishandle such expressions.
address@hidden Arithmetic}.
@end defmac
@defmac AC_TYPE_MBSTATE_T
@@ -6261,12 +6264,10 @@ exists.
@acindex{TYPE_UNSIGNED_LONG_LONG_INT}
@cvindex HAVE_UNSIGNED_LONG_LONG_INT
If the C compiler supports a working @code{unsigned long long int} type,
-define @code{HAVE_UNSIGNED_LONG_LONG_INT}. This test also validates
-that the preprocessor can handle integers with the @samp{ULL} suffix.
-However, portable code cannot mix @code{unsigned long int} and
address@hidden long long int} types in preprocessor expressions,
-since the @acronym{HP-UX} 11.00 preprocessor does not use consistent
-promotion rules.
+define @code{HAVE_UNSIGNED_LONG_LONG_INT}. However, this test does not test
address@hidden long long int} values in preprocessor @code{#if} expressions,
+because too many compilers mishandle such expressions.
address@hidden Arithmetic}.
@end defmac
@node Generic Types
@@ -16291,6 +16292,7 @@ more information.
@menu
* Varieties of Unportability:: How to make your programs unportable
* Integer Overflow:: When integers get too large
+* Preprocessor Arithmetic:: @code{#if} expression problems
* Null Pointers:: Properties of null pointers
* Buffer Overruns:: Subscript errors and the like
* Volatile Objects:: @code{volatile} and signals
@@ -16656,6 +16658,20 @@ of these two values typically yields the same signal
on these CPUs,
even though the C standard requires @code{INT_MIN % -1} to yield zero
because the expression does not overflow.
address@hidden Preprocessor Arithmetic
address@hidden Preprocessor Arithmetic
address@hidden preprocessor arithmetic
+
+In C99, preprocessor arithmetic, used for @code{#if} expressions, must
+be evaluated as if all signed values are of type @code{intmax_t} and all
+unsigned values of type @code{uintmax_t}. Many compilers are buggy in
+this area, though. For example, as of 2007, Sun C mishandles @code{#if
+LLONG_MIN < 0} on a platform with 32-bit @code{long int} and 64-bit
address@hidden long int}. Also, some older preprocessors mishandle
+constants ending in @code{LL}. To work around these problems, you can
+compute the value of expressions like @code{LONG_MAX < LLONG_MAX} at
address@hidden rather than at @code{#if}-time.
+
@node Null Pointers
@section Properties of Null Pointers
@cindex null pointers
diff --git a/lib/autoconf/types.m4 b/lib/autoconf/types.m4
index 9c38a7b..6f03738 100644
--- a/lib/autoconf/types.m4
+++ b/lib/autoconf/types.m4
@@ -475,14 +475,7 @@ You should use `AC_TYPE_LONG_DOUBLE' or
`AC_TYPE_LONG_DOUBLE_WIDER' instead.]
AC_DEFUN([_AC_TYPE_LONG_LONG_SNIPPET],
[
AC_LANG_PROGRAM(
- [[/* Test preprocessor. */
- #if ! (-9223372036854775807LL < 0 && 0 < 9223372036854775807ll)
- error in preprocessor;
- #endif
- #if ! (18446744073709551615ULL <= -1ull)
- error in preprocessor;
- #endif
- /* Test literals. */
+ [[/* Test literals. */
long long int ll = 9223372036854775807ll;
long long int nll = -9223372036854775807LL;
unsigned long long int ull = 18446744073709551615ULL;
- Re: rethinking #if and 64-bit numbers (inttypes.h on Sun platforms),
Paul Eggert <=