C99(1P)

📦 version 2017a, in alpine 3.22, alpine 3.23, alpine 3.24, arch rolling, nixpkgs unstable, opensuse-leap 16.0

💖 C99(1P) — POSIX Programmer's Manual 💖

okay bestie, welcome to the POSIX Programmer's Manual page for c99, and we are about to make compiling C programs feel like the main character moment it truly is ✨

🌸 PROLOG 🌸

so like, this manual page is part of the POSIX Programmer's Manual. real talk: the Linux implementation of this interface may differ (so go peek at the corresponding Linux manual page for the details on Linux behavior), or honestly the interface may not even be implemented on Linux at all 🙈. iykyk.

👑 NAME 👑

c99 — compile standard C programs 💅

🎀 SYNOPSIS 🎀

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

🦋 DESCRIPTION 🦋

so the c99 utility is basically your interface to the standard C compilation system, and it shall accept source code conforming to the ISO C standard. the system is conceptually two besties working together: a compiler and a link editor 🫶. the input files referenced by the pathname operands and the -l option-arguments get compiled and linked to produce an executable file. and ngl, it is unspecified whether the linking happens entirely within the operation of c99 — some implementations may produce objects that aren't fully resolved until the file is actually executed. no cap.

if the -c option is specified, then for all pathname operands of the form file.c, the files:

$(basename pathname .c).o

shall be created as the result of a successful compilation. and if the -c option is not specified, it's unspecified whether those .o files get created or deleted for the file.c operands. it's giving chaos but make it standard 💀.

