c99 [options...] pathname [[pathname] [-I directory]
[-L directory] [-l library]]...
If the -c option is specified, for all pathname operands of the form file.c, the files:
$(basename pathname .c).o
shall be created as the result of successful compilation. If the -c option is not specified, it is unspecified whether such .o files are created or deleted for the file.c operands.
If there are no options that prevent link editing (such as -c or -E), and all input files compile and link without error, the resulting executable file shall be written according to the -o outfile option (if present) or to the file a.out.
The executable file shall be created as specified in Section 1.1.1.4, File Read, Write, and Creation, except that the file permission bits shall be set to: S_IRWXO | S_IRWXG | S_IRWXU
and the bits specified by the umask of the process shall be cleared.
The following options shall be supported:
Multiple instances of the -D, -I, -L, -l, and -U options can be specified.
The processing of other files is implementation-defined.
"%s:\n", <pathname>
may be written. These messages, if written, shall precede the processing of each input file; they shall not be written to the standard output if they are written to the standard error, as described in the STDERR section.
If the -E option is specified, the standard output shall be a text file that represents the results of the preprocessing stage of the language; it may contain extra information appropriate for subsequent compilation passes.
"%s:\n", <pathname>
may be written to allow identification of the diagnostic and warning messages with the appropriate input file. These messages, if written, shall precede the processing of each input file; they shall not be written to the standard error if they are written to the standard output, as described in the STDOUT section.
This utility may produce warning messages about certain conditions that do not warrant returning an error (non-zero) exit value.
The c99 utility shall recognize the following -l options for standard libraries:
In the absence of options that inhibit invocation of the link editor, such as -c or -E, the c99 utility shall cause the equivalent of a -l c option to be passed to the link editor after the last pathname operand or -l option, causing it to be searched after all other object files and libraries are loaded.
It is unspecified whether the libraries libc.a, libl.a, libm.a, libpthread.a, librt.a, libtrace.a, libxnet.a, or liby.a exist as regular files. The implementation may accept as -l option-arguments names of objects that do not exist as regular files.
The C compiler and link editor shall support the significance of external symbols up to a length of at least 31 bytes; the action taken upon encountering symbols exceeding the implementation-defined maximum symbol length is unspecified.
The compiler and link editor shall support a minimum of 511 external symbols per source or object file, and a minimum of 4095 external symbols in total. A diagnostic message shall be written to the standard output if the implementation-defined limit is exceeded; other actions are unspecified.
If a file with the same name as one of the standard headers defined in the Base Definitions volume of POSIX.1-2008, Chapter 13, Headers, not provided as part of the implementation, is placed in any of the usual places that are searched by default for headers, the results are unspecified.
All implementations shall support one of the following programming
environments as a default. Implementations may support more than one
of the following programming environments. Applications can use
sysconf()
or
getconf
to determine which programming environments are supported.
| |||||||||||||||||||||||||||||||||||
All implementations shall support one or more environments where the widths of the following types are no greater than the width of type long:
blksize_t cc_t mode_t nfds_t pid_t | ptrdiff_t size_t speed_t ssize_t suseconds_t |
tcflag_t
wchar_t
wint_t
|
The executable files created when these environments are selected shall be in a proper format for execution by the exec family of functions. Each environment may be one of the ones in Table 4-4, Programming Environments: Type Sizes, or it may be another environment. The names for the environments that meet this requirement shall be output by a getconf command using the POSIX_V7_WIDTH_RESTRICTED_ENVS argument, as a <newline>-separated list of names suitable for use with the getconf -v option. If more than one environment meets the requirement, the names of all such environments shall be output on separate lines. Any of these names can then be used in a subsequent getconf command to obtain the flags specific to that environment with the following suffixes added as appropriate:
This requirement may be removed in a future version.
When this utility processes a file containing a function called main(), it shall be defined with a return type equivalent to int. Using return from the initial call to main() shall be equivalent (other than with respect to language scope issues) to calling exit() with the returned value. Reaching the end of the initial call to main() shall be equivalent to calling exit(0). The implementation shall not declare a prototype for this function.
Implementations provide configuration strings for C compiler flags, linker/loader flags, and libraries for each supported environment. When an application needs to use a specific programming environment rather than the implementation default programming environment while compiling, the application shall first verify that the implementation supports the desired environment. If the desired programming environment is supported, the application shall then invoke c99 with the appropriate C compiler flags as the first options for the compile, the appropriate linker/loader flags after any other options except -l but before any operands or -l options, and the appropriate libraries at the end of the operands and -l options.
Conforming applications shall not attempt to link together object files
compiled for different programming models. Applications shall also be
aware that binary data placed in shared memory or in files might not be
recognized by applications built for other programming models.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
In addition to the type size programming environments above, all implementations also support a multi-threaded programming environment that is orthogonal to all of the programming environments listed above. The getconf utility can be used to get flags for the threaded programming environment, as indicated in Table 4-6, Threaded Programming Environment: c99 Arguments.
| |||||||||||||||
These programming environment flags may be used in conjunction with any of the type size programming environments supported by the implementation.
The following sections are informative.
On systems providing POSIX Conformance (see the Base Definitions volume of POSIX.1-2008, Chapter 2, Conformance), c99 is required only with the C-Language Development option; XSI-conformant systems always provide c99.
Some historical implementations have created .o files when -c is not specified and more than one source file is given. Since this area is left unspecified, the application cannot rely on .o files being created, but it also must be prepared for any related .o files that already exist being deleted at the completion of the link edit.
There is the possible implication that if a user supplies versions of the standard functions (before they would be encountered by an implicit -l c or explicit -l m), that those versions would be used in place of the standard versions. There are various reasons this might not be true (functions defined as macros, manipulations for clean name space, and so on), so the existence of files named in the same manner as the standard libraries within the -L directories is explicitly stated to produce unspecified behavior.
All of the functions specified in the System Interfaces volume of POSIX.1-2008 may be made visible by implementations when the Standard C Library is searched. Conforming applications must explicitly request searching the other standard libraries when functions made visible by those libraries are used.
In the ISO C standard the mapping from physical source characters to the C source character set is implementation-defined. Implementations may strip white-space characters before the terminating <newline> of a (physical) line as part of this mapping and, as a consequence of this, one or more white-space characters (and no other characters) between a <backslash> character and the <newline> character that terminates the line produces implementation-defined results. Portable applications should not use such constructs.
Some c99 compilers not conforming to POSIX.1-2008 do not support trigraphs by default.
c99 -o foo foo.c
The following usage example compiles foo.c and creates the object file foo.o:
c99 -c foo.c
The following usage example compiles foo.c and creates the executable file a.out:
c99 foo.c
The following usage example compiles foo.c, links it with bar.o, and creates the executable file a.out. It may also create and leave foo.o:
c99 foo.c bar.o
offbig_env=$(getconf _POSIX_V7_ILP32_OFFBIG)
if [ $offbig_env != "-1" ] && [ $offbig_env != "undefined" ]
then
c99 $(getconf POSIX_V7_ILP32_OFFBIG_CFLAGS) \
$(getconf POSIX_V7_THREADS_CFLAGS) -D_XOPEN_SOURCE=700 \
$(getconf POSIX_V7_ILP32_OFFBIG_LDFLAGS) \
$(getconf POSIX_V7_THREADS_LDFLAGS) foo.c -o foo \
$(getconf POSIX_V7_ILP32_OFFBIG_LIBS) \
-l pthread
else
echo ILP32_OFFBIG programming environment not supported
exit 1
fi
Consider the case in which module a.c calls function f() in library libQ.a, and module b.c calls function g() in library libp.a. Assume that both libraries reside in /a/b/c. The command line to compile and link in the desired way is:
c99 -L /a/b/c main.o a.c -l Q b.c -l p
In this case the -L option need only precede the first -l option, since both libQ.a and libp.a reside in the same directory.
Multiple -L options can be used when library name collisions occur. Building on the previous example, suppose that the user wants to use a new libp.a, in /a/a/a, but still wants f() from /a/b/c/libQ.a:
c99 -L /a/a/a -L /a/b/c main.o a.c -l Q b.c -l p
In this example, the linker searches the -L options in the order specified, and finds /a/a/a/libp.a before /a/b/c/libp.a when resolving references for b.c. The order of the -l options is still important, however.
are no greater than the width of type long:
# First choose one of the listed environments ...
# ... if there are no additional constraints, the first one will do:
CENV=$(getconf POSIX_V7_WIDTH_RESTRICTED_ENVS | head -n l)
# ... or, if an environment that supports large files is preferred,
# look for names that contain "OFF64" or "OFFBIG". (This chooses
# the last one in the list if none match.)
for CENV in $(getconf POSIX_V7_WIDTH_RESTRICTED_ENVS)
do
case $CENV in
*OFF64*|*OFFBIG*) break ;;
esac
done
# The chosen environment name can now be used like this:
c99 $(getconf ${CENV}_CFLAGS) -D _POSIX_C_SOURCE=200809L \
$(getconf ${CENV}_LDFLAGS) foo.c -o foo \
$(getconf ${CENV}_LIBS)
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 '|'.
The Base Definitions volume of POSIX.1-2008, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines, Chapter 13, Headers
The System Interfaces volume of POSIX.1-2008, exec, sysconf()
Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .