bibliothèque standard C

interface de programmation d'application (API)

: Déprécié : Supprimé
Trois des fichiers d'en-tête ( `<complex.h>`, `<stdatomic.h>`, et `<threads.h>`) sont des fonctionnalités conditionnelles que les implémentations ne sont pas tenues de prendre en charge.
La norme POSIX a ajouté plusieurs en-têtes C non standard pour des fonctionnalités spécifiques à Unix. Nombre d'entre eux ont été adoptés par d'autres architectures. On peut citer par exemple ` clib` et `clib` . Plusieurs autres groupes utilisent également des en-têtes non standard : la bibliothèque GNU C propose `clib` , et OpenVMS intègre la fonction `clib`.`<fcntl.h><unistd.h><alloca.h>va_count()`

Documentation

Sur les systèmes de type Unix, la documentation officielle de l'API est fournie sous forme de pages de manuel (man pages ). Sur la plupart des systèmes, les pages de manuel relatives aux fonctions de la bibliothèque standard se trouvent dans la section 3 ; la section 7 peut contenir des pages plus générales sur les concepts sous-jacents (par exemple, man 7 math_errorsous Linux ).

Mises en œuvre

Les systèmes de type Unix possèdent généralement une bibliothèque C sous forme de bibliothèque partagée , mais les fichiers d'en-tête (et la chaîne d'outils du compilateur) peuvent être absents de l'installation, rendant ainsi le développement en C impossible. La bibliothèque C est considérée comme faisant partie intégrante du système d'exploitation sur ces systèmes ; outre les fonctions spécifiées par la norme C, elle inclut d'autres fonctions de l'API du système d'exploitation, telles que celles spécifiées par la norme POSIX . Les fonctions de la bibliothèque C, y compris celles de la norme ISO C, sont largement utilisées par les programmes et sont considérées non seulement comme une implémentation du langage C, mais aussi comme une composante essentielle de l'interface du système d'exploitation. Les systèmes d'exploitation de type Unix sont généralement inopérants si la bibliothèque C est supprimée. Ceci est particulièrement vrai pour les applications liées dynamiquement, par opposition aux applications liées statiquement. De plus, le noyau lui-même (du moins sous Linux) fonctionne indépendamment de toute bibliothèque.

Sous Microsoft Windows, la bibliothèque d'exécution C de Microsoft fournit une implémentation de la bibliothèque standard C pour le compilateur Microsoft Visual C++ v6.0. La bibliothèque standard C pour les versions plus récentes du compilateur Microsoft Visual C++ est fournie individuellement par chaque compilateur, ainsi que par des packages redistribuables . Les applications compilées écrites en C sont soit liées statiquement à une bibliothèque C, soit liées à une version dynamique de cette bibliothèque fournie avec ces applications, sans qu'il soit nécessaire de présumer de sa présence sur les systèmes cibles. Les fonctions de la bibliothèque C d'un compilateur ne sont pas considérées comme des interfaces avec Microsoft Windows ; les interfaces système Windows sont fournies dans des bibliothèques distinctes de la bibliothèque d'exécution C.

Il existe de nombreuses implémentations de la bibliothèque standard C, fournies avec divers systèmes d'exploitation et compilateurs C. Voici quelques-unes des implémentations les plus courantes :

La bibliothèque BSD libc , diverses implémentations distribuées avec des systèmes d'exploitation dérivés de BSD
Bibliothèque GNU C (glibc), utilisée dans GNU Hurd , GNU/kFreeBSD et la plupart des distributions Linux.
La bibliothèque d'exécution C de Microsoft, qui fait partie de Microsoft Visual C++ , existe en deux versions : MSVCRT, anciennement redistribuable (jusqu'à Visual Studio 2013) et non conforme à la norme C99 , et UCRT (Universal C Run Time), plus récente et fournie avec Windows 10 et 11, conforme à la norme C99..
dietlibc , une implémentation alternative et allégée de la bibliothèque standard C (sans MMU)
μClibc , une bibliothèque standard C pour les systèmes μClinux embarqués (sans MMU)
- uclibc-ng , une bibliothèque C embarquée, dérivée de μClibc, toujours maintenue, avec prise en charge de l'unité de gestion de la mémoire (MMU).
Newlib , une bibliothèque standard C pour systèmes embarqués (sans MMU) , est utilisée dans la distribution GNU Cygwin pour Windows.
klibc , principalement pour le démarrage des systèmes Linux
musl , une autre implémentation légère de la bibliothèque standard C pour les systèmes Linux
Bionic , initialement développé par Google pour le système d'exploitation embarqué Android, est dérivé de la bibliothèque BSD libc.
picolibc , développé par Keith Packard , est destiné aux petits systèmes embarqués disposant d'une mémoire vive limitée et est basé sur le code de Newlib et d'AVR Libc.
llvm-libc est une implémentation à partir de zéro de la bibliothèque standard C, construite dans le cadre du projet LLVM.

