+* Build files only if they are needed on a platform. Look at the
+ alloca and fnmatch modules for how to achieve this. If for some
+ reason you cannot do this, and you have a .c file that leads to an
+ empty .o file on some platforms (through some big #if around all the
+ code), then ensure that the compilation unit is not empty after
+ preprocessing. One way to do this is to #include <stddef.h> or
+ <stdio.h> before the big #if.
+
+Portability guidelines
+----------------------
+
+Gnulib code is intended to be portable to a wide variety of platforms,
+not just GNU platforms.
+
+Many Gnulib modules exist so that applications need not worry about
+undesirable variability in implementations. For example, an
+application that uses the 'malloc' module need not worry about (malloc
+(0)) returning NULL on some Standard C platforms; and 'time_r' users
+need not worry about localtime_r returning int (not char *) on some
+platforms that predate POSIX 1003.1-2001.
+
+Originally much of the Gnulib code was portable to ancient hosts like
+4.2BSD, but it is a maintenance hassle to maintain compatibility with
+unused hosts, so currently we assume at least a freestanding C89
+compiler, possibly operating with a C library that predates C89. The
+oldest environment currently ported to is probably SunOS 4 + GCC 1.x,
+though we haven't tested this exact combination. SunOS 4 last shipped
+on 1998-09-30, and Sun dropped support for it on 2003-10-01, so at
+some point we may start assuming a C89 library as well.
+
+Because we assume a freestanding C89 compiler, Gnulib code can include
+<float.h>, <limits.h>, <stdarg.h>, and <stddef.h> unconditionally. It
+can also include hosted headers like <errno.h> that were present in
+Unix Version 7 and are thus widely available. Similarly, many modules
+include <sys/types.h> even though it's not even in C99; that's OK
+since <sys/types.h> has been around nearly forever. <string.h> and
+<stdlib.h> were not in Unix Version 7, so they weren't universally
+available on ancient hosts, but they are both in SunOS 4 (the oldest
+platform still in relatively-common use) so Gnulib assumes them now.
+
+Even if the include files exist, they may not conform to C89.
+However, GCC has a "fixincludes" script that attempts to fix most
+C89-conformance problems. So Gnulib currently assumes include files
+largely conform to C89 or better. People still using ancient hosts
+should use fixincludes or fix their include files manually.
+
+Even if the include files conform to C89, the library itself may not.
+For example, SunOS 4's (free (NULL)) can dump core, so Gnulib code
+must avoid freeing a null pointer, even though C89 allows it.
+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.