xenial (1) c99.1posix.gz

Provided by: manpages-posix_2013a-1_all bug

PROLOG

       This  manual  page  is part of the POSIX Programmer's Manual.  The Linux implementation of this interface
       may differ (consult the corresponding Linux manual page for details of Linux behavior), or the  interface
       may not be implemented on Linux.

NAME

       c99 — compile standard C programs

SYNOPSIS

       c99 [options...] pathname [[pathname] [−I directory]
           [−L directory] [−l library]]...

DESCRIPTION

       The  c99  utility  is  an  interface  to  the  standard C compilation system; it shall accept source code
       conforming to the ISO C standard. The system conceptually consists of a compiler  and  link  editor.  The
       input  files  referenced  by  pathname  operands  and −l option-arguments shall be compiled and linked to
       produce an executable file. (It is unspecified whether the linking occurs entirely within  the  operation
       of c99; some implementations may produce objects that are not fully resolved until the file is executed.)

       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.

OPTIONS

       The  c99  utility  shall  conform  to  the Base Definitions volume of POSIX.1‐2008, Section 12.2, Utility
       Syntax Guidelines, except that:

        *  Options can be interspersed with operands.

        *  The order of specifying the −L and −l options, and the order of specifying −l options with respect to
           pathname operands is significant.

        *  Conforming  applications  shall specify each option separately; that is, grouping option letters (for
           example, −cO) need not be recognized by all implementations.

       The following options shall be supported:

       −c        Suppress the link-edit phase of the compilation, and do not remove any object  files  that  are
                 produced.

       −D name[=value]
                 Define  name as if by a C-language #define directive. If no =value is given, a value of 1 shall
                 be used. The −D option has lower precedence than the −U option. That is, if  name  is  used  in
                 both  a  −U  and  a  −D option, name shall be undefined regardless of the order of the options.
                 Additional implementation-defined names may be provided by the compiler. Implementations  shall
                 support at least 2048 bytes of −D definitions and 256 names.

       −E        Copy  C-language  source  files  to  standard output, expanding all preprocessor directives; no
                 compilation shall be performed. If any operand is not a text file, the effects are unspecified.

       −g        Produce symbolic information in the object or executable files; the nature of this  information
                 is unspecified, and may be modified by implementation-defined interactions with other options.

       −I directory
                 Change  the  algorithm for searching for headers whose names are not absolute pathnames to look
                 in the directory named by the directory pathname before looking  in  the  usual  places.  Thus,
                 headers  whose  names  are  enclosed  in  double-quotes ("") shall be searched for first in the
                 directory of the file with the #include line, then in directories named in −I options, and last
                 in  the usual places. For headers whose names are enclosed in angle brackets ("<>"), the header
                 shall be searched for only in directories named in −I options and then  in  the  usual  places.
                 Directories  named  in −I options shall be searched in the order specified. If the −I option is
                 used to specify a directory that is one of the usual places searched by  default,  the  results
                 are  unspecified.  Implementations  shall  support  at  least ten instances of this option in a
                 single c99 command invocation.

       −L directory
                 Change the algorithm of searching for the libraries named in the −l  objects  to  look  in  the
                 directory named by the directory pathname before looking in the usual places. Directories named
                 in −L options shall be searched in the order specified. If the −L option is used to  specify  a
                 directory  that  is  one  of the usual places searched by default, the results are unspecified.
                 Implementations shall support at least ten instances of this option in  a  single  c99  command
                 invocation. If a directory specified by a −L option contains files with names starting with any
                 of the strings "libc.", "libl.", "libpthread.", "libm.", "librt.", "libtrace.", "libxnet.",  or
                 "liby.", the results are unspecified.

       −l library
                 Search  the  library  named  liblibrary.a.   A  library  shall  be  searched  when  its name is
                 encountered, so the placement of a −l option is significant. Several standard libraries can  be
                 specified in this manner, as described in the EXTENDED DESCRIPTION section. Implementations may
                 recognize implementation-defined suffixes other than .a as denoting libraries.

       −O optlevel
                 Specify the level of code optimization. If the optlevel option-argument is the digit  '0',  all
                 special  code  optimizations  shall  be  disabled.  If  it  is the digit '1', the nature of the
                 optimization is unspecified. If the −O option is omitted, the nature of  the  system's  default
                 optimization is unspecified. It is unspecified whether code generated in the presence of the −O
                 0 option is the same as that generated when  −O  is  omitted.  Other  optlevel  values  may  be
                 supported.

       −o outfile
                 Use  the  pathname  outfile, instead of the default a.out, for the executable file produced. If
                 the −o option is present with −c or −E, the result is unspecified.

       −s        Produce object or executable files, or both, from which  symbolic  and  other  information  not
                 required  for proper execution using the exec family defined in the System Interfaces volume of
                 POSIX.1‐2008 has been removed (stripped). If both −g and −s options  are  present,  the  action
                 taken is unspecified.

       −U name   Remove any initial definition of name.

       Multiple instances of the −D, −I, −L, −l, and −U options can be specified.

