-
-GNULib code should port without problem to new hosts, e.g., hosts
-conforming to C99 or to recent POSIX standards. Hence GNUlib code
-should avoid using constructs (e.g., undeclared functions return
-'int') that do not conform to C99. However, the GNU coding standards
-allow one departure from strict C99: GNUlib code can assume that
-standard internal types like size_t are no wider than 'long'.
+You can work around some of these problems by requiring the relevant
+modules, e.g., the GNULib 'free' module supplies a conforming 'free'.
+
+The GNU coding standards allow one departure from strict C99: GNULib
+code can assume that standard internal types like size_t are no wider
+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.
+
+ * There are no "holes" in integer values: all the bits of an integer
+ contribute to its value in the usual way.
+
+ * If two nonoverlapping objects have sizes S and T represented as
+ size_t values, then S + T cannot overflow. This assumption is true
+ for all practical hosts with flat address spaces, but it is not
+ always true for hosts with segmented address spaces.
+
+ * If an existing object has size S, and if T is sufficiently small
+ (e.g., 8 KiB), then S + T cannot overflow. Overflow in this case
+ would mean that the rest of your program fits into T bytes, which
+ can't happen in realistic flat-address-space hosts.
+
+ * Objects with all bits zero are treated as 0 or NULL. For example,
+ memset (A, 0, sizeof A) initializes an array A of pointers to NULL.
+
+ * Adding zero to a null pointer does not change the pointer.
+ For example, 0 + (char *) NULL == (char *) NULL.
+
+The above assumptions are not required by the C or POSIX standards but
+hold on all practical porting targets that we're familiar with. If
+you have a porting target where these assumptions are not true, we'd
+appreciate hearing of any fixes. We need fixes that do not increase
+runtime overhead on standard hosts and that are relatively easy to
+maintain.
+
+With the above caveats, GNULib code should port without problem to new
+hosts, e.g., hosts conforming to C99 or to recent POSIX standards.
+Hence GNULib code should avoid using constructs (e.g., undeclared
+functions return 'int') that do not conform to C99.