+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:
+
+ * 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.
+
+ * 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.