компилировать стандартные программы на C (compile standard C programs)
Обоснование (Rationale)
The c99 utility is based on the c89 utility originally introduced
in the ISO POSIX‐2:1993 standard.
Some of the changes from c89 include the ability to intersperse
options and operands (which many c89 implementations allowed
despite it not being specified), the description of -l as an
option instead of an operand, and the modification to the
contents of the Standard Libraries section to account for new
headers and options; for example, <spawn.h> added to the
description of -l rt, and -l trace added for the Tracing option.
POSIX.1‐2008 specifies that the c99 utility must be able to use
regular files for *.o files and for a.out files. Implementations
are free to overwrite existing files of other types when
attempting to create object files and executable files, but are
not required to do so. If something other than a regular file is
specified and using it fails for any reason, c99 is required to
issue a diagnostic message and exit with a non-zero exit status.
But for some file types, the problem may not be noticed for a
long time. For example, if a FIFO named a.out exists in the
current directory, c99 may attempt to open a.out and will hang in
the open() call until another process opens the FIFO for reading.
Then c99 may write most of the a.out to the FIFO and fail when it
tries to seek back close to the start of the file to insert a
timestamp (FIFOs are not seekable files). The c99 utility is also
allowed to issue a diagnostic immediately if it encounters an
a.out or *.o file that is not a regular file. For portable use,
applications should ensure that any a.out, -o option-argument, or
*.o files corresponding to any *.c files do not conflict with
names already in use that are not regular files or symbolic links
that point to regular files.
On many systems, multi-threaded applications run in a programming
environment that is distinct from that used by single-threaded
applications. This multi-threaded programming environment (in
addition to needing to specify -l pthread at link time) may
require additional flags to be set when headers are processed at
compile time (-D_REENTRANT being common). This programming
environment is orthogonal to the type size programming
environments discussed above and listed in Table 4-4, Programming
Environments: Type Sizes. This version of the standard adds
getconf utility calls to provide the C compiler flags and
linker/loader flags needed to support multi-threaded
applications. Note that on a system where single-threaded
applications are a special case of a multi-threaded application,
both of these getconf calls may return NULL strings; on other
implementations both of these strings may be non-NULL strings.
The C standardization committee invented trigraphs (e.g., "??!"
to represent '|') to address character portability problems in
development environments based on national variants of the 7-bit
ISO/IEC 646:1991 standard character set. However, these
environments were already obsolete by the time the first ISO C
standard was published, and in practice trigraphs have not been
used for their intended purpose, and usually are intended to have
their original meaning in K&R C. For example, in practice a C-
language source string like "What??!" is usually intended to end
in two <question-mark> characters and an <exclamation-mark>, not
in '|'.
When the -E option is used, execution of some #pragma
preprocessor directives may simply result in a copy of the
directive being included in the output as part of the allowed
extra information used by subsequent compilation passes (see
STDOUT).