OPERANDS

       The  application  shall  ensure  that at least one pathname operand is specified. The following forms for
       pathname operands shall be supported:

       file.c    A C-language source file to be compiled and optionally linked.  The  application  shall  ensure
                 that the operand is of this form if the −c option is used.

       file.a    A library of object files typically produced by the ar utility, and passed directly to the link
                 editor. Implementations may recognize implementation-defined suffixes other than .a as denoting
                 object file libraries.

       file.o    An  object  file produced by c99 −c and passed directly to the link editor. Implementations may
                 recognize implementation-defined suffixes other than .o as denoting object files.

       The processing of other files is implementation-defined.

STDIN

       Not used.

INPUT FILES

       Each input file shall be one of the following: a text file containing a  C-language  source  program,  an
       object  file  in  the  format produced by c99 −c, or a library of object files, in the format produced by
       archiving zero or more object files, using ar.  Implementations  may  supply  additional  utilities  that
       produce files in these formats. Additional input file formats are implementation-defined.

ENVIRONMENT VARIABLES

       The following environment variables shall affect the execution of c99:

       LANG      Provide a default value for the internationalization variables that are unset or null. (See the
                 Base Definitions volume of POSIX.1‐2008, Section 8.2, Internationalization  Variables  for  the
                 precedence   of   internationalization  variables  used  to  determine  the  values  of  locale
                 categories.)

       LC_ALL    If set to a non-empty string value, override the values of all the  other  internationalization
                 variables.

       LC_CTYPE  Determine  the  locale  for the interpretation of sequences of bytes of text data as characters
                 (for example, single-byte as opposed to multi-byte characters in arguments and input files).

       LC_MESSAGES
                 Determine the locale that should be used to  affect  the  format  and  contents  of  diagnostic
                 messages written to standard error.

       NLSPATH   Determine the location of message catalogs for the processing of LC_MESSAGES.

       TMPDIR    Provide  a pathname that should override the default directory for temporary files, if any.  On
                 XSI-conforming systems, provide a pathname  that  shall  override  the  default  directory  for
                 temporary files, if any.

ASYNCHRONOUS EVENTS

       Default.

STDOUT

       If  more  than  one  pathname operand ending in .c (or possibly other unspecified suffixes) is given, for
       each such file:

           "%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.

STDERR

       The standard error shall be used only for diagnostic messages.  If more than one pathname operand  ending
       in .c (or possibly other unspecified suffixes) is given, for each such file:

           "%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.

OUTPUT FILES

       Object  files  or  executable  files  or  both are produced in unspecified formats. If the pathname of an
       object file or executable file to be created by c99 resolves to an existing directory entry  for  a  file
       that is not a regular file, it is unspecified whether c99 shall attempt to create the file or shall issue
       a diagnostic and exit with a non-zero exit status.

