bug-gnulib
[Top][All Lists]
Advanced

[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;




reply via email to

[Prev in Thread] Current Thread [Next in Thread]