+* 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. See the documentation section "Target Platforms"
+for details.
+
+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.
+
+Currently we assume at least a freestanding C89 compiler, possibly
+operating with a C library that predates C89. The oldest environments
+currently ported to are probably HP-UX 10.20 and IRIX 5.3, though we
+are not testing these platforms very often.
+
+Because we assume a freestanding C89 compiler, Gnulib code can include
+<float.h>, <limits.h>, <stdarg.h>, and <stddef.h> unconditionally. It
+can also assume the existence of <ctime.h>, <errno.h>, <fcntl.h>,
+<locale.h>, <signal.h>, <stdio.h>, <stdlib.h>, <string.h>, and <time.h>.
+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.
+
+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, strtod and mktime have some bugs on some platforms.
+You can work around some of these problems by requiring the relevant
+modules, e.g., the Gnulib 'mktime' module supplies a working and
+conforming 'mktime'.
+
+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.
+