<<< Previous Home Next >>>

NAME

c17 — compile standard C programs

SYNOPSIS

[CD] [Option Start] c17 [options...] pathname [[pathname] [-I directory]
        [-L directory] [-l library] [-R directory]]... [Option End]

DESCRIPTION

The c17 utility is an interface to the standard C compilation system; it shall accept source code written in the C language as defined in section 6 of the ISO C standard. The system conceptually consists of a compilation phase, encompassing Translation Phases 1 through 7 of the ISO C standard, and a linkage phase, for handling Phase 8 of the ISO C standard and extensions described here. The reference to "library components" in Phase 8 shall be taken to refer to components of libraries specified using the -l option, libraries specified as file.a or file.so operands, and the equivalent of a -l c option passed to the link editor in the manner specified in the EXTENDED DESCRIPTION. In addition, the compilation phase can be split into a separate preprocessing operation, handling Translation Phases 1 through 4, and a processing operation, handling Phases 5 though 7. Whether a single utility or multiple utilities for handling phases separately is provided by an implementation is left unspecified. The input files referenced by pathname operands and -l option-arguments shall be compiled and linked to produce an executable file or, if the -G option is specified, a shared library file. It is unspecified whether the linking of an executable file occurs entirely within the operation of c17; when a pathname operand or -l option-argument names a shared library, an executable object may be produced that is not fully resolved until the file is executed.

If the -c option is specified and the -o option is not specified, for all pathname operands of the form file.c or file.i, the files:

$(basename pathname .c).o

or

$(basename pathname .i).o

respectively 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 and file.i 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 or shared library file shall be written according to the -o outfile option, if present. If -o outfile is not specified, a resulting executable file shall be written to the file a.out; if the file to be written is a shared library file, the behavior is unspecified.

Executable files shall be created as specified in 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 c17 utility shall conform to XBD 12.2 Utility Syntax Guidelines , except that:

The following options shall be supported:

-B mode
If mode is dynamic, produce a dynamically linked executable file. If the -B option is present with -c, -E, or -G, the result is unspecified.
-c
Suppress the link-edit phase of the compilation, and do not remove any object files that are produced. The application shall ensure that all operands are of the form file.c or file.i.
-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
Create a shared library or create object files suitable for inclusion in such a shared library. Compilations shall be performed in a manner suitable for the creation of shared libraries (for example, by producing position-independent code).

If -c is also specified, create object files suitable for inclusion in a shared library.

If -c is not specified, create a shared library. In this case the application shall ensure that the file named by the -o outfile option-argument includes an element named so or an implementation-defined element denoting a shared library, where elements in the last component of outfile are separated by <period> characters, for example libx.so.1; if no -o option is included in the options or the file named by the -o outfile option does not contain an element named so or an implementation-defined element denoting a shared library, the result is unspecified. If a pathname operand or -l option-argument names a shared library and that shared library defines an object used by the library being created, it shall become a dependency of the created shared library.

If the -G option is present with -B or -E, the result is 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 c17 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 c17 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.", "libxnet.", or "liby.", the results are unspecified.
-l library
Search the library named liblibrary.a or liblibrary.so. When searching for a library, the linker shall look at each directory specified by -L options that appear on the command line before this -l option, in the order given, and then the system default libraries. If liblibrary.a and liblibrary.so both exist in a directory, c17 shall use liblibrary.so if either -B dynamic or -G is specified. Once a library has been found (shared or static) in a directory, later directories in the list shall not be considered. 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 and .so 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
Name the output file to be produced. If the -o option is present with -E, or with -c and more than one input file, the result is unspecified.

When creating a single object file (by using -c with a single input file), use the pathname outfile, instead of the default file.o, for the object file produced.

When creating an executable file, use the pathname outfile, instead of the default a.out, for the executable file produced.

When creating a shared library, use the pathname outfile as the name of the shared library. If no -o outfile option is specified when creating a shared library, 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-2024 has been removed (stripped). If both -g and -s options are present, the action taken is unspecified.
-R directory
If the object file format supports it, specify a directory to be searched for shared libraries when an executable file or shared library being created by c17 is subsequently executed, or loaded using dlopen(). If directory contains any <colon> or <dollar-sign> characters, the behavior is unspecified. If an implementation provides a means for setting a default load time search location or locations, the -R option shall take precedence.

