Biblioteca estándar de C

La interfaz de programación de aplicaciones (API) de la biblioteca estándar de C se declara en varios archivos de cabecera . Cada archivo de cabecera contiene una o más declaraciones de funciones, definiciones de tipos de datos y macros.

Una implementación de una versión del estándar para el lenguaje C puede describirse como alojada o independiente . Una implementación alojada admite el estándar completo y requiere que estén presentes todos los archivos de cabecera especificados en el estándar; estas son implementaciones típicas para programas que se ejecutan en un sistema operativo. Una implementación independiente no requiere implementar características del lenguaje en la biblioteca C, salvo aquellas especificadas en esa versión del sistema operativo como necesarias para las implementaciones independientes; estas son implementaciones típicas para programas que se ejecutan en un sistema operativo muy limitado o directamente en el hardware.

Tras un largo período de estabilidad, se añadieron tres nuevos archivos de cabecera ( <iso646.h>, <wchar.h>, y ) con el Anexo Normativo 1 (NA1), una adición al estándar C ratificado en 1995. Se añadieron seis archivos de cabecera más ( , , , , , y ) con C99 , una revisión del estándar C publicada en 1999, cinco archivos más ( , , , , y ) con C11 en 2011 y dos archivos más ( y ) con C23 en 2023. En total, ahora hay 31 archivos de cabecera:<wctype.h><complex.h><fenv.h><inttypes.h><stdbool.h><stdint.h><tgmath.h><stdalign.h><stdatomic.h><stdnoreturn.h><threads.h><uchar.h><stdbit.h><stdckdint.h>

Leyenda:  : Obsoleto : Eliminado  

Tres de los archivos de cabecera ( <complex.h>, <stdatomic.h>, y <threads.h>) son características condicionales que las implementaciones no están obligadas a admitir.

El estándar POSIX añadió varios encabezados C no estándar para funcionalidades específicas de Unix. Muchos han encontrado su camino a otras arquitecturas. Algunos ejemplos son y . Otros grupos utilizan otros encabezados no estándar: la biblioteca C de GNU tiene , y OpenVMS tiene la función.<fcntl.h><unistd.h><alloca.h>va_count()

En los sistemas tipo Unix, la documentación autorizada de la API se proporciona en forma de páginas man . En la mayoría de los sistemas, las páginas man sobre las funciones de la biblioteca estándar se encuentran en la sección  3; la sección  7 puede contener algunas páginas más genéricas sobre conceptos subyacentes (por ejemplo, man 7 math_erroren Linux ).

Algunos compiladores (por ejemplo, GCC ^{[ 8 ]} ) proporcionan versiones integradas de muchas de las funciones de la biblioteca estándar de C; es decir, las implementaciones de las funciones se escriben en el archivo objeto compilado , y el programa llama a las versiones integradas en lugar de a las funciones del archivo objeto compartido de la biblioteca de C. Esto reduce la sobrecarga de las llamadas a funciones, especialmente si estas se reemplazan por variantes en línea , y permite otras formas de optimización (ya que el compilador conoce las características de flujo de control de las variantes integradas), pero puede causar confusión durante la depuración (por ejemplo, las versiones integradas no se pueden reemplazar por variantes instrumentadas ).

Sin embargo, las funciones integradas deben comportarse como funciones ordinarias, de acuerdo con la norma ISO C. Esto implica que el programa debe poder crear un puntero a estas funciones a partir de su dirección e invocarlas mediante dicho puntero. Si se obtienen dos punteros a la misma función en dos unidades de traducción diferentes del programa, estos dos punteros deben ser iguales; es decir, la dirección se obtiene resolviendo el nombre de la función, que tiene un enlace externo (a nivel de programa).

Bajo FreeBSD ^{[ 9 ]} y glibc, ^{[ 10 ]} algunas funciones como sin()no se enlazan por defecto y en su lugar se agrupan en la biblioteca matemática libm . Si se utiliza alguna de ellas, se debe proporcionar al enlazador la directiva -lm. POSIX requiere que el compilador c99 admita -lm, y que las funciones declaradas en los encabezados <math.h>, <complex.h>, y <fenv.h>estén disponibles para enlazar si -lmse especifica, pero no especifica si las funciones se enlazan por defecto. ^{[ 11 ]} musl satisface este requisito al colocar todo en una única biblioteca libc y proporcionar una libm vacía. ^{[ 12 ]}