EXTENDED DESCRIPTION

   Standard Libraries
       The c99 utility shall recognize the following −l options for standard libraries:

       −l c      This option shall make available all interfaces referenced in the System Interfaces  volume  of
                 POSIX.1‐2008,  with  the  possible exception of those interfaces listed as residing in <aio.h>,
                 <arpa/inet.h>,   <complex.h>,   <fenv.h>,   <math.h>,   <mqueue.h>,   <netdb.h>,    <net/if.h>,
                 <netinet/in.h>,    <pthread.h>,    <sched.h>,    <semaphore.h>,    <spawn.h>,   <sys/socket.h>,
                 pthread_kill(), and pthread_sigmask() in <signal.h>, <trace.h>, interfaces marked  as  optional
                 in  <sys/mman.h>,  interfaces marked as ADV (Advisory Information) in <fcntl.h>, and interfaces
                 beginning with the prefix clock_ or time_ in <time.h>.  This option shall not be required to be
                 present to cause a search of this library.

       −l l      This  option  shall make available all interfaces required by the C-language output of lex that
                 are not made available through the −l c option.

       −l pthread
                 This option shall make available all interfaces referenced in  <pthread.h>  and  pthread_kill()
                 and  pthread_sigmask()  referenced in <signal.h>.  An implementation may search this library in
                 the absence of this option.

       −l m      This option shall make available  all  interfaces  referenced  in  <math.h>,  <complex.h>,  and
                 <fenv.h>.  An implementation may search this library in the absence of this option.

       −l rt     This  option  shall make available all interfaces referenced in <aio.h>, <mqueue.h>, <sched.h>,
                 <semaphore.h>, and <spawn.h>, interfaces marked as optional in <sys/mman.h>, interfaces  marked
                 as ADV (Advisory Information) in <fcntl.h>, and interfaces beginning with the prefix clock_ and
                 time_ in <time.h>.  An implementation may search this library in the absence of this option.

       −l trace  This option shall make available all interfaces referenced in <trace.h>.  An implementation may
                 search this library in the absence of this option.

       −l xnet   This  option  shall  make  available  all  interfaces  referenced  in <arpa/inet.h>, <netdb.h>,
                 <net/if.h>, <netinet/in.h>, and <sys/socket.h>.  An implementation may search this  library  in
                 the absence of this option.

       −l y      This  option shall make available all interfaces required by the C-language output of yacc that
                 are not made available through the −l c option.

       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.

   External Symbols
       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.

   Header Search
       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.

   Programming Environments
       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.

                                    Table 4-4: Programming Environments: Type Sizes

                           ┌────────────────────────┬─────────┬─────────┬─────────┬─────────┐
                           │Programming EnvironmentBits inBits inBits inBits in │
                           │     getconf Nameintlongpointeroff_t  │
                           ├────────────────────────┼─────────┼─────────┼─────────┼─────────┤
                           │_POSIX_V7_ILP32_OFF32   │    32   │    32   │    32   │    32   │
                           │_POSIX_V7_ILP32_OFFBIG  │    32   │    32   │    32   │   ≥64   │
                           │_POSIX_V7_LP64_OFF64    │    32   │    64   │    64   │    64   │
                           │_POSIX_V7_LPBIG_OFFBIG  │   ≥32   │   ≥64   │   ≥64   │   ≥64   │
                           └────────────────────────┴─────────┴─────────┴─────────┴─────────┘
       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   ptrdiff_t     tcflag_t
                                          cc_t        size_t        wchar_t
                                          mode_t      speed_t       wint_t
                                          nfds_t      ssize_t
                                          pid_t       suseconds_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:

       _CFLAGS   To get the C compiler flags.

       _LDFLAGS  To get the linker/loader flags.

       _LIBS     To get the libraries.

       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.

                                  Table 4-5: Programming Environments: c99 Arguments

                    ┌────────────────────────┬─────────────────────┬───────────────────────────────┐
                    │Programming Environment │                     │         c99 Arguments         │
                    │     getconf NameUsegetconf Name          │
                    ├────────────────────────┼─────────────────────┼───────────────────────────────┤
                    │_POSIX_V7_ILP32_OFF32   │ C Compiler Flags    │ POSIX_V7_ILP32_OFF32_CFLAGS   │
                    │                        │ Linker/Loader Flags │ POSIX_V7_ILP32_OFF32_LDFLAGS  │
                    │                        │ Libraries           │ POSIX_V7_ILP32_OFF32_LIBS     │
                    ├────────────────────────┼─────────────────────┼───────────────────────────────┤
                    │_POSIX_V7_ILP32_OFFBIG  │ C Compiler Flags    │ POSIX_V7_ILP32_OFFBIG_CFLAGS  │
                    │                        │ Linker/Loader Flags │ POSIX_V7_ILP32_OFFBIG_LDFLAGS │
                    │                        │ Libraries           │ POSIX_V7_ILP32_OFFBIG_LIBS    │
                    ├────────────────────────┼─────────────────────┼───────────────────────────────┤
                    │_POSIX_V7_LP64_OFF64    │ C Compiler Flags    │ POSIX_V7_LP64_OFF64_CFLAGS    │
                    │                        │ Linker/Loader Flags │ POSIX_V7_LP64_OFF64_LDFLAGS   │
                    │                        │ Libraries           │ POSIX_V7_LP64_OFF64_LIBS      │
                    ├────────────────────────┼─────────────────────┼───────────────────────────────┤
                    │_POSIX_V7_LPBIG_OFFBIG  │ C Compiler Flags    │ POSIX_V7_LPBIG_OFFBIG_CFLAGS  │
                    │                        │ Linker/Loader Flags │ POSIX_V7_LPBIG_OFFBIG_LDFLAGS │
                    │                        │ Libraries           │ POSIX_V7_LPBIG_OFFBIG_LIBS    │
                    └────────────────────────┴─────────────────────┴───────────────────────────────┘
       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.

                              Table 4-6: Threaded Programming Environment: c99 Arguments

                      ┌────────────────────────┬─────────────────────┬──────────────────────────┐
                      │Programming Environment │                     │      c99 Arguments       │
                      │     getconf NameUsegetconf Name       │
                      ├────────────────────────┼─────────────────────┼──────────────────────────┤
                      │_POSIX_THREADS          │ C Compiler Flags    │ POSIX_V7_THREADS_CFLAGS  │
                      │                        │ Linker/Loader Flags │ POSIX_V7_THREADS_LDFLAGS │
                      └────────────────────────┴─────────────────────┴──────────────────────────┘
       These programming environment flags may be used in conjunction with any  of  the  type  size  programming
       environments supported by the implementation.