if there are no options that prevent link editing (like -c or -E), and all input files compile and link without error, then the resulting executable file shall be written according to the -o outfile option (if it's there) or else to the file a.out. periodt.

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‐2017, 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 — so do not be out here reordering things, bestie, it matters fr fr
  • conforming applications shall specify each option separately; that is, grouping option letters together (for example, -cO) need not be recognized by all implementations. so no bundling, she's not that kind of girl 💅

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, executing 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. so: 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. and okay this part is important: 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‐2017 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. she's not taking anything from stdin, bestie, keep it moving 💅

🎀 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‐2017, 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. (yes bestie, "should" vs "shall" — she's picky like that 💅)

🫶 ASYNCHRONOUS EVENTS 🫶

default.

✨ STDOUT ✨

if more than one pathname operand ending in .c (or possibly other unspecified suffixes) is given, then 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 🔥.

okay and that's just part one, bestie — stay tuned, there's more 💖

✨ STDERR ✨

Okay bestie, standard error is diagnostic messages only. No vibes, no output, just the tea. 💅

If you pass more than one pathname operand ending in .c (or possibly other unspecified suffixes), then for each such file, this may be written:

"%s:\n", <pathname>

That's so the diagnostics and warnings can be matched to the right input file. If these messages are written, they shall come before the processing of each input file. And no cap: they shall not be written to standard error if they are written to standard output, like we talked about in the STDOUT section. 👀

Also, this utility may produce warning messages about certain conditions that do not warrant returning an error (non-zero) exit value. So like, warnings are not always a fail. 💀

📁 OUTPUT FILES 📁

Object files or executable files or both are produced in unspecified formats. We don't know the format, bestie, it's giving mystery. 🕵️‍♀️

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. So like, could go either way. 🙈

🌈 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‐2017, 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 timer_ 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 timer_ 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.

If a file with the same name as one of the standard headers defined in the Base Definitions volume of POSIX.1‐2017, 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

  • _POSIX_V7_ILP32_OFF32 — Bits in int: 32, Bits in long: 32, Bits in pointer: 32, Bits in off_t: 32
  • _POSIX_V7_ILP32_OFFBIG — Bits in int: 32, Bits in long: 32, Bits in pointer: 32, Bits in off_t: ≥64
  • _POSIX_V7_LP64_OFF64 — Bits in int: 32, Bits in long: 64, Bits in pointer: 64, Bits in off_t: 64
  • _POSIX_V7_LPBIG_OFFBIG — Bits in int: ≥32, Bits in long: ≥64, Bits in pointer: ≥64, Bits in off_t: ≥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.

Lowkey the most unhinged part of this whole page is coming up, but bestie we're gonna get through it together 💖 Because the flags are not it until you know which programming environment you're even in.

Table 4-5: Programming Environments: c99 Arguments ✨

Each row is a programming environment (given by its getconf name), and each one has three things you can ask getconf for: the C compiler flags, the linker/loader flags, and the libraries. So:

  • _POSIX_V7_ILP32_OFF32 — the programming environment's getconf name
    • Use: C Compiler Flags → getconf name: POSIX_V7_ILP32_OFF32_CFLAGS
    • Use: Linker/Loader Flags → getconf name: POSIX_V7_ILP32_OFF32_LDFLAGS
    • Use: Libraries → getconf name: POSIX_V7_ILP32_OFF32_LIBS
  • _POSIX_V7_ILP32_OFFBIG — the programming environment's getconf name
    • Use: C Compiler Flags → getconf name: POSIX_V7_ILP32_OFFBIG_CFLAGS
    • Use: Linker/Loader Flags → getconf name: POSIX_V7_ILP32_OFFBIG_LDFLAGS
    • Use: Libraries → getconf name: POSIX_V7_ILP32_OFFBIG_LIBS
  • _POSIX_V7_LP64_OFF64 — the programming environment's getconf name
    • Use: C Compiler Flags → getconf name: POSIX_V7_LP64_OFF64_CFLAGS
    • Use: Linker/Loader Flags → getconf name: POSIX_V7_LP64_OFF64_LDFLAGS
    • Use: Libraries → getconf name: POSIX_V7_LP64_OFF64_LIBS
  • _POSIX_V7_LPBIG_OFFBIG — the programming environment's getconf name
    • Use: C Compiler Flags → getconf name: POSIX_V7_LPBIG_OFFBIG_CFLAGS
    • Use: Linker/Loader Flags → getconf name: POSIX_V7_LPBIG_OFFBIG_LDFLAGS
    • Use: Libraries → getconf name: POSIX_V7_LPBIG_OFFBIG_LIBS

Okay so on top of all those type-size programming environments, literally every implementation also supports a multi-threaded programming environment that's orthogonal to all of the ones listed above 🧵✨ Like, they're independent axes, they don't interfere. And yes, you use the getconf utility to grab the flags for the threaded one too, exactly like Table 4-6 says:

Table 4-6: Threaded Programming Environment: c99 Arguments 🌈

  • _POSIX_THREADS — the programming environment's getconf name
    • Use: C Compiler Flags → getconf name: POSIX_V7_THREADS_CFLAGS
    • Use: Linker/Loader Flags → getconf name: POSIX_V7_THREADS_LDFLAGS

And the tea ☕: these programming environment flags may be used in conjunction with any of the type size programming environments supported by the implementation. Mix and match, bestie, they're compatible 💅

EXIT STATUS 👑

The following exit values shall be returned:

  • 0 — Successful compilation or link edit. Slay.
  • >0 — An error occurred. 💀

CONSEQUENCES OF ERRORS 😭

So when c99 hits a compilation error that means an object file won't be created, here's the vibe: it shall write a diagnostic to standard error, and it shall continue to compile the other source code operands. It does not do the link phase, and it returns a non-zero exit status. Periodt.

If the link edit is unsuccessful, a diagnostic message shall be written to standard error and c99 exits with a non-zero status. And this part is important: a conforming application shall rely on the exit status of c99, rather than on the existence or mode of the executable file. Don't go peeking at the file, bestie, check the exit status 🫶

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. Like, obviously. Don't run it somewhere read-only and then act surprised 🙈

On systems providing POSIX Conformance (see the Base Definitions volume of POSIX.1‐2017, 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. Yeah. Both directions. Chaotic, I know. 💀

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. But 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. So like... don't 🚫

All of the functions specified in the System Interfaces volume of POSIX.1‐2017 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. No freeloading off the implicit search, bestie ✨

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. Seriously, just don't, it's giving undefined-adjacent 🫠

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
  1. 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
  1. 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. Don't forget that part 💅

  1. 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 💭

okay so storytime bestie, because the lore actually matters here 🫶

c99 is based on the c89 utility that was originally introduced in the ISO POSIX‐2:1993 standard. glow-up era.

Some of the changes from c89 include:

  • the ability to intersperse options and operands (which, ngl, many c89 implementations allowed anyway even though it wasn't specified — they were doing it before it was cool 💅)
  • the description of -l as an option instead of an operand
  • 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 they 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 here's the sneaky part 🙈 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, periodt).

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. fr fr, don't do it.

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, iykyk).

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. either way it's giving valid ✨

Now, trigraphs. buckle up 🎀

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 — and this is the messy part — 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 way that nobody ever wanted that 💀

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

🔮 FUTURE DIRECTIONS 🔮

Unlike all of the other non-OB-shaded utilities in this standard, a utility by this name probably will not appear in the next version of this standard. 😭

This utility's name is tied to the current revision of the ISO C standard at the time this standard is approved. Since the ISO C standard and this standard are maintained by different organizations on different schedules, we cannot predict what the compiler will be named in the next version of the standard. it's giving mystery, it's giving chaos 🌈

👀 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‐2017, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines, Chapter 13, Headers
  • The System Interfaces volume of POSIX.1‐2017, exec, sysconf()

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group.

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.opengroup.org/unix/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 .

and that's the whole page bestie!! 🎀 this one's from IEEE/The Open Group, dated 2017, and it lives under the name C99(1P). thank you for reading all four parts, you're literally the main character 💖✨🦋

📦 where this page comes from