Según el estándar C, la macro __STDC_HOSTED__debe definirse como 1si la implementación está alojada. Una implementación alojada tiene todos los encabezados especificados por el estándar C. Una implementación también puede ser independiente, lo que significa que solo se garantiza la presencia de los encabezados necesarios para formar parte de una implementación independiente del estándar. Si una implementación es independiente , debe definirse __STDC_HOSTED__como 0.

Algunas funciones de la biblioteca estándar de C han sido tristemente célebres por tener vulnerabilidades de desbordamiento de búfer y, en general, por fomentar la programación con errores desde su adopción. ^{[ 13 ] [ a ]} ​​Los elementos más criticados son:

• rutinas de manipulación de cadenas , incluidas strcpy()y strcat(), por falta de comprobación de límites y posibles desbordamientos de búfer si los límites no se comprueban manualmente;
• rutinas de cadena en general, por efectos secundarios , fomentando el uso irresponsable del búfer, no garantizando siempre una salida válida terminada en nulo , cálculo de longitud lineal; ^{[ b ]}
• printf()familia de rutinas, para dañar la pila de ejecución cuando la cadena de formato no coincide con los argumentos dados. Este fallo fundamental creó toda una clase de ataques: ataques de cadena de formato ;
• gets()y scanf()familia de rutinas de E/S, por falta de comprobación (ya sea inexistente o sencilla) de la longitud de entrada.

Salvo en el caso extremo de gets(), todas las vulnerabilidades de seguridad pueden evitarse introduciendo código auxiliar para gestionar la memoria, comprobar los límites, verificar la entrada, etc. Esto se suele hacer mediante envoltorios que hacen que las funciones de la biblioteca estándar sean más seguras y fáciles de usar. Esta práctica se remonta al libro "The Practice of Programming" de B. Kernighan y R. Pike, donde los autores suelen usar envoltorios que imprimen mensajes de error y finalizan el programa si se produce un error.

El comité ISO C publicó los informes técnicos TR 24731-1 ^{[ 14 ]} y está trabajando en el TR 24731-2 ^{[ 15 ]} para proponer la adopción de algunas funciones con comprobación de límites y asignación automática de búfer, respectivamente. El primero ha recibido fuertes críticas, aunque también algunos elogios, ^{[ 16 ] [ 17 ]} y el segundo ha tenido una respuesta mixta.

A pesar de las preocupaciones, TR 24731-1 se integró en la línea de estándares C en ISO/IEC 9899:2011 (C11), Anexo K ( Interfaces de comprobación de límites ), y se implementó aproximadamente en la biblioteca de tiempo de ejecución C/++ (CRT) de Microsoft para las plataformas Win32 y Win64.