EXIT STATUS

       The following exit values shall be returned:

        0    Successful compilation or link edit.

       >0    An error occurred.

CONSEQUENCES OF ERRORS

       When  c99  encounters  a compilation error that causes an object file not to be created, it shall write a
       diagnostic to standard error and continue to compile other source code operands, but it shall not perform
       the  link phase and return a non-zero exit status. If the link edit is unsuccessful, a diagnostic message
       shall be written to standard error and c99 exits with a non-zero status. A conforming  application  shall
       rely on the exit status of c99, rather than on the existence or mode of the executable file.

       The following sections are informative.

APPLICATION USAGE

       Since  the  c99 utility usually creates files in the current directory during the compilation process, it
       is typically necessary to run the c99 utility in a directory in which a file can be created.

       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.

EXAMPLES

        1. The following usage example compiles foo.c and creates the executable file foo:

               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

        2. The  following  example shows how an application using threads interfaces can test for support of and
           use a programming environment supporting 32-bit int, long, and pointer types and an off_t type  using
           at least 64 bits:

               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

        3. The following examples clarify the use and interactions of −L and −l options.

           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.

        4. The  following example shows how an application can use a programming environment where the widths of
           the following types: 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

           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)

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 '|'.

FUTURE DIRECTIONS

       None.

SEE ALSO

       Section 1.1.1.4, File Read, Write, and Creation, ar, getconf, make, nm, strip, umask

       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()

       Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1, 2013 Edition,
       Standard  for  Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base
       Specifications Issue 7, Copyright (C) 2013 by the Institute of Electrical and Electronics Engineers,  Inc
       and  The  Open Group.  (This is POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the event
       of any discrepancy between this version and the original IEEE and The Open Group Standard,  the  original
       IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at
       http://www.unix.org/online.html .

       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 .