fonctions intégrées du compilateur

Certains compilateurs (par exemple, GCC ) fournissent des versions intégrées de nombreuses fonctions de la bibliothèque standard C ; autrement dit, l’implémentation des fonctions est écrite dans le fichier objet compilé , et le programme appelle ces versions intégrées au lieu des fonctions présentes dans le fichier objet partagé de la bibliothèque C. Ceci réduit la surcharge liée aux appels de fonctions, notamment si ces appels sont remplacés par des variantes en ligne , et permet d’autres formes d’ optimisation (le compilateur connaissant les caractéristiques de flux de contrôle des variantes intégrées), mais peut engendrer des difficultés lors du débogage (par exemple, les versions intégrées ne peuvent pas être remplacées par des variantes instrumentées ).

Cependant, les fonctions intégrées doivent se comporter comme des fonctions ordinaires, conformément à la norme ISO C. Cela implique principalement que le programme doit pouvoir créer un pointeur vers ces fonctions en obtenant leur adresse, et appeler la fonction au moyen de ce pointeur. Si deux pointeurs vers la même fonction sont obtenus dans deux unités de traduction différentes du programme, ces deux pointeurs doivent être égaux ; autrement dit, l’adresse est obtenue en résolvant le nom de la fonction, qui possède une liaison externe (à l’échelle du programme).

Liaison, libm

Sous FreeBSD et glibc certaines fonctions, telles que ` sin()f`, ne sont pas liées par défaut et sont regroupées dans la bibliothèque mathématique `libm` . Si l'une d'entre elles est utilisée, l'éditeur de liens doit recevoir la directive `f` -lm. POSIX exige que le compilateur c99 prenne en charge ` -lmf`, et que les fonctions déclarées dans les en-têtes `f` <math.h>, <complex.h>`f` et ` <fenv.h>g` soient disponibles pour la liaison si ` -lmf` est spécifié, mais ne précise pas si les fonctions sont liées par défaut. musl satisfait cette exigence en plaçant toutes les fonctions dans une seule bibliothèque `libc` et en fournissant une bibliothèque `libm` vide.

Détection

Selon la norme C, la macro __STDC_HOSTED__doit être définie 1si l'implémentation est hébergée. Une implémentation hébergée possède tous les en-têtes spécifiés par la norme C. Une implémentation peut également être autonome, ce qui signifie que seuls les en-têtes requis pour une implémentation autonome de la norme sont garantis présents. Si une implémentation est autonome , elle doit définir __STDC_HOSTED__la macro 0.

Problèmes et solutions de contournement

#pragma warning(disable : 4996)

avant/autour du ou des d'appel en question, ou indirectement en émettant

#define _CRT_SECURE_NO_WARNINGS 1

avant d'inclure les en-têtes. L'option de ligne de commande /D_CRT_NO_SECURE_WARNINGS=1devrait avoir le même effet que ceci #define.)

Problèmes de multithreading, vulnérabilité aux conditions de concurrence

Cette strerror()routine est critiquée car elle n'est pas sécurisée en matière de concurrence et est par ailleurs vulnérable aux conditions de concurrence .

Gestion des erreurs