The directory named by directory shall not be searched by a process performing dynamic loading if either of the following are true:

  • The real and effective user IDs of that process are different and the directory has write permission for a user ID outside the set of the effective user ID of that process and any implementation-specific user IDs used for directories containing system libraries.

  • The real and effective group IDs of that process are different and the directory has write permission for group IDs other than the effective group ID of that process.

Directories named in -R options shall be searched in the order specified, before the default system library locations are searched.

If a directory specified by a -R option contains files with names starting with any of the strings "libc.", "libl.", "libpthread.", "libm.", "librt.", "libxnet.", or "liby.", the result is unspecified.

If the -R option is present with -c or -E, the result is unspecified.

-U name
Remove any initial definition of name.

Multiple instances of the -D, -I, -L, -l, -R, 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.
file.i
A text file containing the output of c17 -E, to be compiled and optionally linked. The processing already performed by c17 -E when the file was produced shall not be repeated when the file is compiled.
file.a
A library of static object files typically produced by the ar utility, and referenced during the link-edit phase. Implementations may recognize implementation-defined suffixes other than .a as denoting static object file libraries.
file.so
A library of shared object files typically produced by the c17 utility with the -G option, and referenced during the link-edit phase. Implementations may recognize implementation-defined suffixes other than .so as denoting shared object file libraries.
file.o
An object file produced by c17 -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:

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 c17:

