Bibliothèque standard C

La bibliothèque standard C ou libc est la bibliothèque standard du langage de programmation C , telle que spécifiée dans la norme ISO C. À partir de la norme ANSI C d'origine , elle a été développée en même temps que la spécification POSIX de la bibliothèque C , qui en est un sur-ensemble. Étant donné que l'ANSI C a été adopté par l' Organisation internationale de normalisation , la bibliothèque standard C est également appelée bibliothèque ISO C.

La bibliothèque standard C fournit des macros , des définitions de type et des fonctions pour des tâches telles que la gestion des chaînes , les calculs mathématiques, le traitement des entrées/sorties, la gestion de la mémoire et plusieurs autres services du système d'exploitation .

L' interface de programmation d'application (API) de la bibliothèque standard C est déclarée dans un certain nombre de fichiers d'en-tête . Chaque fichier d'en-tête contient une ou plusieurs déclarations de fonction, définitions de type de données et macros.

Après une longue période de stabilité, trois nouveaux fichiers d'en-tête ( iso646.h, wchar.h, et wctype.h) ont été ajoutés avec l'Addendum Normatif 1 (NA1), un ajout à la norme C ratifié en 1995. Six autres fichiers d'en-tête ( complex.h, fenv.h, inttypes.h, stdbool.h, stdint.het tgmath.h) ont été ajoutés avec C99 , une révision de la norme C publiée en 1999, et cinq autres fichiers ( stdalign.h, stdatomic.h, stdnoreturn.h, threads.h, et uchar.h) avec C11 en 2011. Au total, il y a maintenant 29 fichiers d'en-tête :

