From: Paul Eggert Date: Mon, 26 Feb 2007 07:43:43 +0000 (+0000) Subject: * README: Document signed integer overflow situation more X-Git-Tag: cvs-readonly~963 X-Git-Url: http://erislabs.org.uk/gitweb/?a=commitdiff_plain;h=10a617319435e5050434a864c2934967ebe4ac2f;p=gnulib.git * README: Document signed integer overflow situation more accurately. --- diff --git a/ChangeLog b/ChangeLog index 6fc9effd7..f85a9c3a1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2007-02-25 Paul Eggert + + * README: Document signed integer overflow situation more + accurately. + 2007-02-25 Bruno Haible * lib/vasnprintf.c (VASNPRINTF): Fix estimate of size needed for a diff --git a/README b/README index 8ab02c327..ba838e21a 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.