bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

fix README to document signed integer overflow better


From: Paul Eggert
Subject: fix README to document signed integer overflow better
Date: Sun, 25 Feb 2007 23:44:37 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

I installed this:

2007-02-25  Paul Eggert  <address@hidden>

        * README: Document signed integer overflow situation more
        accurately.

--- README      29 Nov 2006 00:41:00 -0000      1.18
+++ README      26 Feb 2007 07:43:39 -0000
@@ -141,10 +141,30 @@ than 'long'.  POSIX 1003.1-2001 and the 
 require 'int' to be at least 32 bits wide, so Gnulib code assumes this
 as well.  Gnulib code makes the following additional assumptions:

- * Signed integer arithmetic is two's complement, without runtime
-   overflow checking.  This is the traditional behavior, and is
-   supported by C99 implementations that conform to ISO/IEC 10967-1
-   (LIA-1) and that define signed integer types as being modulo.
+ * With one exception noted below, signed integer arithmetic is two's
+   complement, without runtime overflow checking.  This is the
+   traditional behavior, and is supported by C99 implementations that
+   conform to ISO/IEC 10967-1 (LIA-1) and that define signed integer
+   types as being modulo.
+
+   The exception is signed loop indexes.  Here, the behavior is
+   undefined if any signed expression derived from the loop index
+   overflows.  For example, the following code contains two such
+   overflows (the "i++" and the "i + 1") and therefore has undefined
+   behavior:
+
+     int i;
+     for (i = INT_MAX - 10; i <= INT_MAX; i++)
+       if (i + 1 < 0)
+        {
+          report_overflow ();
+          break;
+        }
+
+   This exception is a concession to modern optimizing compilers,
+   which can turn the above loop into code that executes the loop body
+   11 times, even though wraparound arithmetic would cause the loop to
+   iterate forever.

  * There are no "holes" in integer values: all the bits of an integer
    contribute to its value in the usual way.




reply via email to

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