Trois des fichiers d’en-tête ( complex.h, stdatomic.het 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. Beaucoup d'entre eux ont trouvé leur chemin vers d'autres architectures. Parmi les exemples, on peut citer fcntl.het unistd.h. Un certain nombre d'autres groupes utilisent d'autres en-têtes non standard : la bibliothèque C GNU possède alloca.h, et OpenVMS possède la va_count()fonction .

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

Les systèmes de type Unix disposent généralement d'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 d'une installation, ce qui rend le développement en C impossible. La bibliothèque C est considérée comme faisant partie du système d'exploitation sur les systèmes de type Unix ; en plus des fonctions spécifiées par la norme C, elle comprend d'autres fonctions qui font partie de l'API du système d'exploitation, telles que les fonctions spécifiées dans 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 comme si elles n'étaient pas seulement une implémentation de quelque chose dans le langage C, mais aussi une partie de facto de l'interface du système d'exploitation. Les systèmes d'exploitation de type Unix ne peuvent généralement pas fonctionner si la bibliothèque C est effacée. Cela est vrai pour les applications qui sont liées de manière dynamique plutôt que statique. De plus, le noyau lui-même (du moins dans le cas de Linux) fonctionne indépendamment de toute bibliothèque.

Sous Microsoft Windows, les bibliothèques dynamiques du système principal ( DLL ) fournissent 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 par chaque compilateur individuellement, 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 la bibliothèque fournie avec ces applications, plutôt que d'être censées être présentes sur les systèmes ciblés. Les fonctions de la bibliothèque C d'un compilateur ne sont pas considérées comme des interfaces avec Microsoft Windows.

Il existe de nombreuses implémentations de bibliothèques C, fournies avec différents systèmes d'exploitation et compilateurs C. Certaines des implémentations les plus populaires sont les suivantes :

• La bibliothèque BSD libc , diverses implémentations distribuées avec les systèmes d'exploitation dérivés de BSD
• Bibliothèque GNU C (glibc), utilisée dans GNU Hurd , GNU/kFreeBSD et Linux
• Bibliothèque d'exécution Microsoft C , qui fait partie de Microsoft Visual C++ . Il existe deux versions de la bibliothèque : MSVCRT qui était redistribuable jusqu'à la version 12/Visual Studio 2013 avec une faible conformité C99, et une nouvelle UCRT (Universal C Run Time) qui fait partie de Windows 10 et 11, donc toujours présente pour établir un lien, et qui est également conforme C99 [1].
• dietlibc , une petite implémentation alternative 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 intégrée, fork 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 les systèmes embarqués (sans MMU) et utilisée dans la distribution Cygwin GNU pour Windows
• klibc , principalement pour démarrer les systèmes Linux
• musl , une autre implémentation légère de la bibliothèque standard C pour les systèmes Linux
• Bionic , développé à l'origine par Google pour le système d'exploitation embarqué Android, dérivé de BSD libc
• picolibc, développé par Keith Packard , ciblant les petits systèmes embarqués avec une RAM limitée, basé sur le code de Newlib et AVR Libc

Certains compilateurs (par exemple, GCC ) fournissent des versions intégrées de nombreuses fonctions de la bibliothèque standard C ; c'est-à-dire que les implémentations des fonctions sont écrites dans le fichier objet compilé et le programme appelle les versions intégrées au lieu des fonctions du fichier objet partagé de la bibliothèque C. Cela réduit la charge des appels de fonction, en particulier si les appels de fonction sont remplacés par des variantes en ligne , et permet d'autres formes d' optimisation (car le compilateur connaît les caractéristiques de flux de contrôle des variantes intégrées), mais peut entraîner une confusion 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. La principale implication est que le programme doit être capable de créer un pointeur vers ces fonctions en prenant leur adresse et d'invoquer la fonction au moyen de ce pointeur. Si deux pointeurs vers la même fonction sont dérivés de deux unités de traduction différentes dans le programme, ces deux pointeurs doivent être équivalents ; c'est-à-dire que l'adresse provient de la résolution du nom de la fonction, qui a un lien externe (à l'échelle du programme).

Sous FreeBSD et glibc, certaines fonctions telles que sin() ne sont pas liées par défaut et sont plutôt regroupées dans la bibliothèque mathématique libm . Si l'une d'entre elles est utilisée, le linker doit recevoir la directive -lm. POSIX exige que le compilateur c99 prenne en charge -lm, et que les fonctions déclarées dans les en-têtes math.h, complex.h, et fenv.hsoient disponibles pour la liaison si -lmest spécifié, mais ne précise pas si les fonctions sont liées par défaut. musl satisfait cette exigence en mettant tout dans une seule bibliothèque libc et en fournissant une libm vide.

Selon la norme C, la macro __STDC_HOSTED__doit être définie à 1 si 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 ces en-têtes ne seront pas présents. Si une implémentation est autonome , elle doit être définie __STDC_HOSTED__à 0 .

Certaines fonctions de la bibliothèque standard C sont connues pour présenter des vulnérabilités de dépassement de mémoire tampon et pour encourager généralement une programmation boguée depuis leur adoption. Les éléments les plus critiqués sont :

• routines de manipulation de chaînes , y compris strcpy()et strcat(), en raison du manque de vérification des limites et des débordements de tampon possibles si les limites ne sont pas vérifiées manuellement ;
• routines de chaîne en général, pour les effets secondaires , encourageant l'utilisation irresponsable de tampons, ne garantissant pas toujours une sortie terminée par null valide , calcul de longueur linéaire ;
• printf()famille de routines, pour endommager la pile d'exécution lorsque la chaîne de format ne correspond pas aux arguments donnés. Cette faille fondamentale a donné naissance à une classe entière d'attaques : les attaques de chaîne de format ;
• gets()et scanf()une famille de routines d'E/S, faute de vérification (ni simple ni complète) de la longueur d'entrée.

À l'exception du cas extrême avec gets(), toutes les vulnérabilités de sécurité peuvent être évitées en introduisant du code auxiliaire pour effectuer la gestion de la mémoire, la vérification des limites, la vérification des entrées, etc. Cela se fait souvent sous la forme de wrappers qui rendent les fonctions de la bibliothèque standard plus sûres et plus faciles à utiliser. Cela remonte au livre The Practice of Programming de B. Kernighan et R. Pike, où les auteurs utilisent couramment des wrappers qui impriment des messages d'erreur et quittent le programme si une erreur se produit.

Le comité ISO C a publié les rapports techniques TR 24731-1 et travaille sur TR 24731-2 pour proposer l'adoption de certaines fonctions avec vérification des limites et allocation automatique de tampon, en conséquence. Le premier a rencontré de vives critiques avec quelques éloges, le second a reçu des réponses mitigées. Malgré cela, TR 24731-1 a été implémenté dans la bibliothèque standard C de Microsoft et son compilateur émet des avertissements lors de l'utilisation d'anciennes fonctions « non sécurisées ».

La strerror()routine est critiquée pour son caractère non sécurisé au niveau des threads et pour sa vulnérabilité aux conditions de concurrence .

La gestion des erreurs des fonctions dans la bibliothèque standard C n'est pas cohérente et parfois déroutante. Selon la page de manuel Linux math_error, « La situation actuelle (version 2.8) sous glibc est compliquée. La plupart des fonctions (mais pas toutes) génèrent des exceptions en cas d'erreur. Certaines définissent également errno . Quelques fonctions définissent errno , mais ne génèrent pas d'exception. Un très petit nombre de fonctions ne font ni l'une ni l'autre. »

Le langage C original ne proposait aucune fonction intégrée telle que les opérations d'E/S, contrairement aux langages traditionnels tels que COBOL et Fortran . Au fil du temps, les communautés d'utilisateurs de C ont partagé des idées et des implémentations de ce que l'on appelle aujourd'hui les bibliothèques standard C. Bon nombre de ces idées ont finalement été incorporées dans la définition du langage C standardisé.

Unix et C ont été créés dans les laboratoires Bell d'AT&T à la fin des années 1960 et au début des années 1970. Au cours des années 1970, le langage C est devenu de plus en plus populaire. De nombreuses universités et organisations ont commencé à créer leurs propres variantes du langage pour leurs propres projets. Au début des années 1980, des problèmes de compatibilité entre les différentes implémentations du C sont devenus apparents. En 1983, l' American National Standards Institute (ANSI) a formé un comité pour établir une spécification standard du C connue sous le nom de « ANSI C ». Ce travail a abouti à la création de la norme dite C89 en 1989. Une partie de la norme résultante était un ensemble de bibliothèques logicielles appelées bibliothèque standard ANSI C.

POSIX , ainsi que SUS , spécifient un certain nombre de routines qui devraient être disponibles en plus de celles de la bibliothèque standard C de base. La spécification POSIX inclut des fichiers d'en-tête pour, entre autres utilisations, le multithreading , la mise en réseau et les expressions régulières . Ceux-ci sont souvent implémentés parallèlement aux fonctionnalités de la bibliothèque standard C, avec des degrés de proximité variables. Par exemple, glibc implémente des fonctions telles que forkwithin libc.so, mais avant que NPTL ne soit fusionné avec glibc, il constituait une bibliothèque séparée avec son propre argument d'indicateur de lien. Souvent, cette fonctionnalité spécifiée par POSIX sera considérée comme faisant partie de la bibliothèque ; la bibliothèque C de base peut être identifiée comme la bibliothèque C ANSI ou ISO .

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 comporte des extensions qui ne sont pas 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 à être largement développée après la publication de la première norme en 1989). Certaines des extensions de la bibliothèque BSD libc sont :

• sys/tree.h – contient une implémentation de l'arbre rouge-noir et de l'arbre étalé
• sys/queue.h – implémentations de listes chaînées , de files d'attente , de files d'attente de queue, etc.
• fgetln() – défini dans stdio.h. Cela peut être utilisé pour lire un fichier ligne par ligne.
• fts.h – contient certaines fonctions permettant de parcourir une hiérarchie de fichiers
• db.h – quelques fonctions pour se connecter à la base de données Berkeley DB
• strlcat()et strlcpy() – alternatives sûres pour strncat()et strncpy()
• err.h – contient certaines fonctions pour imprimer des messages d’erreur formatés
• vis.h – contient la vis()fonction. Cette fonction permet d'afficher des caractères non imprimables dans un format visuel.

Certains langages incluent les fonctionnalités de la bibliothèque C standard dans leurs propres bibliothèques. La bibliothèque peut être adaptée pour mieux correspondre à la structure du langage, mais la sémantique opérationnelle reste similaire. Le langage C++ , par exemple, inclut les fonctionnalités de la bibliothèque C standard dans l' espace de noms std (par exemple, std::printf, std::atoi, std::feof), dans des fichiers d'en-tête portant des noms similaires à ceux du C ( cstdio, cmath, cstdlib, etc.). D'autres langages qui adoptent des approches similaires sont D , Perl , Ruby et la principale implémentation de Python connue sous le nom de CPython . Dans Python 2, par exemple, les objets de fichiers intégrés sont définis comme « implémentés à l'aide stdiodu package de C », de sorte que les opérations disponibles (ouverture, lecture, écriture, etc.) sont censées avoir le même comportement que les fonctions C correspondantes. Rust possède une caisse appelée libc qui permet d'utiliser plusieurs fonctions, structures et autres définitions de type C.

La bibliothèque standard C est petite par rapport aux bibliothèques standard de certains autres langages. Elle fournit un ensemble de base de fonctions mathématiques, de manipulation de chaînes, de conversions de types et d'E/S basées sur des fichiers et des consoles. Elle n'inclut pas d'ensemble standard de « types de conteneurs » comme la bibliothèque de modèles standard C++ , sans parler des boîtes à outils complètes d'interface utilisateur graphique (GUI), des outils réseau et de la profusion d'autres fonctionnalités que Java et le .NET Framework fournissent en standard. Le principal avantage de la petite bibliothèque standard est qu'elle permet de fournir un environnement ISO C fonctionnel beaucoup plus facilement qu'avec d'autres langages, et par conséquent de porter C sur une nouvelle plate-forme est relativement facile.