Editing C standard library

{{Short description|Standard library for the C programming language}}
{{C Standard Library}}
The '''C standard library''', sometimes referred to as '''libc''',<ref>{{cite web |url=https://nullprogram.com/blog/2023/02/11 |title=My review of the C standard library in practice |last=Wellons |first=Chris |date=11 February 2023 |access-date=29 December 2024}}</ref> is the [[standard library]] for the [[C (programming language)|C programming language]], as specified in the [[ISO C]] standard.<ref name="c17io">[[International Organization for Standardization|ISO]]/[[International Electrotechnical Commission|IEC]] (2018). ''[[C17 (C standard revision)|ISO/IEC 9899:2018(E): Programming Languages - C]] §7''</ref> Starting from the original [[ANSI C]] standard, it was developed at the same time as the [[C POSIX library]], which is a superset of it.<ref>{{cite web |url=https://stackoverflow.com/questions/9376837/difference-bewteen-c-standard-library-and-c-posix-library |title=Difference between C standard library and C POSIX library |year=2012 |access-date=4 March 2015 |website=stackoverflow.com}}</ref> Since ANSI C was adopted by the [[International Organization for Standardization]],<ref name="ISOAdoptedAnsiC">{{cite web |title=C Standards |url=http://www.keil.com/support/docs/1893.htm |access-date=24 November 2011 |website=C: C Standards |publisher=Keil |language=en-US}}</ref> the C standard library is also called the '''ISO C library'''.<ref>{{cite web |url=http://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_1.html |title=The GNU C Library – Introduction |access-date=5 December 2013 |website=gnu.org}}</ref>

The C standard library provides [[macro (computer science)|macro]]s, [[Data type|type]] definitions and [[Function (computer programming)|functions]] for tasks such as [[character string (computer science)|string]] manipulation, mathematical computation, input/output processing, [[memory management]], and [[input/output]].

== Application programming interface (API) ==

=== {{Anchor|headers}}Header files ===

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

After a long period of stability, three new header files (<code>iso646.h</code>, <code>wchar.h</code>, and <code>wctype.h</code>) were added with ''Normative Addendum 1'' (NA1), an addition to the C Standard ratified in 1995. Six more header files (<code>complex.h</code>, <code>fenv.h</code>, <code>inttypes.h</code>, <code>stdbool.h</code>, <code>stdint.h</code>, and <code>tgmath.h</code>) were added with [[C99]], a revision to the C Standard published in 1999, five more files (<code>stdalign.h</code>, <code>stdatomic.h</code>, <code>stdnoreturn.h</code>, <code>threads.h</code>, and <code>uchar.h</code>) with [[C11 (C standard revision)|C11]] in 2011 and one more file (<code>stdbit.h</code>) with [[C23 (C standard revision)|C23]] in 2023. In total, there are now 30 header files:

{| class="wikitable sortable"
|-
! Name !! From !! Description
|-
| <code>[[assert.h|<assert.h>]]</code> || || Declares the [[assertion (computing)|assert]] macro, used to assist with detecting logical errors and other types of bugs while [[debugging]] a program.
|-
| <code>[[complex.h|<complex.h>]]</code> || C99 || Defines a [[C mathematical functions#complex.h|set of functions]] for manipulating [[complex number]]s.
|-
| <code>[[ctype.h|<ctype.h>]]</code> || || Defines [[C character classification|set of functions]] used to classify characters by their types or to convert between upper and lower case in a way that is independent of the used [[character set]] (typically [[ASCII]] or one of its extensions, although implementations utilizing [[EBCDIC]] are also known).
|-
| <code>[[errno.h|<errno.h>]]</code> || || For testing error codes reported by library functions.
|-
| <code>[[fenv.h|<fenv.h>]]</code> || C99 || Defines a [[C mathematical functions#fenv.h|set of functions]] for controlling [[floating-point]] environment.
|-
| <code>[[float.h|<float.h>]]</code> || || Defines [[C data types#float.h|macro constants]] specifying the implementation-specific properties of the [[floating-point]] library.
|-
| <code>[[inttypes.h|<inttypes.h>]]</code> || C99 || Defines [[C data types#inttypes.h|exact-width integer types]].
|-
| <code>[[iso646.h|<iso646.h>]]</code> || NA1 || Defines [[C alternative tokens|several macros]] that implement alternative ways to express several standard tokens. For programming in [[ISO 646]] variant character sets.
|-
| <code>[[limits.h|<limits.h>]]</code> || || Defines [[C data types#limits.h|macro constants]] specifying the implementation-specific properties of the integer types.
|-
| <code><locale.h></code> || || Defines [[C localization functions|localization functions]].
|-
| <code>[[math.h|<math.h>]]</code> || || Defines [[C mathematical functions|common mathematical functions]].
|-
| <code>[[setjmp.h|<setjmp.h>]]</code> || || Declares the macros <code>setjmp</code> and <code>longjmp</code>, which are used for non-local exits.
|-
| <code>[[signal.h|<signal.h>]]</code> || || Defines [[C signal handling|signal-handling functions]].
|-
| <code><stdalign.h></code> || C11 || For querying and specifying the [[Data structure alignment|alignment]] of objects.
|-
| <code>[[stdarg.h|<stdarg.h>]]</code> || || For accessing a varying number of arguments passed to functions.
|-
| <code><stdatomic.h></code> || C11 || For [[Linearizability|atomic operations]] on data shared between threads.
|-
| <code><stdbit.h></code> || C23 || For byte ordening and bit representation.
|-
| <code>[[stdbool.h|<stdbool.h>]]</code> || C99 || Defines [[C data types#stdbool.h|a Boolean data type]].
|-
| <code>[[stddef.h|<stddef.h>]]</code> || || Defines [[C data types#stddef.h|several useful types and macros]].
|-
| <code>[[stdint.h|<stdint.h>]]</code> || C99 || Defines [[C data types#stdint.h|exact-width integer types]].
|-
| <code>[[stdio.h|<stdio.h>]]</code> || || Defines [[C file input/output|core input and output functions]]
|-
| <code><stdlib.h></code> || || Defines [[C string handling#stdlib.h|numeric conversion functions]], [[C mathematical functions#stdlib.h|pseudo-random numbers generation functions]], [[C dynamic memory allocation|memory allocation]], [[C process control|process control functions]]
|-
| <code><stdnoreturn.h></code> || C11 || For specifying non-returning functions
|-
| <code>[[string.h|<string.h>]]</code> || || Defines [[C string handling|string-handling functions]]
|-
| <code>[[tgmath.h|<tgmath.h>]]</code> || C99 || Defines [[C mathematical functions#tgmath.h|type-generic mathematical functions]].
|-
| <code><threads.h></code> || C11 || Defines functions for managing multiple [[Thread (computer science)|threads]], [[Mutual exclusion|mutexes]] and [[Monitor (synchronization)|condition variables]]
|-
| <code>[[time.h|&lt;time.h&gt;]]</code> || || Defines [[C date and time functions|date- and time-handling functions]]
|-
| <code><uchar.h></code> || C11 || Types and functions for manipulating [[Unicode]] characters
|-
| <code>[[wchar.h|<wchar.h>]]</code> || NA1 || Defines [[C string handling|wide-string-handling functions]]
|-
| <code>[[wctype.h|<wctype.h>]]</code> || NA1 || Defines [[C character classification|set of functions]] used to classify wide characters by their types or to convert between upper and lower case
|}

Three of the header files (<code>complex.h</code>, <code>stdatomic.h</code>, and <code>threads.h</code>) 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 <code>[[fcntl.h]]</code> and <code>[[unistd.h]]</code>. A number of other groups are using other nonstandard headers – the [[GNU C Library]] has <code>alloca.h</code>, and [[OpenVMS]] has the <code>va_count()</code> function.

=== Documentation ===
On Unix-like systems, the authoritative documentation of the API is provided in the form of [[man page]]s. On most systems, man pages on standard library functions are in section&nbsp;3; section&nbsp;7 may contain some more generic pages on underlying concepts (e.g. <code>man 7 math_error</code> in [[Linux]]).

== Implementations ==
[[Unix-like]] systems typically have a C library in [[shared library]] form, but the header files (and compiler toolchain) may be absent from an installation so C development may not be possible. The C library is considered part of the operating system on Unix-like systems; in addition to functions specified by the C standard, it includes other functions that are part of the operating system API, such as functions specified in the [[POSIX]] standard. The C library functions, including the ISO C standard ones, are widely used by programs, and are regarded as if they were not only an implementation of something in the C language, but also ''de facto'' part of the operating system interface. Unix-like operating systems generally cannot function if the C library is erased. This is true for applications which are dynamically as opposed to statically linked. Further, the kernel itself (at least in the case of Linux) operates independently of any libraries.

On Microsoft Windows, the core system dynamic libraries ([[dynamic-link library|DLLs]]) provide an implementation of the C standard library for the [[Microsoft Visual&nbsp;C++]] compiler v6.0; the C standard library for newer versions of the Microsoft Visual&nbsp;C++ compiler is provided by each compiler individually, as well as ''redistributable'' packages. Compiled applications written in C are either statically linked with a C library, or linked to a dynamic version of the library that is shipped with these applications, rather than relied upon to be present on the targeted systems. Functions in a compiler's C library are not regarded as interfaces to Microsoft Windows.

Many C library implementations exist, provided with both various operating systems and C compilers.  Some of the popular implementations are the following:

* The [[BSD libc]], various implementations distributed with [[Berkeley Software Distribution|BSD]]-derived operating systems
* [[GNU C Library]] (glibc), used in [[GNU Hurd]], [[GNU/kFreeBSD]], and most [[Linux]] distributions
* [[Windows library files#CRT|Microsoft C run-time library]], part of [[Microsoft Visual C++]]. There are two versions of the library: MSVCRT that was a redistributable till v12 / Visual Studio 2013 with low C99 compliance, and a new one UCRT (Universal C Run Time) that is part of Windows 10 and 11, so always present to link against, and is C99 compliant too [https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt?view=msvc-170].
* [[dietlibc]], an alternative small implementation of the C standard library (MMU-less)
* [[uClibc|μClibc]], a C standard library for embedded [[μClinux]] systems (MMU-less)
** [[uClibc|uclibc-ng]], an embedded C library, fork of μClibc, still maintained, with [[memory management unit]] (MMU) support
* [[Newlib]], a C standard library for embedded systems (MMU-less)<ref>{{cite web |url=http://www.cygwin.com/ml/newlib/2006/msg00224.html |title=Re: Does Newlib support mmu-less CPUs? |publisher=Cygwin.com |date=23 March 2006 |access-date=28 October 2011 |archive-url=https://web.archive.org/web/20081122063741/http://www.cygwin.com/ml/newlib/2006/msg00224.html |archive-date=22 November 2008 |url-status=dead}}</ref> and used in the [[Cygwin]] GNU distribution for Windows
* [[klibc]], primarily for booting Linux systems
* [[musl]], another lightweight C standard library implementation for Linux systems<ref>{{cite web |url=http://www.etalabs.net/musl/ |title=musl libc |publisher=Etalabs.net |access-date=28 October 2011}}</ref>
* [[Bionic (software)|Bionic]], originally developed by Google for the Android embedded system operating system, derived from BSD libc
* [https://keithp.com/picolibc picolibc], developed by [[Keith Packard]], targeting small embedded systems with limited RAM, based on code from [[Newlib]] and [https://www.nongnu.org/avr-libc/ AVR Libc]

=== Compiler built-in functions ===
Some compilers (for example, [[GNU Compiler Collection|GCC]]<ref>{{cite book |author=FSF |author-link=Free Software Foundation |date=2024 |chapter=6.64 Other Built-in Functions Provided by GCC |chapter-url=https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html |title=A GNU Manual |url=https://gcc.gnu.org/onlinedocs/gcc/index.html |publisher=self-published}}</ref>) 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 function|inline]] variants, and allows other forms of [[compiler optimization|optimization]] (as the compiler knows the [[control flow|control-flow]] characteristics of the built-in variants), but may cause confusion when debugging (for example, the built-in versions cannot be replaced with [[instrumentation (computer programming)|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<ref>{{cite web |title=Compiling with cc |url=http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/tools-compiling.html |access-date=2 March 2013}}</ref> and glibc,<ref>{{cite web |last1=Weimer |first1=Florian |title=c - What functions is the libm intended for? |url=https://stackoverflow.com/questions/54054925/what-functions-is-the-libm-intended-for |website=Stack Overflow |access-date=24 February 2021}}</ref> 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 <code>-lm</code>. POSIX requires that the c99 compiler supports <code>-lm</code>, and that the functions declared in the headers <code>math.h</code>, <code>complex.h</code>, and <code>fenv.h</code> are available for linking if <code>-lm</code> is specified, but does not specify if the functions are linked by default.<ref>{{cite web |title=c99 - compile standard C programs |url=https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html |website=The Open Group Base Specifications Issue 7, 2018 edition |publisher=The Open Group |access-date=24 February 2021}}</ref> musl satisfies this requirement by putting everything into a single libc library and providing an empty libm.<ref>{{cite web |title=musl FAQ |url=https://www.musl-libc.org/faq.html |website=www.musl-libc.org |access-date=24 February 2021}}</ref>

=== Detection ===
According to the C standard the macro <code>__STDC_HOSTED__</code> 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 <code>__STDC_HOSTED__</code> to '''0'''.

== Problems and workarounds ==

=== {{Anchor|BUFFER-OVERFLOW}}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.<ref>{{cite web |url=https://www.techtarget.com/searchsecurity/definition/buffer-overflow |title=buffer overflow |last=Cobb |first=Michael |date=July 2021 |website=TechTarget |access-date=29 December 2024}}</ref>{{efn|[[Morris worm]] that takes advantage of the well-known vulnerability in <code>gets()</code> have been created as early as in 1988.}} The most criticized items are:
* [[C string handling|string-manipulation routines]], including <code>strcpy()</code> and <code>strcat()</code>, for lack of [[bounds checking]] and possible buffer overflows if the bounds are not checked manually;
* string routines in general, for [[side effect (computer science)|side-effects]], encouraging irresponsible buffer usage, not always guaranteeing valid [[null-terminated string|null-terminated]] output, linear length calculation;{{efn|in C standard library, string length calculation and looking for a string's end have [[Linear time|linear time complexities]] and are inefficient when used on the same or related strings repeatedly}}
* <code>[[printf]]()</code> family of routines, for spoiling the [[call stack|execution stack]] when the format string does not match the arguments given. This fundamental flaw created an entire class of attacks: [[format string attack]]s;
* <code>[[gets()|gets]]()</code> and <code>[[scanf]]()</code> family of I/O routines, for lack of (either any or easy) input length checking.

Except the extreme case with <code>gets()</code>, 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<ref>{{cite web |url=http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1225.pdf |title=ISO/IEC TR 24731-1: Extensions to the C Library, Part I: Bounds-checking interfaces |date=28 March 2007 |access-date=13 March 2014 |publisher=open-std.org }}</ref> and is working on TR 24731-2<ref>{{cite web |url=http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1337.pdf |title=ISO/IEC WDTR 24731-2: Extensions to the C Library, Part II: Dynamic Allocation Functions |date=10 August 2008 |access-date=13 March 2014 |publisher=open-std.org }}</ref> to propose adoption of some functions with bounds checking and automatic buffer allocation, correspondingly. The former has met severe criticism with some praise,<ref>[https://stackoverflow.com/questions/372980/do-you-use-the-tr-24731-safe-functions-in-your-c-code Do you use the TR 24731 'safe' functions in your C code?] - Stack overflow</ref><ref>{{cite web |url=http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1106.txt |title=Austin Group Review of ISO/IEC WDTR 24731 |access-date=28 October 2011}}</ref> and the latter saw mixed response.

Despite concerns, TR 24731-1 was integrated into the C standards track in ISO/IEC 9899:2011 (C11), Annex K (''Bounds-checking interfaces''), and implemented approximately in Microsoft’s C/++ runtime (CRT) library for the Win32 and Win64 platforms.

(By default, Microsoft Visual Studio’s C and C++ compilers issue warnings when using older, "insecure" functions. However, Microsoft’s implementation of TR 24731-1 is subtly incompatible with both TR 24731-1 and Annex K,<ref>{{cite web |url=http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm#implementations |title=Field Experience With Annex K—''Bounds Checking Interfaces'' |access-date=9 October 2024}}</ref> so it’s common for portable projects to disable or ignore these warnings. They can be disabled directly by issuing <syntaxhighlight lang="c" copy class="nowrap"
  >#pragma warning(disable : 4996)</syntaxhighlight> before/around the call <nowiki>site[s]</nowiki> in question, or indirectly by issuing <syntaxhighlight lang="c" copy class="nowrap"
  >#define _CRT_SECURE_NO_WARNINGS 1</syntaxhighlight>
before including any headers.<ref>{{cite web |url=https://learn.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt#eliminating-deprecation-warnings |title=Security Features in the CRT—Eliminating deprecation warnings |date=February 2023 |access-date=9 October 2024}}</ref> Command-line option <code>/D_CRT_NO_SECURE_WARNINGS=1</code> should have the same effect as this <code lang="c">#define</code>.)

=== Threading problems, vulnerability to race conditions ===
The <code>[[strerror]]()</code> routine is criticized for being [[thread safety|thread unsafe]] and otherwise vulnerable to [[race condition]]s.

=== 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 <code>math_error</code>, "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."<ref>{{cite web |url=http://man7.org/linux/man-pages/man7/math_error.7.html |title=math_error - detecting errors from mathematical functions |date=11 August 2008 |access-date=13 March 2014 |website=man7.org}}</ref>

== Standardization ==
{{Main article|C (programming language)#History|l1=C (programming language) § History}}

The original [[C (programming language)|C language]] provided no built-in functions such as I/O operations, unlike traditional languages such as [[COBOL]] and [[Fortran]].{{Citation needed|date=November 2010}} Over time, user communities of C shared ideas and implementations of what is now called C standard libraries. Many of these ideas were incorporated eventually into the definition of the standardized C language.

Both [[Unix]] and C were created at [[Bell Labs|AT&T's Bell Laboratories]] in the late 1960s and early 1970s. During the 1970s the C language became increasingly popular. Many universities and organizations began creating their own variants of the language for their own projects. By the beginning of the 1980s compatibility problems between the various C implementations became apparent. In 1983 the [[American National Standards Institute]] (ANSI) formed a committee to establish a standard specification of C known as "[[ANSI C]]". This work culminated in the creation of the so-called C89 standard in 1989. Part of the resulting standard was a set of [[software libraries]] called the ANSI C standard library.

=== POSIX standard library ===
{{Main article|C POSIX library}}

[[POSIX]], as well as [[Single Unix Specification|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, [[POSIX Threads|multi-threading]], [[Berkeley sockets|networking]], and [[regular expression]]s. These are often implemented alongside the C standard library functionality, with varying degrees of closeness. For example, [[glibc]] implements functions such as <code>[[fork (operating system)|fork]]</code> within <code>libc.so</code>, 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 [[International Organization for Standardization|ISO]] C library.

=== BSD libc ===
'''BSD libc''' is a superset of the POSIX standard library supported by the C libraries included with [[BSD]] [[operating system]]s 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 [[BSD#4.4BSD and descendants|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:

* <code>sys/tree.h</code>{{snd}} contains an implementation of [[red–black tree]] and [[splay tree]]<ref>{{cite web |url=http://man.freebsd.org/tree |title=tree |website=Man.freebsd.org |date=27 December 2007 |access-date=25 August 2013}}</ref><ref>{{cite web |url=http://bxr.su/o/sys/sys/tree.h |title=Super User's BSD Cross Reference: /OpenBSD/sys/sys/tree.h |website=bxr.su}}</ref>
* <code>sys/queue.h</code>{{snd}} implementations of [[Linked list]], [[queue (data structure)|queues]], [[tail queue]], etc.<ref>{{cite web |url=http://man.freebsd.org/queue |title=queue |website=Man.freebsd.org |date=13 May 2011 |access-date=25 August 2013}}</ref><ref>{{cite web |url=http://bxr.su/o/sys/sys/queue.h |title=Super User's BSD Cross Reference: /OpenBSD/sys/sys/queue.h |website=bxr.su}}</ref>
* <code>fgetln()</code>{{snd}} defined in <code>stdio.h</code>. This can be used to read a file line by line.<ref>{{cite web |url=http://man.freebsd.org/fgetln |title=fgetln |website=Man.freebsd.org |date=19 April 1994 |access-date=25 August 2013}}</ref><ref>{{cite web |url=http://bxr.su/o/lib/libc/stdio/fgetln.c#fgetln |title=Super User's BSD Cross Reference: /OpenBSD/lib/libc/stdio/fgetln.c |website=bxr.su}}</ref><ref>{{cite web |url=http://bxr.su/o/include/stdio.h |title=Super User's BSD Cross Reference: /OpenBSD/include/stdio.h |website=bxr.su}}</ref>
* <code>fts.h</code>{{snd}} contains some functions to traverse a file hierarchy<ref>{{cite web |url=http://man.freebsd.org/fts |title=fts|website=Man.freebsd.org |date=18 March 2012 |access-date=25 August 2013}}</ref><ref>{{cite web |url=http://bxr.su/o/include/fts.h |title=Super User's BSD Cross Reference: /OpenBSD/include/fts.h |website=bxr.su}}</ref>
* <code>db.h</code>{{snd}} some functions to connect to the [[Berkeley DB]]<ref>{{cite web |url=http://man.freebsd.org/db |title=db |website=Man.freebsd.org |date=10 September 2010 |access-date=25 August 2013}}</ref><ref>{{cite web |url=http://bxr.su/o/include/db.h |title=Super User's BSD Cross Reference: /OpenBSD/include/db.h |website=bxr.su}}</ref>
* <code>strlcat()</code> and <code>strlcpy()</code>{{snd}} secure alternatives for <code>strncat()</code> and <code>strncpy()</code><ref>Miller, Todd C. and Theo de Raadt. [http://www.usenix.org/events/usenix99/millert.html strlcpy and strlcat - consistent, safe, string copy and concatenation]. Proceedings of the 1999 USENIX Annual Technical Conference, June 6–11, 1999, pp. 175–178.</ref><ref>{{cite web |url=http://bxr.su/o/lib/libc/string/strlcat.c |title=Super User's BSD Cross Reference: /OpenBSD/lib/libc/string/strlcat.c |website=bxr.su}}</ref><ref>{{cite web |url=http://bxr.su/o/lib/libc/string/strlcpy.c |title=Super User's BSD Cross Reference: /OpenBSD/lib/libc/string/strlcpy.c |website=bxr.su}}</ref><ref>{{cite web |url=http://bxr.su/o/lib/libc/string/strncat.c |title=Super User's BSD Cross Reference: /OpenBSD/lib/libc/string/strncat.c |website=bxr.su}}</ref><ref>{{cite web |url=http://bxr.su/o/lib/libc/string/strncpy.c |title=Super User's BSD Cross Reference: /OpenBSD/lib/libc/string/strncpy.c |website=bxr.su}}</ref>
* <code>err.h</code>{{snd}} contains some functions to print formatted error messages<ref>{{cite web |url=http://man.freebsd.org/err |title=err|website=Man.freebsd.org |date=29 March 2012 |access-date=25 August 2013}}</ref><ref>{{cite web |url=http://bxr.su/o/include/err.h |title=Super User's BSD Cross Reference: /OpenBSD/include/err.h |website=bxr.su}}</ref>
* <code>vis.h</code>{{snd}} contains the <code>vis()</code> function. This function is used to display non-printable characters in a visual format.<ref>{{cite web |title=vis(3) |url=http://www.freebsd.org/cgi/man.cgi?query=vis&sektion=3&apropos=0&manpath=FreeBSD+9.1-RELEASE |website=Man.FreeBSD.org |access-date=14 September 2013}}</ref><ref>{{cite web |url=http://bxr.su/o/lib/libc/gen/vis.c#vis |title=Super User's BSD Cross Reference: /OpenBSD/lib/libc/gen/vis.c |website=bxr.su}}</ref><ref>{{cite web |url=http://bxr.su/o/include/vis.h |title=Super User's BSD Cross Reference: /OpenBSD/include/vis.h |website=bxr.su}}</ref>

== The C standard library in other languages ==
Some languages include the functionality of the standard C library in their own libraries. The library may be adapted to better suit the language's structure, but the [[operational semantics]] are kept similar.

=== C++ ===
The [[C++]] language incorporates the majority of the C standard library’s constructs into its own, excluding C-specific machinery. C standard library functions are exported from the C++ standard library in two ways.

For backwards-/cross-compatibility to C and pre-Standard C++, functions can be accessed in the global [[namespace (programming)|namespace]] ({{mono|::}}), after {{code|#include|lang=cpp}}ing the C standard header name as in C.<ref>{{citation |url=https://en.cppreference.com/w/cpp/header#C_compatibility_headers |access-date=9 October 2024 |title=C++ Standard Library Headers—C compatibility headers}}</ref>{{^|This should probably be interwiki}} Thus, the C++98 program <syntaxhighlight lang="cpp">#include <stdio.h>
int main() {
	return ::puts("Hello, world!") == EOF;
}</syntaxhighlight> should exhibit (apparently-)identical behavior to [[ANSI_C#C95|C95]] program <syntaxhighlight lang="c">#include <stdio.h>
int main(void) {
	return puts("Hello, world!") == EOF;
}</syntaxhighlight>

From [[C++98]] on, C functions are also made available in namespace {{mono|::std}} (e.g., C {{mono|printf}} as C++ {{mono|::std::printf}}, {{mono|atoi}} as {{mono|::std::atoi}}, {{mono|feof}} as {{mono|::std::feof}}), by including header <code lang="cpp">&lt;c{{varserif|hdrname}}&gt;</code> instead of corresponding C header <code lang="cpp">&lt;{{varserif|hdrname}}.h&gt;</code>. E.g., {{mono|&lt;cstdio&gt;}} substitutes for {{mono|&lt;stdio.h&gt;}} and {{mono|&lt;cmath&gt;}} for {{mono|&lt;math.h&gt;}}; note lack of ''{{mono|.h}}'' extension on C++ header names.

Thus, an equivalent (generally preferable) C++≥98 program to the above two is: <syntaxhighlight lang="cpp"
>#include <cstdio>
int main() {
	return std::puts("Hello, world") == EOF;
}</syntaxhighlight>

A {{code|using namespace ::std|lang=cpp}} declaration above or within 
{{mono|main}} can be issued to apply the {{mono|::std::}} prefix automatically, although it’s generally considered poor practice to use it globally in headers because it pollutes the global namespace.<ref>{{cite web |url=https://websites.umich.edu/~eecs381/handouts/NamespaceGuide.pdf#page=2 |first=David |last=Kieras |title=Using "using": How to use the std namespace |publisher=EECS Department, University of Michigan |website=EECS381 Handouts |access-date=9 October 2024 |date=15 February 2015 |format=PDF |url-status=live |archive-url=https://web.archive.org/web/20221224070046/https://websites.umich.edu/~eecs381/handouts/NamespaceGuide.pdf#page=2 |archive-date=24 December 2022 |quote=A single <code>using namespace std;</code> statement in a single header file in a complex project can make a mess out of the namespace management for the whole project. <em>So, no top level [<nowiki /><code>using namespace</code><nowiki />] statements in a header file!</em>}}</ref>

A few of the C++≥98 versions of C’s headers are missing; e.g., C≥11 {{mono|&lt;stdnoreturn.h&gt;}} and {{mono|&lt;threads.h&gt;}} have no C++ counterparts.<ref>{{cite web |url=https://en.cppreference.com/w/cpp/header#Unsupported_C_headers |title=C++ Standard Library headers—Unsupported C headers |access-date=9 October 2024}}</ref>

Others are reduced to placeholders, such as (until [[C++20]]) {{mono|&lt;ciso646&gt;}} for C95 {{mono|&lt;iso646.h&gt;}}, all of whose requisite macros are rendered as keywords in C++98. C-specific syntactic constructs aren’t generally supported, even if their header is.<ref>{{cite web |url=https://en.cppreference.com/w/cpp/header#Meaningless_C_headers |title=C++ Standard Library headers—Meaningless C headers |access-date=9 October 2024}}</ref>

Several C headers exist primarily for C++ compatibility, and these tend to be near-empty in C++. For example, [[C99]]–[[C17 (C standard revision)|17]] {{mono|&lt;stdbool.h&gt;}} require only <syntaxhighlight lang="c" highlight="4" class="nowrap"
>#define bool _Bool
#define false 0
#define true 1
#define __bool_true_false_are_defined 1</syntaxhighlight> in order to feign support for the C++98 {{mono|bool}}, {{mono|false}}, and {{mono|true}} keywords in C. [[C++11]] requires {{mono|&lt;stdbool.h&gt;}} and {{mono|&lt;cstdbool&gt;}} for compatibility, but all they need to define is {{mono|__bool_true_false_are_defined}}. [[C23 (C standard revision)|C23]] obsoletes older {{mono|_Bool}} keyword in favor of new, C++98-equivalent {{mono|bool}}, {{mono|false}}, and {{mono|true}} keywords, so the C≥23 and C++≥11 {{mono|&lt;stdbool.h&gt;}}/{{mono|&lt;cstdbool&gt;}} headers are fully equivalent. (In particular, C23 doesn’t require any {{mono|__STDC_VERSION_BOOL_H__}} macro for {{mono|&lt;stdbool.h&gt;}}.)

Access to C library functions via namespace {{mono|::std}} and the C++≥98 header names is preferred where possible. To encourage adoption, [[C++98]] obsoletes the C (''{{mono|*.h}}'') header names, so it’s possible that use of C compatibility headers will cause an especially strict C++98–[[C++20|20]] preprocessor to raise a diagnostic of some sort. However, [[C++23]] (unusually) <em>de-</em>obsoletes these headers, so newer C++ implementations/modes shouldn’t complain without being asked to specifically.<ref>{{cite web |url=https://en.cppreference.com/w/cpp/header#C_compatibility_headers |title=C++ Standard Library headers—C compatibility headers |access-date=9 October 2024}}</ref>

{{^|These↓↓ should probably be expanded and given their own subsections alongside C++ and Python. At the very least, citation needed!}}
Other languages take a similar approach, placing C compatibility functions/routines under a common namespace; these include [[D (programming language)|D]], [[Perl]], and [[Ruby (programming language)|Ruby]].
{{^|PHP is another prominent example, and some basics like `printf`, `puts`, `toupper`, and `sqrt` show up in other Unixy languages such as POSIX shell script and Awk. Probably a trailing §(#Other languages) would be best.}}

=== Python ===
[[CPython]] includes wrappers for some of the C library functions in its own common library, and it also grants more direct access to C functions and variables via its ''{{mono|ctypes}}'' package.<ref>{{cite web |url=https://docs.python.org/3/library/ctypes.html |title=ctypes—A foreign function library for Python |publisher=docs.python.com |access-date=9 October 2024}}</ref>

More generally, [[Python (programming language)|Python]] [[History of Python#Version 2|2.{{var|x}}]] specifies the built-in file objects as being “implemented using C's ''stdio'' package,"<ref>{{cite web |url=https://docs.python.org/2/library/stdtypes.html#bltin-file-objects#bltin-file-objects |title=The Python Standard Library, §5.9: File Objects |access-date=9 October 2024 |quote=File objects are implemented using C’s <i>stdio</i> package and can be created with the built-in <code>open()</code> function.}}</ref> and frequent reference is made to C standard library behaviors; the available operations ({{code|open|lang=python}}, {{code|read|lang=python}}, {{code|write|lang=python}} {{^|Could link these to Python2 docs, but I’m here for C and C++}}, etc.) are expected to have the same behavior as the corresponding C functions ({{code|fopen|lang=c}}, {{code|fread|lang=c}}, {{code|fwrite|lang=c}}, etc.).

[[History of Python#Version 3|Python 3]]’s specification relies considerably less on C specifics than [[History of Python#Version 2|Python 2]], however.

=== Rust ===
[[Rust (programming language)|Rust]] offers crate {{mono|libc}}, which allows various C standard (and other) library functions and type definitions to be used.<ref>{{cite web |url=https://docs.rs/libc/latest/libc/ |title=Crate ''libc'' |website=Rust Crates |access-date=9 October 2024}}</ref>

== Comparison to standard libraries of other languages ==
The C standard library is small compared to the standard libraries of some other languages. The C library provides a basic set of mathematical functions, string manipulation, [[type conversion]]s, and file and console-based I/O. It does not include a standard set of "[[container (data structure)|container types]]" like the [[C++]] [[Standard Template Library]], let alone the complete [[graphical user interface]] (GUI) toolkits, networking tools, and profusion of other functionality that [[Java (software platform)|Java]] and the [[.NET Framework]] provide as standard. The main advantage of the small standard library is that providing a working ISO C environment is much easier than it is with other languages, and consequently porting C to a new platform is comparatively easy.

== See also ==
* [[C++ Standard Library]]

== Notes ==
{{Notelist}}

== References ==
{{Reflist|30em}}

== Further reading ==
* {{cite book |last=Plauger |first=P.J. |author-link=P. J. Plauger |title=The Standard C library |edition=1 |year=1992 |publisher=Prentice Hall |isbn=978-0131315099}}

== External links ==
*[https://web.archive.org/web/20150118141700/http://www.acm.uiuc.edu/webmonkeys/book/c_guide/index.html The C Library Reference Guide]
*[http://www.schweikhardt.net/identifiers.html Handy list of which headers are in which standard]
* Microsoft [https://docs.microsoft.com/en-us/cpp/c-runtime-library/run-time-routines-by-category Universal C runtime routines by category] on MSDN
* NetBSD [https://man.netbsd.org/intro.3 C libraries manual] {{Webarchive|url=https://web.archive.org/web/20151223092755/http://netbsd.gw.com/cgi-bin/man-cgi?intro+3+NetBSD-current |date=23 December 2015 }} and [http://BXR.SU/NetBSD/lib/libc/ full C library source]
* [http://man.cat-v.org/unix-1st/3/ Manual pages for the original C standard libraries in Unix]

{{C programming language|state=expanded}}

{{DEFAULTSORT:C Standard Library}}
[[Category:C standard library| ]]
[[Category:C (programming language)]]