La gestion des erreurs des fonctions de la bibliothèque standard C est incohérente et parfois source de confusion. Selon la page de manuel Linuxmath_error : « La situation actuelle (version 2.8) sous glibc est complexe. La plupart des fonctions (mais pas toutes) lèvent des exceptions en cas d’erreur. Certaines définissent également errno . Quelques fonctions définissent errno sans lever d’exception. Un très petit nombre de fonctions ne font ni l’un ni l’autre. »

Standardisation

POSIX et la spécification Single Unix définissent un certain nombre de routines supplémentaires par rapport à celles de la bibliothèque standard C de base. La spécification POSIX inclut des fichiers d'en-tête pour, entre autres, les threads POSIX pour la programmation multithread , les sockets Berkeley pour la mise en réseau et les expressions régulières . Ces fonctionnalités sont souvent implémentées en parallèle de celles de la bibliothèque standard C, avec un degré d'intégration variable. Par exemple, glibc implémente des fonctions telles que ` fork__init__` au sein de `__init__` libc.so, mais avant l'intégration de la bibliothèque native de threads POSIX à glibc, celle-ci constituait une bibliothèque distincte avec son propre argument d'édition de liens. Ces fonctionnalités spécifiées par POSIX sont généralement considérées comme faisant partie de la bibliothèque ; la bibliothèque C de base peut alors être désignée comme la bibliothèque C ANSI ou ISO .

BSD libc

La bibliothèque BSD libc est un sur-ensemble de la bibliothèque standard POSIX prise en charge par les bibliothèques C incluses dans les systèmes d'exploitation BSD tels que FreeBSD , NetBSD , OpenBSD et macOS . La bibliothèque BSD libc possède des extensions non définies dans la norme d'origine, dont beaucoup sont apparues pour la première fois dans la version 4.4BSD de 1994 (la première à avoir été largement développée après la publication de la norme initiale en 1989). Voici quelques-unes de ces extensions :

<sys/tree.h> contient une implémentation de l'arbre rouge-noir et de l'arbre splay
<sys/queue.h> implémentations de listes chaînées , de files d'attente , base de données Berkeley
strlcat()et – alternatives sécurisées pour et strlcpy()strncat()strncpy()
<err.h> contient certaines fonctions pour imprimer des messages d'erreur formatés
<vis.h> contient la vis()fonction. Cette fonction est utilisée pour afficher les caractères non imprimables sous une forme visuelle.

La bibliothèque standard C dans d'autres langues

Certains langages intègrent les fonctionnalités de la bibliothèque standard C dans leurs propres bibliothèques. Ces dernières peuvent être adaptées à la structure du langage, mais leur sémantique opérationnelle reste similaire.

C++

Le langage C++ intègre la majorité des constructions de la bibliothèque standard C, à l'exception des mécanismes spécifiques au C. Les fonctions de la bibliothèque standard C sont exportées de la bibliothèque standard C++ de deux manières.

Pour assurer la rétrocompatibilité/compatibilité avec C et C++ pré-standard, les fonctions peuvent être accessibles dans l' espace de noms global ( ::), après #includeavoir ajouté le nom d'en-tête standard C comme en C. #include <stdio.h>int main ( void ) { return puts ( "Bonjour, monde !" ) == EOF ; }

devrait présenter un comportement (apparemment) identique à celui d'un programme C95 de code identique .

À partir de C++98 , les fonctions C sont également disponibles dans l'espace de noms std(par exemple, C printfcomme C++ , comme `f` std::printf, atoicomme std::atoi` feofc` std::feof), en incluant l'en-tête ` c` au lieu de l'en-tête C correspondant . Par exemple, ` f` remplace `f` et `f` ; notez l'absence d' extension sur les noms d'en-têtes C++.<c<<cstdio><stdio.h><cmath><math.h>.h

Ainsi, un programme C++≥98 équivalent (et généralement préférable) aux deux précédents est :

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