(Por defecto, los compiladores de C y C++ de Microsoft Visual Studio emiten advertencias al usar funciones antiguas e "inseguras". Sin embargo, la implementación de Microsoft de TR 24731-1 es sutilmente incompatible tanto con TR 24731-1 como con el Anexo K, ^{[ 18 ]} por lo que es común que los proyectos portátiles deshabiliten o ignoren estas advertencias. Se pueden deshabilitar directamente emitiendo

#pragma warning(disable : 4996)

antes/alrededor del/de los sitio(s) de llamada en cuestión, o indirectamente mediante la emisión de

#define _CRT_SECURE_NO_WARNINGS 1

antes de incluir cualquier encabezado. ^{[ 19 ]} La opción de línea de comandos /D_CRT_NO_SECURE_WARNINGS=1debería tener el mismo efecto que esta #define.)

La strerror()rutina es criticada por no ser segura para los hilos de ejecución y por ser vulnerable a condiciones de carrera .

El manejo de errores de las funciones en la biblioteca estándar de C no es consistente y a veces resulta confuso. Según la página del manual de Linux math_error, "La situación actual (versión 2.8) con glibc es caótica. La mayoría (pero no todas) las funciones generan excepciones en caso de error. Algunas también establecen errno . Unas pocas funciones establecen errno , pero no generan una excepción. Muy pocas funciones no hacen ninguna de las dos cosas." ^{[ 20 ]}

POSIX y la Especificación Única de Unix especifican una serie de rutinas adicionales a las de la biblioteca estándar básica de C. La especificación POSIX incluye archivos de cabecera para, entre otras funcionalidades, hilos POSIX para programación multihilo , sockets Berkeley para redes y expresiones regulares . Estas se implementan a menudo junto con la funcionalidad de la biblioteca estándar de C, con distintos grados de similitud. Por ejemplo, glibc implementa funciones como forkdentro de libc.so, pero antes de que la Biblioteca de Hilos POSIX Nativos se fusionara con glibc, constituía una biblioteca separada con su propio argumento de bandera del enlazador. A menudo, esta funcionalidad especificada por POSIX se considerará parte de la biblioteca; la biblioteca básica de C puede identificarse como la biblioteca C ANSI o ISO .

BSD libc es un superconjunto de la biblioteca estándar POSIX compatible con las bibliotecas C incluidas en los sistemas operativos BSD , como FreeBSD , NetBSD , OpenBSD y macOS . BSD libc tiene algunas extensiones que no están definidas en el estándar original, muchas de las cuales aparecieron por primera vez en la versión 4.4BSD de 1994 (la primera en desarrollarse en gran medida después de que se publicara el primer estándar en 1989). Algunas de las extensiones de BSD libc son:

• <sys/tree.h> – contiene una implementación de árbol rojo-negro y árbol splay ^{[ 21 ] [ 22 ]}
• <sys/queue.h> – implementaciones de lista enlazada , colas , cola de cola , etc. ^{[ 23 ] [ 24 ]}
• fgetln() – definido en <stdio.h>. Esto se puede usar para leer un archivo línea por línea. ^{[ 25 ] [ 26 ] [ 27 ]}
• <fts.h> – contiene algunas funciones para recorrer una jerarquía de archivos ^{[ 28 ] [ 29 ]}
• <db.h> – algunas funciones para conectarse a Berkeley DB ^{[ 30 ] [ 31 ]}
• strlcat()y – alternativas seguras para y ^{[ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ]}strlcpy() strncat()strncpy()
• <err.h> – contiene algunas funciones para imprimir mensajes de error formateados ^{[ 37 ] [ 38 ]}
• <vis.h> – contiene la vis()función. Esta función se utiliza para mostrar caracteres no imprimibles en un formato visual. ^{[ 39 ] [ 40 ] [ 41 ]}

El lenguaje C++ incorpora la mayoría de las construcciones de la biblioteca estándar de C en las suyas, excluyendo la maquinaria específica de C. Las funciones de la biblioteca estándar de C se exportan desde la biblioteca estándar de C++ de dos maneras.

Para la retrocompatibilidad/compatibilidad cruzada con C y C++ preestándar, se puede acceder a las funciones en el espacio de nombres global ( ::), después de #includeescribir el nombre del encabezado estándar de C como en C. ^{[ 42 ]}Sin embargo, el ::uso para indicar el espacio de nombres global es necesario solo cuando está dentro del ámbito de otros espacios de nombres donde se define el mismo nombre de símbolo. Por lo tanto, el programa C++98

#include <stdio.h>int main ( void ) { return puts ( "Hola, mundo!" ) == EOF ; }

debería presentar un comportamiento (aparentemente) idéntico al de un programa C95 con código idéntico .

Desde C++98 en adelante, las funciones de C también están disponibles en el espacio de nombres std(por ejemplo, C  printfcomo C++  std::printf, atoicomo std::atoi, feofcomo std::feof), al incluir el encabezado en lugar del encabezado C correspondiente . Por ejemplo, sustituye a y a ; tenga en cuenta la falta de extensión en los nombres de los encabezados de C++.<chdrname><hdrname.h><cstdio><stdio.h><cmath><math.h>.h

Por lo tanto, un programa equivalente (generalmente preferible) en C++≥98 a los dos anteriores es:

#include <cstdio>int main () { return std :: puts ( "Hola, mundo" ) == EOF ; }

Si se utiliza C++20 o posterior, se puede sustituir por (pero no por , ya que los módulos no exportan macros, como ).#include<cstdio>import<cstdio>;importstd;EOF

Se puede emitir una declaración arriba o dentro para calificar automáticamente el espacio de nombres (esencialmente aplicando el prefijo automáticamente), aunque escribir una instrucción puede contaminar el espacio de nombres global con símbolos potencialmente no deseados si se usa en el ámbito global de un encabezado . ^{[ 43 ]}usingnamespacestd;mainstdstd::using

Faltan algunos de los encabezados de las versiones C++≥98 de C; por ejemplo, C≥11 <stdnoreturn.h>y <threads.h>no tienen contrapartes en C++. ^{[ 44 ]}

Otros se reducen a marcadores de posición, como (hasta C++20 ) <ciso646>para C95 <iso646.h>, cuyas macros necesarias se representan como palabras clave en C++98. Las construcciones sintácticas específicas de C generalmente no son compatibles, incluso si su encabezado lo es. ^{[ 45 ]}

Existen varios encabezados de C principalmente para la compatibilidad con C++, y estos tienden a estar casi vacíos en C++. Por ejemplo, C99 – 17<stdbool.h> solo requieren

#define bool _Bool #define false 0 #define true 1 #define __bool_true_false_are_defined 1

para simular compatibilidad con las palabras clave C++98 bool, falsey trueen C. C++11 requiere <stdbool.h>y <cstdbool>para compatibilidad, pero solo necesitan definir __bool_true_false_are_defined. C23 desaprueba _Boolla palabra clave anterior en favor de las nuevas palabras clave equivalentes a C++98 bool, falsey , por lo que los encabezados / de trueC≥23 y C++≥11 son totalmente equivalentes. (En particular, C23 no requiere ninguna macro para .)<stdbool.h>cstdbool>__STDC_VERSION_BOOL_H__<stdbool.h>

Se prefiere, siempre que sea posible, el acceso a las funciones de la biblioteca C a través del espacio de nombres ::std y los nombres de los encabezados C++≥98. Para fomentar su adopción, C++98 declara obsoletos los nombres de los encabezados C, por lo que es posible que el uso de encabezados de compatibilidad con C provoque que un preprocesador C++98–20 especialmente estricto genere algún tipo de diagnóstico. Sin embargo, C++23 (de forma inusual) vuelve a dejar obsoletos estos encabezados, por lo que las implementaciones/modos de C++ más recientes no deberían quejarse sin que se les solicite específicamente. ^{[ 46 ]}<*.h>

El módulostd.compat de la biblioteca estándar C++≥23 coloca todos los símbolos de la biblioteca estándar de C en el espacio de nombres global (similar a incluir todos <*.h>los encabezados), mientras que el stdmódulo deja los símbolos de la biblioteca estándar de C en el stdespacio de nombres (similar a incluir las versiones C++ de los encabezados de C). Otros lenguajes adoptan un enfoque similar, colocando las funciones/rutinas de compatibilidad con C bajo un espacio de nombres común; entre ellos se incluyen D , Perl y Ruby .

CPython incluye envoltorios para algunas de las funciones de la biblioteca C en su propia biblioteca común, y también proporciona un acceso más directo a las funciones y variables de C a través de su paquete ctypes . ^{[ 47 ]}

De manera más general, Python  2.x especifica que los objetos de archivo integrados están “implementados usando el paquete stdio de C ”, ^{[ 48 ]} y se hace referencia frecuente a los comportamientos de la biblioteca estándar de C; las operaciones disponibles (open , read,writeSe espera que las funciones C correspondientes ( , , , etc.) tengan el mismo comportamiento que las funciones C correspondientes ( fopen, fread, fwrite, etc.).

Sin embargo, la especificación de Python 3 depende considerablemente menos de las particularidades de C que la de Python 2 .

Rust ofrece una crate libcque permite utilizar diversas funciones y definiciones de tipos de la biblioteca estándar de C (y otras). ^{[ 49 ]}

Zig incluye libc para los objetivos disponibles. ^{[ 50 ]}