LANG
Provide a default value for the internationalization variables that are unset or null. (See XBD 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
[XSI] [Option Start] Determine the location of messages objects and message catalogs. [Option End]
TMPDIR
Provide a pathname that should override the default directory for temporary files, if any. [XSI] [Option Start]  On XSI-conforming systems, provide a pathname that shall override the default directory for temporary files, if any. [Option End]

ASYNCHRONOUS EVENTS

Default.

STDOUT

If more than one pathname operand ending in .c or .i (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 and shall contain at least one line with the format:

"# %d \"%s\"\n", <line>, <pathname>

for each file processed as a result of a #include directive, unless no other output generated from that file is present in the output, where line is a line number and pathname is the pathname used to open the file.

STDERR

The standard error shall be used only for diagnostic messages, except that if more than one pathname operand ending in .c or .i (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 c17 resolves to an existing directory entry for a file that is not a regular file, it is unspecified whether c17 shall attempt to create the file or shall issue a diagnostic and exit with a non-zero exit status.

EXTENDED DESCRIPTION

Standard Libraries

The c17 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-2024, 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>, <threads.h>, pthread_kill() and pthread_sigmask() in <signal.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 <threads.h>, and also 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 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 c17 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.

The libraries c, l, m, pthread, rt, xnet, and y shall be found as shared libraries when specified as the option-argument to the -l option and may also be found as static libraries but, except for the shared library version of the c library, need not exist as regular files. The implementation may accept as -l option-arguments names of additional implementation-defined libraries 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 4095 external identifiers in one translation unit. 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 XBD 14. 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 the _POSIX_Vn_ILP* and _POSIX_Vn_LP* constants in <unistd.h>, and corresponding sysconf() and getconf calls, to determine which programming environments are supported.

Table: Programming Environments: Type Sizes

Programming Environment getconf Name

Bits in int

Bits in long

Bits in all pointer types

Bits in off_t

_POSIX_V8_ILP32_OFF32

32

32

32

32

_POSIX_V8_ILP32_OFFBIG

32

32

32

>=64

_POSIX_V8_LP64_OFF64

32

64

64

64

_POSIX_V8_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
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 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_V8_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 c17 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: Programming Environments: c17 Arguments

Programming Environment getconf Name

Use

c17 Arguments getconf Name

_POSIX_V8_ILP32_OFF32

C Compiler Flags

POSIX_V8_ILP32_OFF32_CFLAGS

 

Linker/Loader Flags

POSIX_V8_ILP32_OFF32_LDFLAGS

 

Libraries

POSIX_V8_ILP32_OFF32_LIBS

_POSIX_V8_ILP32_OFFBIG

C Compiler Flags

POSIX_V8_ILP32_OFFBIG_CFLAGS

 

Linker/Loader Flags

POSIX_V8_ILP32_OFFBIG_LDFLAGS

 

Libraries

POSIX_V8_ILP32_OFFBIG_LIBS

_POSIX_V8_LP64_OFF64

C Compiler Flags

POSIX_V8_LP64_OFF64_CFLAGS

 

Linker/Loader Flags

POSIX_V8_LP64_OFF64_LDFLAGS

 

Libraries

POSIX_V8_LP64_OFF64_LIBS

_POSIX_V8_LPBIG_OFFBIG

C Compiler Flags

POSIX_V8_LPBIG_OFFBIG_CFLAGS

 

Linker/Loader Flags

POSIX_V8_LPBIG_OFFBIG_LDFLAGS

 

Libraries

POSIX_V8_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 Programming Environments: Type Sizes .

Table: Threaded Programming Environment: c17 Arguments

Programming Environment getconf Name

Use

c17 Arguments getconf Name

_POSIX_THREADS

C Compiler Flags

POSIX_V8_THREADS_CFLAGS

 

Linker/Loader Flags

POSIX_V8_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 c17 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 it shall return a non-zero exit status. If the link edit is unsuccessful, a diagnostic message shall be written to standard error and c17 exits with a non-zero status. A conforming application shall rely on the exit status of c17, rather than on the existence or mode of the executable file.

The following sections are informative.

APPLICATION USAGE

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

On systems providing POSIX Conformance (see XBD 2. Conformance ), c17 is required only with the C-Language Development option; XSI-conformant systems always provide c17.

Since this standard requires that conforming applications define either _POSIX_C_SOURCE or _XOPEN_SOURCE before inclusion of any header (see XSH 2.2.1 POSIX.1 Symbols ), if c17 is used to compile source code that includes a header without defining one of these feature test macros in the required manner, the behavior of c17 itself and the results of using any files it generates are undefined. When c17 is used this way, implementations are encouraged to make visible in headers from the ISO C standard only the symbols that are allowed by that standard, and otherwise to behave the same as if _POSIX_C_SOURCE or _XOPEN_SOURCE had been defined, but portable applications cannot rely on this.

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-2024 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 c17 compilers not conforming to POSIX.1-2024 do not support trigraphs by default.

Implementations may support multiple programming environments with some of them conforming to this standard and some not conforming. The _POSIX_Vn_ILP* and _POSIX_Vn_LP* constants in <unistd.h>, and corresponding sysconf() and getconf calls, only indicate whether each programming environment is supported; they do not indicate anything about conformance of the environments that are supported. For example, an implementation may support the ILP32_OFF32 environment for legacy reasons with a 32-bit time_t, whereas in a conforming environment time_t is required to have a width of at least 64 bits. Application writers should consult an implementation's POSIX Conformance Document for information about the conformance of each supported programming environment.

EXAMPLES

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

    The following usage example compiles foo.c and creates the object file foo.o:

    c17 -c foo.c

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

    c17 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:

    c17 foo.c bar.o

    The following usage example preprocesses foo.c and bar.c to create foo.i and bar.i, compiles foo.i and bar.i to create foo.o and bar.o, then links foo.o and bar.o to create the executable file foobar. Each c17 execution would ideally be invoked from a separate rule in a makefile (see make ) with suitable dependencies so that each is only executed when it needs to be:

    c17 -E foo.c > foo.i
c17 -E bar.c > bar.i
c17 -c foo.i
c17 -c bar.i
c17 -o foobar foo.o 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 all pointer types, and an off_t type using at least 64 bits: 
    offbig_env=$(getconf _POSIX_V8_ILP32_OFFBIG)
if [ $offbig_env != "-1" ] && [ $offbig_env != "undefined" ]
then
    c17 $(getconf POSIX_V8_ILP32_OFFBIG_CFLAGS) \
    $(getconf POSIX_V8_THREADS_CFLAGS) -D_XOPEN_SOURCE=800 \
    $(getconf POSIX_V8_ILP32_OFFBIG_LDFLAGS) \
    $(getconf POSIX_V8_THREADS_LDFLAGS) foo.c -o foo \
    $(getconf POSIX_V8_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:

    c17 -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:

    c17 -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_V8_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_V8_WIDTH_RESTRICTED_ENVS)
do
    case $CENV in
    *OFF64*|*OFFBIG*) break ;;
    esac
done

    
# The chosen environment name can now be used like this:

    
c17 $(getconf ${CENV}_CFLAGS) -D _POSIX_C_SOURCE=202405L \
$(getconf ${CENV}_LDFLAGS) foo.c -o foo \
$(getconf ${CENV}_LIBS)
  5. The following example shows how to create a shared library that does not depend on any other shared library: 
    c17 -G -c foo.c bar.c
c17 -G -o foobar.so foo.o bar.o
  6. The following example shows how to create a dynamic executable that loads application specific shared libraries by searching a specified list of directories when it is executed: 
    c17 -G -c foo.c
c17 -G -o /path/to/dir1/foo.so foo.o
c17 -G -c bar.c
c17 -G -o /path/to/dir2/bar.so bar.o
c17 -B dynamic -L /path/to/dir1 -L /path/to/dir2 -R /path/to/dir1 \
    -R /path/to/dir2 -o foobar foobar.c -l foo -l bar

RATIONALE

The c17 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.

POSIX.1-2024 specifies that the c17 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, c17 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, c17 may attempt to open a.out and will hang in the open() call until another process opens the FIFO for reading. Then c17 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 c17 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.

Commands of the form c17 -c -o ... are frequently used to directly place the .o file into an alternative directory without a need to separately rename the output file. This helps to support concurrent compilations and out of tree builds.

Some implementations allow -c -o directory to produce directory/file.o even when there is more than one input file; however, portable applications using -c with -o must compile only one file at a time and must specify the final destination filename rather than a directory.

The shared library version of the c library is required to exist as a regular file because the dynamic linker needs to be able to load at least one library at execution time. Other standard shared libraries need not exist in their own right if the interfaces the standard requires them to provide exist in the c library; all that is required is that they are "found" when specified as -l option-arguments. Static versions of the standard libraries need not exist as regular files, even if they are found as static libraries when specified as -l option-arguments.

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

This standard requires that, when -E is used, lines beginning with '#' are output identifying the files processed as a result of #include directives in order that c17 -E can be used to generate makefile dependencies. See make . Usually such lines are output each time the origin of the subsequent lines in the output changes, and the line number after the '#' is the line number in the named file of the line from which the next line in the output was derived.

When the -R option is not included when an executable file or shared library is being created, some implementations use the environment variables LD_RUN_PATH and LD_LIBRARY_PATH to determine the directories to be searched for shared libraries.

Some implementations permit place-holders preceded by a <dollar-sign> character ('$'), such as $ORIGIN, in the -R directory option-argument to be evaluated at load time. Some implementations accept a colon separated list of directories for the path to search for shared libraries, with the same effect as specifying the -R option multiple times. However, these features are not universal.

The name of a shared library usually contains an element named so. Other implementation-defined elements are allowed for backwards compatibility with historical systems, and so that tools can be developed on conforming systems to create libraries for multiple environments. For example, Microsoft systems use the filename extension .dll (and do not allow following text) to denote a shared library. The standard allows additional characters to be used in the name of a library following an so element to permit shared library versioning information to be at the end of the library filename rather than requiring that any such strings appear before the final element of the library name.

The decision to standardize on so as a required element in a shared library name was intentional, as the alternative would have been standardizing things such as a new make macro $(SHLIB_EXT) that would otherwise be needed to write a portable makefile that can compile shared libraries despite not having a standardized element name.

If a combination of direct and indirect dependencies of a shared library would require different versions of another shared library, options that are not specified by the standard (such as -B direct) will probably need to be used when linking that shared library, so that at runtime the intended versions are found.

FUTURE DIRECTIONS

If this utility is directed to display a pathname that contains any bytes that have the encoded value of a <newline> character when <newline> is a terminator or separator in the output format being used, implementations are encouraged to treat this as an error. A future version of this standard may require implementations to treat this as an error.

If this utility is directed to create a new directory entry that contains any bytes that have the encoded value of a <newline> character, implementations are encouraged to treat this as an error. A future version of this standard may require implementations to treat this as an error.

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.

SEE ALSO

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

XBD 8. Environment Variables , 12.2 Utility Syntax Guidelines , 14. Headers

XSH exec , sysconf

CHANGE HISTORY

First released in Issue 8. Included for alignment with the ISO/IEC 9899:2018 standard.

End of informative text.
<<< Previous Home Next >>>