Si vous utilisez C++20 ou une version ultérieure, peut être remplacé par (mais pas par , car les modules n'exportent pas de macros, telles que ).#include<cstdio>import<cstdio>;importstd;EOF

Une déclaration ci-dessus ou à l'intérieur peut être émise pour qualifier automatiquement l' espace de noms (appliquant essentiellement le préfixe automatiquement), bien que l'écriture d'une instruction puisse polluer l'espace de noms global avec des symboles potentiellement indésirables si elle est utilisée dans la portée globale d'un en-tête . usingnamespacestd;mainstdstd::using

Il manque quelques en-têtes C++≥98 pour les versions de C ; par exemple, les versions C≥11 <stdnoreturn.h>n'ont <threads.h>pas d'équivalents C++.

D'autres sont réduits à des espaces réservés, comme (jusqu'à C++20 ) <ciso646>pour C95 <iso646.h>, dont toutes les macros requises sont rendues comme des mots clés en C++98. Les constructions syntaxiques spécifiques au C ne sont généralement pas prises en charge, même si leur en-tête l'est.

Plusieurs en-têtes C existent principalement pour assurer la compatibilité avec C++, et ceux-ci sont généralement presque vides en C++. Par exemple, C99-17 ne nécessitent que<stdbool.h>

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

Pour simuler la prise en charge des mots-clés C++98 bool, false`__init__` et true`__init__` en C, C++11 exige <stdbool.h>`__init__` et <cstdbool>`__init__` pour la compatibilité, mais ils n'ont besoin de définir que `__init__` __bool_true_false_are_defined. C23 déprécie l'ancien mot-clé `__init__` au profit des nouveaux mots-clés `__init__` , `__init__` et `__init__`, _Booléquivalents à ceux de C++98. Ainsi, les en - têtes C≥23 et C++≥11 sont entièrement équivalents. (En particulier, C23 n'exige aucune macro pour `__init__`.)boolfalsetrue<stdbool.h>cstdbool>__STDC_VERSION_BOOL_H__<stdbool.h>

L'accès aux fonctions de la bibliothèque C via l'espace de noms ` ::std` et les noms d'en-tête C++≥98 est préférable lorsque cela est possible. Afin d'encourager leur adoption, C++98 rend obsolètes les noms d'en-tête C, de sorte que l'utilisation d'en-têtes de compatibilité C peut entraîner l'affichage d'un diagnostic par un préprocesseur C++98–20 particulièrement strict . Cependant, C++23 (exceptionnellement) rétablit la compatibilité avec ces en-têtes, de sorte que les implémentations/modes C++ plus récents ne devraient pas générer d'erreur sans y être explicitement invités. <*.h>

Le module de bibliothèque standard C++≥23 std.compatplace tous les symboles de la bibliothèque standard C dans l'espace de noms global (comme s'il incluait tous <*.h>les en-têtes), tandis que le stdmodule laisse les symboles de la bibliothèque standard C dans l' stdespace de noms (comme s'il incluait les versions C++ des en-têtes C).

Python

CPython inclut des wrappers pour certaines fonctions de la bibliothèque C dans sa propre bibliothèque commune, et il offre également un accès plus direct aux fonctions et variables C via son package ctypes .

Plus généralement, Python 2.xstdio de C » , et il est fréquemment fait référence aux comportements de la bibliothèque standard C ; les opérations disponibles open , read,write, fread, fwrite, etc.).

La spécification de Python 3 repose toutefois beaucoup moins sur les spécificités du C que celle de Python 2 .

Rouiller

Rust propose crate libc, qui permet d'utiliser diverses fonctions et définitions de types de bibliothèques standard C (et autres).

Zig

Zig est fourni avec libc pour les cibles disponibles.

Comparaison avec les bibliothèques standard d'autres langages

La bibliothèque standard du C est réduite comparée à celles d'autres langages. Elle offre un ensemble de fonctions mathématiques de base, la manipulation de chaînes de caractères, les conversions de types et les entrées/sorties via fichiers et console. Elle ne comprend pas d'ensemble standard de types conteneurs / bibliothèque de modèles standard (STL ) du C++ , ni les outils complets d'interface graphique (GUI), les outils réseau et la multitude d'autres fonctionnalités offertes par Java et le framework .NET . Le principal avantage de cette bibliothèque standard réduite réside dans la simplicité de mise en place d'un environnement C ISO fonctionnel, facilitant ainsi le portage du C vers une nouvelle plateforme.