summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorPaul Eggert <eggert@cs.ucla.edu>2007-02-26 07:43:43 +0000
committerPaul Eggert <eggert@cs.ucla.edu>2007-02-26 07:43:43 +0000
commit10a617319435e5050434a864c2934967ebe4ac2f (patch)
treee20fcf86aa4d9a4c6d4dfd6b667254a8b24d15e0 /README
parenta7b66f7ce60806e824c73ae8dd97b3316ca880c0 (diff)
downloadgnulib-10a617319435e5050434a864c2934967ebe4ac2f.tar.gz
* README: Document signed integer overflow situation more
accurately.
Diffstat (limited to 'README')
-rw-r--r--README28
1 files changed, 24 insertions, 4 deletions
diff --git a/README b/README
index 8ab02c327e..ba838e21a7 100644
--- a/README
+++ b/README
@@ -141,10 +141,30 @@ than 'long'. POSIX 1003.1-2001 and the GNU coding standards both
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.