The GNU coding standards allow one departure from strict C: Gnulib
code can assume that standard internal types like
size_t are no
long. POSIX requires implementations to support at
least one programming environment where this is true, and such
environments are recommended for Gnulib-using applications. When it
is easy to port to non-POSIX platforms like MinGW where these types
are wider than
long, new Gnulib code should do so, e.g., by
ptrdiff_t instead of
long. However, it is not
always that easy, and no effort has been made to check that all Gnulib
modules work on MinGW-like environments.
Gnulib code makes the following additional assumptions:
unsigned intare at least 32 bits wide. POSIX and the GNU coding standards both require this.
Previously, Gnulib code sometimes assumed that signed integer arithmetic wraps around, but modern compiler optimizations sometimes do not guarantee this, and Gnulib code with this assumption is now considered to be questionable. See Integer Properties.
Although some Gnulib modules contain explicit support for the other signed integer representations allowed by the C standard (ones’ complement and signed magnitude), these modules are the exception rather than the rule. All practical Gnulib targets use two’s complement.
S + Tcannot overflow.
(char *) &O <= (char *) P && (char *) P < (char *) (&O + 1).
S + Tcannot 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.
memset (A, 0, sizeof A)initializes an array
Aof pointers to NULL.
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.