Header files

The application programming interface (API) of the C standard library is declared in a number of header files. Each header file contains one or more function declarations, data type definitions, and macros.

After a long period of stability, three new header files (iso646.h, wchar.h, and wctype.h) were added with Normative Addendum 1 (NA1), an addition to the C Standard ratified in 1995. Six more header files (complex.h, fenv.h, inttypes.h, stdbool.h, stdint.h, and tgmath.h) were added with C99, a revision to the C Standard published in 1999, and five more files (stdalign.h, stdatomic.h, stdnoreturn.h, threads.h, and uchar.h) with C11 in 2011. In total, there are now 29 header files:

Three of the header files (complex.h, stdatomic.h, and threads.h) are conditional features that implementations are not required to support.

The POSIX standard added several nonstandard C headers for Unix-specific functionality. Many have found their way to other architectures. Examples include fcntl.h and unistd.h. A number of other groups are using other nonstandard headers – the GNU C Library has alloca.h, and OpenVMS has the va_count() function.

Documentation

On Unix-like systems, the authoritative documentation of the API is provided in the form of man pages. On most systems, man pages on standard library functions are in section 3; section 7 may contain some more generic pages on underlying concepts (e.g. man 7 math_error in Linux).

Compiler built-in functions

Some compilers (for example, GCC^[7]) provide built-in versions of many of the functions in the C standard library; that is, the implementations of the functions are written into the compiled object file, and the program calls the built-in versions instead of the functions in the C library shared object file. This reduces function-call overhead, especially if function calls are replaced with inline variants, and allows other forms of optimization (as the compiler knows the control-flow characteristics of the built-in variants), but may cause confusion when debugging (for example, the built-in versions cannot be replaced with instrumented variants).

However, the built-in functions must behave like ordinary functions in accordance with ISO C. The main implication is that the program must be able to create a pointer to these functions by taking their address, and invoke the function by means of that pointer. If two pointers to the same function are derived in two different translation units in the program, these two pointers must compare equal; that is, the address comes by resolving the name of the function, which has external (program-wide) linkage.

Linking, libm

Under FreeBSD^[8] and glibc,^[9] some functions such as sin() are not linked in by default and are instead bundled in the mathematical library libm. If any of them are used, the linker must be given the directive -lm. POSIX requires that the c99 compiler supports -lm, and that the functions declared in the headers math.h, complex.h, and fenv.h are available for linking if -lm is specified, but does not specify if the functions are linked by default.^[10] musl satisfies this requirement by putting everything into a single libc library and providing an empty libm.^[11]

Detection

According to the C standard the macro __STDC_HOSTED__ shall be defined to 1 if the implementation is hosted. A hosted implementation has all the headers specified by the C standard. An implementation can also be freestanding which means that these headers will not be present. If an implementation is freestanding, it shall define __STDC_HOSTED__ to 0.

Buffer overflow vulnerabilities

Some functions in the C standard library have been notorious for having buffer overflow vulnerabilities and generally encouraging buggy programming ever since their adoption.^{[lower-alpha 1]} The most criticized items are:

• string-manipulation routines, including strcpy() and strcat(), for lack of bounds checking and possible buffer overflows if the bounds are not checked manually;
• string routines in general, for side-effects, encouraging irresponsible buffer usage, not always guaranteeing valid null-terminated output, linear length calculation;^{[lower-alpha 2]}
• printf() family of routines, for spoiling the execution stack when the format string does not match the arguments given. This fundamental flaw created an entire class of attacks: format string attacks;
• gets() and scanf() family of I/O routines, for lack of (either any or easy) input length checking.

Except the extreme case with gets(), all the security vulnerabilities can be avoided by introducing auxiliary code to perform memory management, bounds checking, input checking, etc. This is often done in the form of wrappers that make standard library functions safer and easier to use. This dates back to as early as The Practice of Programming book by B. Kernighan and R. Pike where the authors commonly use wrappers that print error messages and quit the program if an error occurs.

The ISO C committee published Technical reports TR 24731-1^[12] and is working on TR 24731-2^[13] to propose adoption of some functions with bounds checking and automatic buffer allocation, correspondingly. The former has met severe criticism with some praise,^[14][15] the latter received mixed responses. Despite this, TR 24731-1 has been implemented into Microsoft's C standard library and its compiler issues warnings when using old "insecure" functions.

Threading problems, vulnerability to race conditions

The strerror() routine is criticized for being thread unsafe and otherwise vulnerable to race conditions.

Error handling

The error handling of the functions in the C standard library is not consistent and sometimes confusing. According to the Linux manual page math_error, "The current (version 2.8) situation under glibc is messy. Most (but not all) functions raise exceptions on errors. Some also set errno. A few functions set errno, but do not raise an exception. A very few functions do neither."^[16]

POSIX standard library

POSIX, as well as SUS, specify a number of routines that should be available over and above those in the basic C standard library. The POSIX specification includes header files for, among other uses, multi-threading, networking, and regular expressions. These are often implemented alongside the C standard library functionality, with varying degrees of closeness. For example, glibc implements functions such as fork within libc.so, but before NPTL was merged into glibc it constituted a separate library with its own linker flag argument. Often, this POSIX-specified functionality will be regarded as part of the library; the basic C library may be identified as the ANSI or ISO C library.

BSD libc

BSD libc is a superset of the POSIX standard library supported by the C libraries included with BSD operating systems such as FreeBSD, NetBSD, OpenBSD and macOS. BSD libc has some extensions that are not defined in the original standard, many of which first appeared in 1994's 4.4BSD release (the first to be largely developed after the first standard was issued in 1989). Some of the extensions of BSD libc are:

• sys/tree.h – contains an implementation of red–black tree and splay tree^[17][18]
• sys/queue.h – implementations of Linked list, queues, tail queue, etc.^[19][20]
• fgetln() – defined in stdio.h. This can be used to read a file line by line.^[21][22][23]
• fts.h – contains some functions to traverse a file hierarchy^[24][25]
• db.h – some functions to connect to the Berkeley DB^[26][27]
• strlcat() and strlcpy() – secure alternatives for strncat() and strncpy()^{[28][29][30][31][32]}
• err.h – contains some functions to print formatted error messages^[33][34]
• vis.h – contains the vis() function. This function is used to display non-printable characters in a visual format.^[35][36][37]