Langage de programmation - C - glibc

Les premiers pas

La bibliothèque glibc, aussi nommé The GNU C Library, comprend plusieurs fichiers d'entête, chacun fournissant des définitions et des déclarations pour un groupe de fonctions connexes; ces informations sont utilisées par le compilateur C lors du traitement de votre programme. Par exemple, le fichier d'entête stdio.h déclare les fonctions permettant d'effectuer des entrées et des sorties, et le fichier d'entête string.h déclare les utilitaires de traitement de chaînes de caractères.

Normes et portabilité

Cette section présente les différentes normes et autres sources sur lesquelles la bibliothèque C de GNU est basée. Ces sources incluent les normes ISO C et POSIX, ainsi que les implémentations System V et Berkeley Unix.

L'objectif principal de cette page est de vous expliquer comment utiliser efficacement les fonctionnalités de la bibliothèque glibc. Mais si vous souhaitez rendre vos programmes compatibles avec ces normes ou portables sur des systèmes d'exploitation autres que GNU, cela peut affecter la façon dont vous utilisez la bibliothèque. Cette section vous donne un aperçu de ces normes, afin que vous sachiez de quoi il s'agit lorsqu'elles sont mentionnées dans d'autres parties de cette page.

ISO C

La bibliothèque glibc est compatible avec la norme C adoptée par l'American National Standards Institute (ANSI) : American National Standard X3.159-1989-"ANSI C" et plus tard par l'Organisation internationale de normalisation (ISO) : ISO/IEC 9899:1990, "Langages de programmation-C". Nous faisons ici référence à la norme comme ISO C car il s'agit de la norme la plus générale en matière de ratification. Les fichiers d'entête et les fonctions de bibliothèque composant la bibliothèque glibc sont un sur-ensemble de ceux spécifiés par la norme ISO C.

Si vous êtes soucieux du strict respect de la norme ISO C, vous devez utiliser l'option «-ansi» lorsque vous compilez vos programmes avec le compilateur GNU C. Cela indique au compilateur de définir uniquement les fonctionnalités de la norme ISO à partir des fichiers d'entête de la bibliothèque, à moins que vous ne demandiez explicitement des fonctionnalités supplémentaires.

Il est important de pouvoir restreindre la bibliothèque pour n'inclure que les fonctionnalités ISO C, car ISO C impose des limites sur les noms pouvant être définis par l'implémentation de la bibliothèque, et les extensions GNU ne correspondent pas à ces limites.

Cette page ne tente pas de vous donner des détails complets sur les différences entre ISO C et les dialectes plus anciens. Il donne des conseils sur la façon d'écrire des programmes fonctionnant de manière portable sous plusieurs dialectes C, mais ne vise pas à l'exhaustivité.

POSIX (The Portable Operating System Interface)

La bibliothèque glibc est également compatible avec la famille de normes ISO POSIX, plus connue sous le nom de Portable Operating System Interface for Computer Environments (ISO/IEC 9945). Elles ont également été publiées sous le nom de norme ANSI/IEEE 1003. POSIX est principalement dérivé de diverses versions du système d'exploitation Unix.

Les fonctionnalités de la bibliothèque spécifiées par les normes POSIX sont un sur-ensemble de celles requises par ISO C; POSIX spécifie des fonctionnalités supplémentaires pour les fonctions ISO C, ainsi que de nouvelles fonctions supplémentaires. En général, les exigences et fonctionnalités supplémentaires définies par les normes POSIX visent à fournir un support de niveau inférieur pour un type particulier d'environnement de système d'exploitation, plutôt qu'un support de langage de programmation général pouvant s'exécuter dans de nombreux environnements de système d'exploitation divers.

La bibliothèque glibc implémente toutes les fonctions spécifiées dans ISO/IEC 9945-1:1996, l'interface de programmation d'application du système POSIX, communément appelée POSIX.1. Les extensions principales des fonctionnalités ISO C spécifiées par cette norme incluent les primitives d'interface du système de fichiers (voir Interface du système de fichiers), les fonctions de contrôle de terminal spécifiques au périphérique et les fonctions de contrôle de processus.

Certaines fonctionnalités de la norme ISO/IEC 9945-2:1993, la norme POSIX Shell and Utilities (POSIX.2) sont également implémentées dans la bibliothèque glibc. Il s'agit notamment d'utilitaires permettant de gérer les expressions régulières et d'autres fonctionnalités de recherche de motifs.

Concepts de sécurité POSIX

Cette page décrit diverses propriétés de sécurité des fonctions de la bibliothèque glibc, dans des lignes suivant leurs prototypes et ressemblent à ceci :

Préliminaire : | MT-Safe | AS-Safe | AC-Safe |

Les propriétés sont évaluées selon les critères définis dans la norme POSIX pour des contextes de sécurité tels que Thread-, Async-Signal- et Async-Cancel--Safe. Des définitions intuitives de ces propriétés, tentant de saisir le sens des définitions standard, suivent :

Les fonctions MT-Safe ou Thread-Safe peuvent être appelées en toute sécurité en présence d'autres processus léger. MT, dans MT-Safe, signifie Multi Thread.

Être MT-Safe n'implique pas qu'une fonction soit atomique, ni qu'elle utilise l'un des mécanismes de synchronisation de mémoire que POSIX expose aux utilisateurs. Il est même possible que l'appel de fonctions MT-Safe en séquence ne produise pas une combinaison MT-Safe. Par exemple, le fait qu'un processus léger appelle deux fonctions MT-Safe l'une après l'autre ne garantit pas un comportement équivalent à l'exécution atomique d'une combinaison des deux fonctions, car les appels simultanés dans d'autres processus léger peuvent interférer de manière destructive.

Les optimisations de programme entier pouvant insérer des fonctions dans des interfaces de bibliothèque peuvent exposer à une réorganisation non sécurisée, et donc effectuer l'insertion dans l'interface de la bibliothèque glibc n'est pas recommandé. L'état MT-Safety documenté n'est pas garanti dans le cadre d'une optimisation de programme complet. Cependant, les fonctions définies dans les en-têtes visibles par l'utilisateur sont conçues pour être sûres pour l'insertion en ligne.

Les fonctions AS-Safe ou Async-Signal-Safe peuvent être appelées en toute sécurité à partir de gestionnaires de signaux désynchronisées. AS, dans AS-Safe, signifie Asynchronous Signal.

De nombreuses fonctions AS-Safe peuvent définir errno ou modifier l'environnement à virgule flottante, car cela ne les rend pas inadaptées à une utilisation dans des gestionnaires de signaux. Cependant, les programmes peuvent mal se comporter si les gestionnaires de signaux asynchrones modifient cet état local du thread, et on ne peut pas compter sur le mécanisme de gestion des signaux pour le préserver. Par conséquent, les gestionnaires de signaux appelant des fonctions pouvant définir errno ou modifier l'environnement à virgule flottante doivent enregistrer leurs valeurs d'origine et les restaurer avant de revenir.

Les fonctions AC-Safe ou Async-Cancel-Safe peuvent être appelées en toute sécurité lorsque l'annulation asynchrone est activée. AC dans AC-Safe signifie Asynchronous Cancellation.

La norme POSIX ne définit que trois fonctions comme étant AC-Safe, à savoir pthread_cancel, pthread_setcancelstate et pthread_setcanceltype. À l'heure actuelle, la bibliothèque glibc ne fournit aucune garantie au-delà de ces trois fonctions, mais documente les fonctions actuellement AC-Safe.

Tout comme les gestionnaires de signaux, les routines de nettoyage d'annulation doivent configurer l'environnement à virgule flottante dont elles ont besoin. Les routines ne peuvent pas supposer un environnement à virgule flottante, en particulier lorsque l'annulation désynchronisée est activée. Si la configuration de l'environnement à virgule flottante ne peut pas être effectuée de manière atomique, il est également possible que l'environnement rencontré soit incohérent en interne.

Les fonctions MT-Unsafe, AS-Unsafe, AC-Unsafe ne peuvent pas être appelées en toute sécurité dans les contextes de sécurité décrits ci-dessus. Les appeler dans de tels contextes invoque un comportement indéfini.

Les fonctions n'étant pas explicitement documentées comme sûres dans un contexte de sécurité doivent être considérées comme non sûres.
Les propriétés de sécurité Preliminary sont documentées, ce qui indique que ces propriétés ne seront peut-être pas prises en compte dans les prochaines versions de la bibliothèque C de GNU.

Ces propriétés préliminaires sont le résultat d'une évaluation des propriétés de notre implémentation actuelle, plutôt que de ce qui est mandaté et autorisé par les normes actuelles et futures.

Bien que nous nous efforcions de respecter les normes, dans certains cas, notre implémentation est sûre même lorsque la norme n'exige pas de sécurité, et dans d'autres cas, notre implémentation ne répond pas aux exigences de sécurité standard. Ces dernières sont très probablement des bogues; les premières, lorsqu'elles sont marquées comme préliminaires, ne doivent pas être prises en compte : les normes futures peuvent nécessiter des modifications qui ne sont pas compatibles avec les propriétés de sécurité supplémentaires offertes par l'implémentation actuelle.

De plus, la norme POSIX n'offre pas de définition détaillée de la sécurité. Nous supposons que, par «appel sûr», POSIX signifie que, tant que le programme n'appelle pas de comportement indéfini, la fonction «appel sûr» se comporte comme spécifié et ne fait pas dévier les autres fonctions de leur comportement spécifié. Nous avons choisi d'utiliser ses définitions de sécurité approximatives, non pas parce qu'elles sont les meilleures définitions à utiliser, mais parce que leur choix harmonise cette page avec POSIX.

Gardez à l'esprit qu'il s'agit de définitions et d'annotations préliminaires, et que certains aspects des définitions sont encore en cours de discussion et peuvent être sujets à clarification ou à modification.

Au fil du temps, nous envisageons de faire évoluer les notes de sécurité préliminaires vers des engagements stables, aussi stables que ceux de nos interfaces. Au fur et à mesure, nous supprimerons le mot-clef Preliminary des notes de sécurité. Cependant, tant que le mot-clef reste présent, il ne doit pas être considéré comme une promesse de comportement futur.

Les autres mots-clefs apparaissant dans les notes de sécurité sont définis dans les sections suivantes.

Fonctionnalités non sûres (Unsafe)

Les fonctions n'étant pas sûres à appeler dans certains contextes sont annotées avec des mots-clefs documentant leurs fonctionnalités les rendant dangereuses à appeler. Les fonctionnalités AS-Unsafe dans cette section indiquent que les fonctions ne peuvent jamais être appelées en toute sécurité lorsque les signaux désynchronisées sont activés. Les fonctionnalités AC-Unsafe indiquent qu'elles ne peuvent jamais être appelées en toute sécurité lorsque l'annulation désynchronisée est activée. Il n'y a pas de marque MT-Unsafe dans cette section.

Terme	Description
lock	Les fonctions marquées avec lock comme fonctionnalité AS-Unsafe peuvent être interrompues par un signal alors qu'elles détiennent un verrou non récursif. Si le gestionnaire de signal appelle une autre fonction de ce type qui prend le même verrou, le résultat est un blocage. Les fonctions annotées avec lock comme fonctionnalité AC-Unsafe peuvent, si elles sont annulées de manière désynchronisée, ne pas libérer un verrou ayant été libéré si leur exécution n'avait pas été interrompue par l'annulation désynchronisé du processus léger. Une fois qu'un verrou est laissé pris, les tentatives de prise de ce verrou bloqueront indéfiniment.
corrupt	Les fonctions marquées avec corrupt comme fonction AS-Unsafe peuvent corrompre les structures de données et mal se comporter lorsqu'elles interrompent ou sont interrompues par une autre fonction de ce type. Contrairement aux fonctions marquées avec lock, celles-ci prennent des verrous récursifs pour éviter les problèmes MT-Safety, mais cela ne suffit pas à empêcher un gestionnaire de signaux d'observer une structure de données partiellement mise à jour. Une corruption supplémentaire peut survenir du fait que la fonction interrompue ne remarque pas les mises à jour effectuées par les gestionnaires de signaux. Les fonctions marquées avec corrupt comme fonction AC-Unsafe peuvent laisser les structures de données dans un état corrompu et partiellement mis à jour. Les utilisations ultérieures de la structure de données peuvent mal se comporter.
heap	Les fonctions marquées avec heap peuvent appeler des fonctions de gestion de mémoire de tas de la famille de fonctions malloc/free et ne sont aussi sûres que ces fonctions. Cette note est donc équivalente à : \| AS-Unsafe lock \| AC-Unsafe lock fd mem \|
dlopen	Les fonctions marquées dlopen utilisent le chargeur dynamique pour charger des bibliothèques partagées dans l'image d'exécution en cours. Cela implique l'ouverture de fichiers, leur mappage en mémoire, l'allocation de mémoire supplémentaire, la résolution de symboles, l'application de relocalisations et bien plus encore, tout cela tout en maintenant des verrous de chargeur dynamique internes. Les verrous sont suffisants pour que ces fonctions soient non sécurisées AS et AC, mais d'autres problèmes peuvent survenir. À l'heure actuelle, il s'agit d'un espace réservé pour tous les problèmes de sécurité potentiels soulevés par dlopen.
plugin	Les fonctions annotées avec plugin peuvent exécuter du code à partir de plugins pouvant être externes à la bibliothèque glibc. Ces fonctions de plugin sont supposées être MT-Safe, AS-Unsafe et AC-Unsafe. Des exemples de tels plugins sont les bibliothèques de déroulement de pile, les back-ends de changement de service de noms (NSS) et de conversion d'ensemble de caractères (iconv). Bien que les plugins mentionnés en exemple soient tous introduits au moyen de dlopen, le mot clef plugin n'implique aucune implication directe du chargeur dynamique ou des interfaces libdl, ceux-ci sont couverts par dlopen. Par exemple, si une fonction charge un module et trouve les adresses de certaines de ses fonctions, tandis qu'une autre appelle simplement ces fonctions déjà résolues, la première sera marquée avec dlopen, tandis que la seconde obtiendra le plugin. Lorsqu'une seule fonction effectue toutes ces actions, elle obtient alors les deux marques.
i18n	Les fonctions marquées avec i18n peuvent appeler des fonctions d'internationalisation de la famille gettext et ne seront aussi sûres que ces fonctions. Cette note est donc équivalente à : \| MT-Safe env \| AS-Unsafe corrupt heap dlopen \| AC-Unsafe corrupt \|
timer	Les fonctions marquées d'un timer utilisent la fonction d'alarme ou similaire pour définir un délai d'attente pour un appel système ou une opération de longue durée. Dans un programme multi-processus léger, il existe un risque que le signal de délai d'attente soit transmis à un autre processus léger, ce qui empêche l'interruption du processus léger prévu. En plus d'être MT-Unsafe, ces fonctions sont toujours AS-Unsafe, car leur appel dans des gestionnaires de signaux peut interférer avec les temporisateurs définis dans le code interrompu, et AC-Unsafe, car il n'existe aucun moyen sûr de garantir qu'un temporisateur antérieur sera réinitialisé en cas d'annulation désynchronisée.

Fonctionnalités conditionnellement sûres

Pour certaines fonctionnalités rendant les fonctions dangereuses à appeler dans certains contextes, il existe des moyens connus pour éviter le problème de sécurité autrement que de s'abstenir complètement d'appeler la fonction. Les mots-clefs suivant font référence à ces fonctionnalités, et chacune de leurs définitions indique comment l'ensemble du programme doit être contraint afin de supprimer le problème de sécurité indiqué par le mot-clé. Ce n'est que lorsque toutes les raisons qui rendent une fonction dangereuse sont observées et traitées, en appliquant les contraintes documentées, que la fonction devient sûre à appeler dans un contexte.

Terme	Description
init	Les fonctions marquées avec init comme fonctionnalité MT-Unsafe effectuent l'initialisation MT-Unsafe lors de leur premier appel. L'appel d'une telle fonction au moins une fois en mode monothread supprime cette cause spécifique pour laquelle la fonction est considérée comme MT-Unsafe. Si aucune autre cause ne subsiste, la fonction peut alors être appelée en toute sécurité après le démarrage d'autres processus léger. Les fonctions marquées avec init comme fonctionnalité AS- ou AC-Unsafe utilisent le mécanisme interne libc_once ou similaire pour initialiser les structures de données internes. Si un gestionnaire de signaux interrompt un tel initialiseur et appelle une fonction qui effectue également l'initialisation libc_once, il se bloquera si la bibliothèque de processus léger a été chargée. De plus, si un initialiseur est partiellement terminé avant d'être annulé ou interrompu par un signal dont le gestionnaire nécessite la même initialisation, une partie ou la totalité de l'initialisation peut être effectuée plusieurs fois, ce qui entraîne une fuite de ressources ou même une corruption des données internes. Les applications devant appeler des fonctions marquées avec init comme une fonctionnalité AS- ou AC-Unsafe doivent s'assurer que l'initialisation est effectuée avant de configurer les gestionnaires de signaux ou d'activer l'annulation, afin que les problèmes de sécurité AS et AC liés à libc_once ne surviennent pas.
race	Les fonctions annotées avec race comme problème de sécurité MT fonctionnent sur des objets de manière à provoquer des courses de données ou des formes similaires d'interférences destructives en dehors de l'exécution simultanée. Dans certains cas, les objets sont transmis aux fonctions par les utilisateurs; dans d'autres, ils sont utilisés par les fonctions pour renvoyer des valeurs aux utilisateurs ; dans d'autres encore, ils ne sont même pas exposés aux utilisateurs. Nous considérons que l'accès aux objets transmis en tant que paramètres (indirects) aux fonctions est exempt de courses de données. L'assurance que les objets sont exempts de courses de données est de la responsabilité de l'appelant. Nous ne marquerons pas une fonction comme MT-Unsafe ou AS-Unsafe si elle se comporte mal lorsque les utilisateurs ne prennent pas les mesures requises par POSIX pour éviter les courses de données lors du traitement de tels objets. En règle générale, si une fonction est documentée comme lisant à partir d'un objet qui lui est transmis (par référence) ou le modifiant, les utilisateurs doivent utiliser des primitives de synchronisation de mémoire pour éviter les courses de données, comme ils le feraient s'ils effectuaient les accès eux-mêmes plutôt qu'en appelant la fonction de bibliothèque. Les flux FILE sont l'exception à la règle générale, dans la mesure où POSIX impose à la bibliothèque de se prémunir contre les courses de données dans de nombreuses fonctions manipulant des objets de ce type opaque spécifique. Nous considérons cela comme une commodité fournie aux utilisateurs, plutôt que comme une exigence générale dont les attentes devraient s'étendre à d'autres types. Afin de rappeler aux utilisateurs que la protection de certains paramètres est de leur responsabilité, nous allons annoter les fonctions prenant des objets de certains types comme paramètres. Nous traçons la ligne pour les objets transmis par les utilisateurs comme suit : les objets dont les types sont exposés aux utilisateurs et auxquels les utilisateurs sont censés accéder directement, tels que les tampons de mémoire, les chaînes et divers types de structures visibles par l'utilisateur, ne donnent pas de raison pour que les fonctions soient annotées avec race. Cela serait bruyant et redondant avec l'exigence générale, et peu de gens seraient surpris par le manque de protections internes de la bibliothèque lors de l'accès à des objets auxquels les utilisateurs peuvent accéder directement. En ce qui concerne les objets opaques ou de type opaque, dans la mesure où ils ne peuvent être manipulés qu'en les passant à des fonctions de bibliothèque (par exemple, FILE, DIR, obstack, iconv_t), il peut y avoir des attentes supplémentaires quant à la coordination interne de l'accès par la bibliothèque. Nous annoterons, avec race suivi de deux points et du nom de l'argument, les fonctions qui acceptent de tels objets mais qui ne se chargent pas de synchroniser l'accès à ceux-ci par défaut. Par exemple, les fonctions déverrouillées du flux FILE seront annotées, mais celles qui effectuent un verrouillage implicite sur les flux FILE par défaut ne le seront pas, même si le verrouillage implicite peut être désactivé flux par flux. Dans les deux cas, nous ne considérerons pas comme MT-Unsafe les fonctions pouvant accéder aux objets fournis par l'utilisateur de manière non sécurisée si les utilisateurs ne parviennent pas à s'assurer que les accès sont bien définis. L'idée prévaut que les utilisateurs sont censés protéger contre les courses de données tous les objets fournis par l'utilisateur auxquels la bibliothèque accède en leur nom. Cette responsabilité de l'utilisateur ne s'applique cependant pas aux objets contrôlés par la bibliothèque elle-même, tels que les objets internes et les tampons statiques utilisés pour renvoyer des valeurs à partir de certains appels. Lorsque la bibliothèque ne les protège pas contre les utilisations concurrentes, ces cas sont considérés comme MT-Unsafe et AS-Unsafe (bien que la marque de course sous AS-Unsafe soit omise car redondante avec celle sous MT-Unsafe). Comme dans le cas des objets exposés par l'utilisateur, la marque peut être suivie de deux points et d'un identifiant. L'identifiant regroupe toutes les fonctions opérant sur un certain objet non protégé; les utilisateurs peuvent éviter les problèmes de MT-Safety liés à l'accès concurrent non protégé à ces objets internes en créant un mutex non récursif lié à l'identifiant, et en conservant toujours le mutex lors de l'appel d'une fonction marquée comme racy sur cet identifiant, comme ils devraient le faire si l'identifiant était un objet sous le contrôle de l'utilisateur. Le mutex non récursif évite le problème de MT-Safety, mais il échange un problème de AS-Safety contre un autre, de sorte que l'utilisation dans les signaux asynchrones reste indéfinie. Lorsque l'identifiant se rapporte à un tampon statique utilisé pour contenir les valeurs de retour, le mutex doit être conservé aussi longtemps que le tampon reste utilisé par l'appelant. De nombreuses fonctions renvoyant des pointeurs vers des tampons statiques proposent des variantes réentrantes entreposant les valeurs de retour dans des tampons fournis par l'appelant. Dans certains cas, comme tmpname, la variante est choisie non pas en appelant un point d'entrée alternatif, mais en passant un pointeur non NULL au tampon dans lequel les valeurs renvoyées doivent être entreposées. Ces variantes sont généralement préférables dans les programmes multi-processus léger, bien que certaines d'entre elles ne soient pas MT-Safe en raison d'autres tampons internes, également documentés avec des notes de course.
const	Les fonctions marquées avec const comme problème de sécurité MT modifient de manière non atomique des objets internes étant mieux considérés comme constants, car une partie substantielle de la bibliothèque glibc y accède sans synchronisation. Contrairement à race, qui fait que les lecteurs et les écrivains d'objets internes sont considérés comme MT-Unsafe et AS-Unsafe, cette marque s'applique uniquement aux écrivains. Les écrivains restent également MT- et AS-Unsafe à appeler, mais la constance alors obligatoire des objets qu'ils modifient permet aux lecteurs d'être considérés comme MT-Safe et AS-Safe (tant qu'il n'existe aucune autre raison pour laquelle ils ne sont pas sûrs), car le manque de synchronisation n'est pas un problème lorsque les objets sont effectivement constants. L'identifiant suivant la marque const apparaîtra seul comme une note de sécurité dans les lecteurs. Les programmes souhaitant contourner ce problème de sécurité, afin d'appeler des rédacteurs, peuvent utiliser un verrou rwlock non récursif associé à l'identifiant, et protéger tous les appels aux fonctions marquées avec const suivi de l'identifiant avec un verrou d'écriture, et tous les appels aux fonctions marquées avec l'identifiant seul avec un verrou de lecture. Le verrouillage non récursif supprime le problème de sécurité MT, mais il remplace un problème de sécurité AS par un autre, de sorte que l'utilisation dans les signaux désynchronisées reste indéfinie.
sig	Les fonctions marquées avec sig comme problème de sécurité MT (ce qui implique un problème de sécurité AS identique, omis par souci de concision) peuvent installer temporairement un gestionnaire de signal à des fins internes, ce qui peut interférer avec d'autres utilisations du signal, identifiées après deux points. Ce problème de sécurité peut être contourné en s'assurant qu'aucune autre utilisation du signal n'aura lieu pendant la durée de l'appel. Il est recommandé de conserver un mutex non récursif tout en appelant toutes les fonctions utilisant le même signal temporaire ; il est recommandé de bloquer ce signal avant l'appel et de réinitialiser son gestionnaire par la suite. Il n'existe aucun moyen sûr de garantir que le gestionnaire de signal d'origine soit restauré en cas d'annulation désynchronisée, par conséquent les fonctions ainsi marquées sont également AC-Unsafe. Outre les mesures recommandées pour contourner le problème de sécurité MT et AS, afin d'éviter le problème d'annulation, il est recommandé de désactiver l'annulation désynchronisée et d'installer un gestionnaire de nettoyage pour restaurer le signal à l'état souhaité et libérer le mutex.
term	Les fonctions marquées avec term comme problème de sécurité MT peuvent modifier les paramètres du terminal de la manière recommandée, à savoir : appeler tcgetattr, modifier certains indicateurs, puis appeler tcsetattr; cela crée une fenêtre dans laquelle les modifications apportées par d'autres processus léger sont perdues. Ainsi, les fonctions marquées avec term sont MT-Unsafe. La même fenêtre permet de perdre les modifications apportées par des signaux désynchronisées. Ces fonctions sont également AS-Unsafe, mais la marque correspondante est omise car redondante. Il est donc conseillé aux applications utilisant le terminal d'éviter les interactions concurrentes et réentrantes avec lui, en ne l'utilisant pas dans les gestionnaires de signaux ou en bloquant les signaux qui pourraient l'utiliser, et en détenant un verrou lors de l'appel de ces fonctions et de l'interaction avec le terminal. Ce verrou doit également être utilisé pour l'exclusion mutuelle avec les fonctions marquées avec race:tcattr(fd), où fd est un descripteur de fichier pour le terminal de contrôle. L'appelant peut utiliser un seul mutex pour plus de simplicité, ou utiliser un mutex par terminal, même s'il est référencé par des descripteurs de fichiers différents. Les fonctions marquées du terme «Problème de sécurité AC» sont censées restaurer les paramètres du terminal à leur état d'origine, après les avoir temporairement modifiés, mais elles peuvent échouer si elles sont annulées. Outre les mesures recommandées pour contourner le problème de sécurité MT et AS, afin d'éviter le problème d'annulation, il est recommandé de désactiver l'annulation désynchronisée et d'installer un gestionnaire de nettoyage pour restaurer les paramètres du terminal à leur état d'origine et libérer le mutex.

Autres remarques de sécurité

Des mots-clefs supplémentaires peuvent être associés aux fonctions, indiquant des fonctionnalités ne rendant pas une fonction dangereuse à appeler, mais pouvant devoir être prises en compte dans certaines classes de programmes :

Terme	Description
locale	Les fonctions annotées avec locale comme problème de sécurité MT lisent à partir de l'objet locale sans aucune forme de synchronisation. Les fonctions annotées avec locale appelées simultanément avec des modifications de paramètres régionaux peuvent se comporter d'une manière ne correspant à aucun des paramètres régionaux actifs pendant leur exécution, mais à un mélange imprévisible de ceux-ci. Nous ne marquons cependant pas ces fonctions comme MT- ou AS-Unsafe, car les fonctions modifiant l'objet locale sont marquées avec const:locale et considérées comme non sécurisées. Étant non sécurisées, ces dernières ne doivent pas être appelées lorsque plusieurs processus léger sont en cours d'exécution ou que des signaux asynchrones sont activés, et donc la locale peut être considérée comme effectivement constante dans ces contextes, ce qui rend la première sûre.
env	Les fonctions marquées avec env comme problème de sécurité MT accèdent à l'environnement avec getenv ou similaire, sans aucune protection pour assurer la sécurité en présence de modifications simultanées. Nous ne marquons cependant pas ces fonctions comme MT- ou AS-Unsafe, car les fonctions modifiant l'environnement sont toutes marquées avec const:env et considérées comme non sûres. Étant non sûres, ces dernières ne doivent pas être appelées lorsque plusieurs processus léger sont en cours d'exécution ou que des signaux asynchrones sont activés, et donc l'environnement peut être considéré comme effectivement constant dans ces contextes, ce qui rend le premier sûr.
hostid	La fonction marquée avec hostid comme problème de sécurité MT lit à partir des structures de données à l'échelle du système contenant l'«ID d'hôte» de la machine. Ces structures de données ne peuvent généralement pas être modifiées de manière atomique. Comme il est prévu que l'«ID d'hôte» ne change normalement pas, la fonction la lisant (gethostid) est considérée comme sûre, tandis que la fonction la modifiant (sethostid) est marquée avec const:hostid, indiquant qu'elle peut nécessiter une attention particulière si elle doit être appelée. Dans ce cas précis, l'attention particulière s'apparente à une coordination à l'échelle du système (et pas seulement au sein d'un processus).
sigintr	Les fonctions marquées avec sigintr comme problème de sécurité MT accèdent à la structure de données interne _sigintr sans aucune protection pour garantir la sécurité en présence de modifications simultanées. Nous ne marquons cependant pas ces fonctions comme MT- ou AS-Unsafe, car les fonctions qui modifient cette structure de données sont toutes marquées avec const:sigintr et considérées comme non sécurisées. Étant non sécurisées, ces dernières ne doivent pas être appelées lorsque plusieurs processus légers sont en cours d'exécution ou que des signaux asynchrones sont activés, et donc la structure de données peut être considérée comme effectivement constante dans ces contextes, ce qui rend la première sûre.
fd	Les fonctions annotées avec fd comme problème de sécurité AC peuvent divulguer des descripteurs de fichiers si l'annulation asynchrone du processus léger interrompt leur exécution. Les fonctions allouant ou désallouent des descripteurs de fichiers seront généralement marquées comme telles. Même si elles ont tenté de protéger l'allocation et la désallocation du descripteur de fichier avec des régions de nettoyage, l'allocation d'un nouveau descripteur et le stockage de son numéro où la région de nettoyage pourrait le libérer ne peuvent pas être effectués en une seule opération atomique. De même, la libération du descripteur et son retrait de la structure de données normalement responsable de sa libération ne peuvent pas être effectués de manière atomique. Il y aura toujours une fenêtre dans laquelle le descripteur ne peut pas être libéré car il n'a pas encore été stocké dans l'argument du gestionnaire de nettoyage, ou il a déjà été retiré avant sa libération. Il ne peut pas être retiré après sa libération : un descripteur ouvert peut signifier soit que le descripteur doit encore être fermé, soit qu'il l'a déjà fait mais que le descripteur a été réalloué par un autre thread ou gestionnaire de signaux. De telles fuites peuvent être évitées en interne, avec une certaine pénalité de performance, en désactivant temporairement l'annulation désynchronisée du processus léger. Cependant, étant donné que les appelants des fonctions d'allocation ou de désallocation devraient le faire eux-mêmes, pour éviter le même type de fuite dans leur propre couche, il est plus logique que la bibliothèque suppose qu'elle s'en occupe plutôt que d'imposer une pénalité de performance étant redondante lorsque le problème est résolu dans les couches supérieures et insuffisante dans le cas contraire. Cette remarque en elle-même ne conduit pas à considérer une fonction comme AC-Unsafe. Cependant, les effets cumulatifs de telles fuites peuvent poser un problème pour certains programmes. Si tel est le cas, il est recommandé de suspendre l'annulation asynchrone pendant la durée des appels à ces fonctions.
mem	Les fonctions annotées avec mem comme problème de sécurité AC peuvent fuir la mémoire si l'annulation asynchrone du processus léger interrompt leur exécution. Le problème est similaire à celui des descripteurs de fichiers : il n'existe pas d'interface atomique pour allouer de la mémoire et entreposer son adresse dans le paramètre d'un gestionnaire de nettoyage, ou pour la libérer et supprimer son adresse de cet argument, sans au moins désactiver temporairement l'annulation désynchronisée, ce que ces fonctions ne font pas. Cette remarque ne suffit pas à elle seule à faire considérer une fonction comme généralement non sécurisée AC. Cependant, les effets cumulatifs de telles fuites peuvent être suffisamment graves pour certains programmes pour que la désactivation de l'annulation désynchronisée pendant la durée des appels à ces fonctions puisse être nécessaire.
cwd	Les fonctions marquées avec cwd comme problème de sécurité MT peuvent modifier temporairement le répertoire de travail actuel pendant leur exécution, ce qui peut entraîner la résolution inattendue des noms de chemin relatifs dans d'autres processus légers ou dans des gestionnaires de signaux ou d'annulations désynchronisées. Ce n'est pas une raison suffisante pour marquer les fonctions ainsi marquées comme MT- ou AS-Unsafe, mais lorsque ce comportement est facultatif (par exemple, nftw avec FTW_CHDIR), éviter l'option peut être une bonne alternative à l'utilisation de noms de chemin complets ou d'appels système relatifs au descripteur de fichier (par exemple openat).
!posix	Cette remarque, en tant que note de sécurité MT, AS ou AC pour une fonction, indique que l'état de sécurité de la fonction est connu pour différer de l'état spécifié dans la norme POSIX. Par exemple, POSIX n'exige pas qu'une fonction soit sûre, mais notre implémentation l'est, ou vice-versa. Pour le moment, l'absence de cette remarque n'implique pas que les propriétés de sécurité que nous avons documentées soient identiques à celles imposées par POSIX pour les fonctions correspondantes.
:identifier	Les annotations peuvent parfois être suivies d'identifiants, destinés à regrouper plusieurs fonctions qui, par exemple, accèdent aux structures de données de manière non sécurisée, comme dans race et const, ou à fournir des informations plus spécifiques, comme nommer un signal dans une fonction marquée avec sig. Il est envisagé qu'il puisse également être appliqué à lock et corrupt à l'avenir. Dans la plupart des cas, l'identifiant nommera un ensemble de fonctions, mais il peut nommer des objets globaux ou des arguments de fonction, ou des propriétés identifiables ou des composants logiques qui leur sont associés, avec une notation telle que par exemple :buf(arg) pour désigner un tampon associé au paramètre arg, ou :tcattr(fd) pour désigner les attributs terminaux d'un descripteur de fichier fd. L'utilisation la plus courante des identifiants est de fournir des groupes logiques de fonctions et de paramètres devant être protégés par la même primitive de synchronisation afin de garantir un fonctionnement sûr dans un contexte donné.
/condition	Certaines annotations de sécurité peuvent être conditionnelles, dans le sens où elles ne s'appliquent que si une expression booléenne impliquant des paramètres, des variables globales ou même le noyau sous-jacent est évaluée à true. Des conditions telles que /hurd ou /!linux!bsd indiquent que le marqueur précédent ne s'applique que lorsque le noyau sous-jacent est le HURD, ou lorsqu'il ne s'agit ni de Linux ni d'un noyau BSD, respectivement. /!ps et /one_per_line indiquent que le marqueur précédent ne s'applique que lorsque l'argument ps est NULL, ou que la variable globale one_per_line est différente de zéro. Lorsque toutes les marques rendant une fonction non sûre sont ornées de telles conditions, et qu'aucune des conditions nommées ne se vérifie, alors la fonction peut être considérée comme sûre.

Berkeley Unix

La bibliothèque glibc définit des fonctionnalités de certaines versions d'Unix n'étant pas formellement standardisées, en particulier des systèmes Unix 4.2 BSD, 4.3 BSD et 4.4 BSD (également connus sous le nom de Berkeley Unix) et de SunOS (un dérivé populaire de 4.2 BSD incluant certaines fonctionnalités d'Unix System V). Ces systèmes prennent en charge la plupart des fonctionnalités ISO C et POSIX, et 4.4 BSD et les versions plus récentes de SunOS les prennent en charge toutes.

Les fonctionnalités BSD incluent les liens symboliques, la fonction select, les fonctions de signal BSD et les sockets.

SVID (The System V Interface Description)

La description de l'interface System V (SVID) est un document décrivant le système d'exploitation AT&T Unix System V. Il s'agit dans une certaine mesure d'un sur-ensemble de la norme POSIX (The Portable Operating System Interface).

La bibliothèque glibc définit la plupart des fonctionnalités requises par la SVID n'étant pas également requises par les normes ISO C ou POSIX, pour la compatibilité avec System V Unix et d'autres systèmes Unix (tels que SunOS) incluant ces fonctionnalités. Cependant, de nombreuses fonctionnalités plus obscures et moins utiles requises par la SVID ne sont pas incluses. (En fait, Unix System V lui-même ne les fournit pas toutes.)

Les fonctionnalités prises en charge par System V incluent les méthodes de communication interprocessus et de mémoire partagée, les familles de fonctions hsearch et drand48, fmtmsg et plusieurs fonctions mathématiques.

XPG (The X/Open Portability Guide)

Le X/Open Portability Guide, publié par la société X/Open Company, Ltd., est une norme plus générale que POSIX. Le X/Open détient les droits d'auteur d'Unix et le XPG spécifie les exigences pour les systèmes destinés à être un système Unix.

La bibliothèque glibc est conforme au X/Open Portability Guide, édition 4.2, avec toutes les extensions communes aux systèmes compatibles XSI (X/Open System Interface) et également toutes les extensions X/Open UNIX.

Les ajouts au-dessus de POSIX sont principalement dérivés des fonctionnalités disponibles dans les systèmes System V et BSD. Certaines des erreurs vraiment graves des systèmes System V ont cependant été corrigées. Étant donné que le respect de la norme XPG avec les extensions Unix est une condition préalable pour obtenir la marque Unix, il y a de fortes chances que la fonctionnalité soit disponible sur les systèmes commerciaux.

Linux (le noyau Linux)

La bibliothèque glibc inclut par référence la documentation des pages de manuel Linux 6.9.1 pour documenter les appels système répertoriés pour le noyau Linux. Des détails supplémentaires sur l'interface d'appel système Linux peuvent être trouvés dans System Call Interface.

Utilisation de la bibliothèque

Cette section décrit certains problèmes pratiques liés à l'utilisation de la bibliothèque glibc.

Fichiers d'entête

Les bibliothèques utilisées par les programmes C se composent en réalité de deux parties : les fichiers d'entête définissant les types et les macros et déclarent les variables et les fonctions; et la bibliothèque ou l'archive proprement dite contenant les définitions des variables et des fonctions.

(Rappelez-vous qu'en C, une déclaration fournit simplement des informations sur l'existence d'une fonction ou d'une variable et donne son type. Pour une déclaration de fonction, des informations sur les types de ses arguments peuvent également être fournies. Le but des déclarations est de permettre au compilateur de traiter correctement les références aux variables et aux fonctions déclarées. Une définition, en revanche, alloue en fait de l'espace de stockage pour une variable ou indique ce que fait une fonction.)

Pour utiliser les fonctionnalités de la bibliothèque glibc, vous devez vous assurer que les fichiers sources de votre programme incluent les fichiers d'entête appropriés. Cela permet au compilateur de disposer des déclarations de ces fonctionnalités et de traiter correctement les références à celles-ci. Une fois votre programme compilé, l'éditeur de liens résout ces références aux définitions réelles fournies dans le fichier d'archive.

Les fichiers d'entête sont inclus dans un fichier source de programme par la directive de préprocesseur «#include». Le langage C prend en charge deux formes de cette directive; la première :

#include "header"

est généralement utilisé pour inclure un fichier d'entête que vous écrivez vous-même; il contiendrait des définitions et des déclarations décrivant les interfaces entre les différentes parties de votre application particulière. En revanche :

#include <file.h>

est généralement utilisé pour inclure un fichier d'entête file.h contenant les définitions et les déclarations d'une bibliothèque standard. Ce fichier serait normalement installé dans un emplacement standard par votre administrateur système. Vous devez utiliser cette seconde forme pour les fichiers d'entête de la bibliothèque C.

En général, les directives «#include» sont placées en haut du fichier source C, avant tout autre code. Si vous commencez vos fichiers sources par des commentaires expliquant ce que fait le code du fichier (une bonne idée), placez les directives «#include» immédiatement après, après la définition de la macro de test de fonctionnalité.

La bibliothèque glibc fournit plusieurs fichiers d'entête, chacun contenant les définitions de type et de macro et les déclarations de variables et de fonctions pour un groupe de fonctionnalités liées. Cela signifie que vos programmes peuvent avoir besoin d'inclure plusieurs fichiers d'entête, selon les fonctionnalités que vous utilisez exactement.

Certains fichiers d'entête de bibliothèque incluent automatiquement d'autres fichiers d'entête de bibliothèque. Cependant, en termes de style de programmation, vous ne devriez pas vous y fier ; il est préférable d'inclure explicitement tous les fichiers d'entête requis pour les fonctionnalités de la bibliothèque que vous utilisez. Les fichiers d'entête de la bibliothèque glibc ont été écrits de telle manière qu'il n'y a pas d'importance si un fichier d'entête est accidentellement inclus plus d'une fois ; inclure un fichier d'entête une deuxième fois n'a aucun effet. De même, si votre programme doit inclure plusieurs fichiers d'en-tête, l'ordre dans lequel ils sont inclus n'a pas d'importance.

Note de compatibilité : l'inclusion de fichiers d'entête standard dans n'importe quel ordre et n'importe quel nombre de fois fonctionne dans n'importe quelle implémentation C ISO. Cependant, cela n'a traditionnellement pas été le cas dans de nombreuses implémentations C plus anciennes.

À proprement parler, vous n'avez pas besoin d'inclure un fichier d'entête pour utiliser une fonction qu'il déclare; vous pouvez déclarer la fonction explicitement vous-même. Mais il est généralement préférable d'inclure le fichier d'en-tête car il peut définir des types et des macros n'étant pas disponibles autrement et parce qu'il peut définir des remplacements de macros plus efficaces pour certaines fonctions. C'est également un moyen sûr d'avoir la déclaration correcte.

Définitions de macros des fonctions

Si nous décrivons quelque chose comme une fonction dans cette page, il se peut qu'il y ait également une définition de macro. Cela n'a normalement aucun effet sur la façon dont votre programme s'exécute : la définition de macro fait la même chose que la fonction. En particulier, les équivalents de macros pour les fonctions de bibliothèque évaluent les arguments exactement une fois, de la même manière qu'un appel de fonction le ferait. La principale raison de ces définitions de macros est qu'elles peuvent parfois produire une expansion en ligne étant considérablement plus rapide qu'un appel de fonction réel.

Prendre l'adresse d'une fonction de bibliothèque fonctionne même si elle est également définie comme une macro. En effet, dans ce contexte, le nom de la fonction n'est pas suivi de la parenthèse gauche étant syntaxiquement nécessaire pour reconnaître un appel de macro.

Vous pouvez parfois vouloir éviter d'utiliser la définition de macro d'une fonction, peut-être pour rendre votre programme plus facile à déboguer. Il existe deux façons de procéder :

Vous pouvez éviter une définition de macro dans une utilisation spécifique en mettant le nom de la fonction entre parenthèses. Cela fonctionne parce que le nom de la fonction n'apparaît pas dans un contexte syntaxique où il est reconnaissable comme un appel de macro.
Vous pouvez supprimer toute définition de macro pour un fichier source entier en utilisant la directive de préprocesseur «#undef», sauf indication contraire explicite dans la description de cette fonction.

Par exemple, supposons que le fichier d'entête stdlib.h déclare une fonction nommée abs avec :



extern int abs (int);

et fournit également une définition macro pour abs. Ensuite, dans :



#include <stdlib.h>

int f (int *i) { return abs (++*i); }

la référence à abs peut se référer soit à une macro soit à une fonction. D'autre part, dans chacun des exemples suivants, la référence se fait à une fonction et non à une macro :



#include <stdlib.h>

int g (int *i) { return (abs) (++*i); }

 
#undef abs

int h (int *i) { return abs (++*i); }

Étant donné que les définitions de macro faisant double emploi avec une fonction se comportent exactement de la même manière que la version réelle de la fonction, aucune de ces méthodes n'est généralement nécessaire. En fait, la suppression des définitions de macro ne fait généralement que ralentir votre programme.

Noms réservés

Les noms de tous les types de bibliothèques, macros, variables et fonctions issus de la norme ISO C sont réservés sans condition; votre programme ne peut pas redéfinir ces noms. Tous les autres noms de bibliothèques sont réservés si votre programme inclut explicitement le fichier d'entête les définissant ou les déclare. Ces restrictions peuvent s'expliquer de plusieurs manières :

Les autres personnes lisant votre code pourraient être très confuses si vous utilisiez une fonction nommée exit pour faire quelque chose de complètement différent de ce que fait la fonction exit standard, par exemple. Empêcher cette situation permet de rendre vos programmes plus faciles à comprendre et contribue à la modularité et à la maintenabilité.
Cela évite la possibilité qu'un utilisateur redéfinisse accidentellement une fonction de bibliothèque appelée par d'autres fonctions de bibliothèque. Si la redéfinition était autorisée, ces autres fonctions ne fonctionneraient pas correctement.
Cela permet au compilateur d'effectuer toutes les optimisations spéciales qu'il souhaite sur les appels à ces fonctions, sans qu'elles aient pu être redéfinies par l'utilisateur. Certaines fonctionnalités de la bibliothèque, telles que celles permettant de gérer les paramètres variadic (voir Fonctions Variadic) et les sorties non locales, nécessitent en réalité une coopération considérable de la part du compilateur C, et en ce qui concerne l'implémentation, il pourrait être plus facile pour le compilateur de les traiter comme des parties intégrées du langage.

Outre les noms documentés dans cette page, les noms réservés incluent tous les identifiants externes (fonctions et variables globales) commençant par un trait de soulignement («_») et tous les identifiants, quelle que soit leur utilisation, commençant par deux traits de soulignement ou un trait de soulignement suivi d'une majuscule sont des noms réservés. Cela permet à la bibliothèque et aux fichiers d'entête de définir des fonctions, des variables et des macros à des fins internes sans risque de conflit avec les noms des programmes utilisateur.

Certaines classes supplémentaires de noms d'identifiants sont réservées pour de futures extensions du langage C ou de l'environnement POSIX.1. Bien que l'utilisation de ces noms pour vos propres besoins ne pose pas de problème pour le moment, ils soulèvent la possibilité d'un conflit avec les futures versions des normes C ou POSIX, vous devez donc éviter ces noms.

Les noms commençant par un «E» majuscule suivi d'un chiffre ou d'une lettre majuscule peuvent être utilisés pour des noms de codes d'erreur supplémentaires.
Les noms commençant par «is» ou «to» suivi d'une lettre minuscule peuvent être utilisés pour des fonctions de test et de conversion de caractères supplémentaires.
Les noms commençant par «LC_» suivi d'une lettre majuscule peuvent être utilisés pour des macros supplémentaires spécifiant des attributs régionaux.
Les noms de toutes les fonctions mathématiques existantes suffixés par «f» ou «l» sont réservés aux fonctions correspondantes qui fonctionnent respectivement sur des paramètres float et long double.
Les noms commençant par «SIG» suivi d'une lettre majuscule sont réservés pour des noms de signaux supplémentaires.
Les noms commençant par «SIG_» suivi d'une lettre majuscule sont réservés pour des actions de signaux supplémentaires.
Les noms commençant par «str», «mem» ou «wcs» suivi d'une lettre minuscule sont réservés pour des fonctions de chaîne et de tableau supplémentaires.
Les noms se terminant par «_t» sont réservés pour des noms de type supplémentaires.

De plus, certains fichiers d'entête individuels réservent des noms au-delà de ceux qu'ils définissent réellement. Vous n'avez à vous soucier de ces restrictions que si votre programme inclut ce fichier d'entête particulier.

Le fichier d'entête dirent.h réserve les noms préfixés par «d_».
Le fichier d'entête fcntl.h réserve les noms préfixés par «l_», «F_», «O_» et «S_».
Le fichier d'entête grp.h réserve les noms préfixés par «gr_».
Le fichier d'entête limits.h réserve les noms suffixés par «_MAX».
Le fichier d'entête pwd.h réserve les noms préfixés par «pw_».
Le fichier d'entête signal.h réserve les noms préfixés par «sa_» et «SA_».
Le fichier d'entête sys/stat.h réserve les noms préfixés par «st_» et «S_».
Le fichier d'entête sys/times.h réserve les noms préfixés par «tms_».
Le fichier d'entête termios.h réserve les noms préfixés par «c_», «V», «I», «O» et «TC» ; et les noms préfixés par « B » suivi d'un chiffre.

Macros de test de fonctionnalités

L'ensemble exact des fonctionnalités disponibles lorsque vous compilez un fichier source est contrôlé par les macros de test de fonctionnalités que vous définissez.

Si vous compilez vos programmes en utilisant «gcc -ansi», vous obtenez uniquement les fonctionnalités de la bibliothèque ISO C, à moins que vous ne demandiez explicitement des fonctionnalités supplémentaires en définissant une ou plusieurs macros de fonctionnalités. Voir les options de la commande GNU CC.

Vous devez définir ces macros en utilisant les directives de préprocesseur «#define» en haut de vos fichiers de code source. Ces directives doivent apparaître avant tout #include d'un fichier d'entête système. Il est préférable de les placer en tout premier dans le fichier, précédées uniquement de commentaires. Vous pouvez également utiliser l'option «-D» pour GCC, mais il est préférable de faire en sorte que les fichiers sources indiquent leur propre signification de manière autonome.

Ce système existe pour permettre à la bibliothèque de se conformer à plusieurs normes. Bien que les différentes normes soient souvent décrites comme des sur-ensembles les unes des autres, elles sont généralement incompatibles car les normes plus importantes nécessitent des fonctions avec des noms que les plus petites réservent au programme utilisateur. Ce n'est pas de la simple pédanterie - cela a été un problème dans la pratique. Par exemple, certains programmes non GNU définissent des fonctions nommées getline n'ayant rien à voir avec le getline de cette bibliothèque. Elles ne seraient pas compilables si toutes les fonctionnalités étaient activées sans distinction.

Cela ne doit pas être utilisé pour vérifier qu'un programme est conforme à une norme limitée. C'est insuffisant à cette fin, car cela ne vous protégera pas contre l'inclusion de fichiers d'entête en dehors de la norme, ou contre le recours à une sémantique non définie dans la norme.

Macro : _POSIX_SOURCE

Si vous définissez cette macro, les fonctionnalités de la norme POSIX.1 (norme IEEE 1003.1) sont alors disponibles, ainsi que toutes les fonctionnalités ISO C.

L'état de _POSIX_SOURCE n'a aucune importance si vous définissez la macro _POSIX_C_SOURCE sur un entier positif.

Macro : _POSIX_C_SOURCE

Définissez cette macro sur un entier positif pour contrôler les fonctionnalités POSIX mises à disposition. Plus la valeur de cette macro est élevée, plus les fonctionnalités mises à disposition sont nombreuses.

Si vous définissez cette macro sur une valeur supérieure ou égale à 1, les fonctionnalités de l'édition 1990 de la norme POSIX.1 (norme IEEE 1003.1-1990) sont alors mises à disposition.

Si vous définissez cette macro sur une valeur supérieure ou égale à 2, les fonctionnalités de l'édition 1992 de la norme POSIX.2 (norme IEEE 1003.2-1992) sont alors mises à disposition.

Si vous définissez cette macro sur une valeur supérieure ou égale à 199309L, les fonctionnalités de l'édition 1993 de la norme POSIX.1b (norme IEEE 1003.1b-1993) sont alors mises à disposition.

Si vous définissez cette macro sur une valeur supérieure ou égale à 199506L, alors les fonctionnalités de l'édition 1995 de la norme POSIX.1c (norme IEEE 1003.1c-1995) sont disponibles.

Si vous définissez cette macro sur une valeur supérieure ou égale à 200112L, alors les fonctionnalités de l'édition 2001 de la norme POSIX (norme IEEE 1003.1-2001) sont disponibles.

Si vous définissez cette macro sur une valeur supérieure ou égale à 200809L, alors les fonctionnalités de l'édition 2008 de la norme POSIX (norme IEEE 1003.1-2008) sont disponibles.

Des valeurs supérieures pour _POSIX_C_SOURCE permettront des extensions futures. Le processus de normalisation POSIX définira ces valeurs si nécessaire, et la bibliothèque glibc devrait les prendre en charge quelque temps après leur normalisation. L'édition 1996 de POSIX.1 (ISO/IEC 9945-1 : 1996) stipule que si vous définissez _POSIX_C_SOURCE avec une valeur supérieure ou égale à 199506L, alors les fonctionnalités de l'édition 1996 sont disponibles. En général, dans la bibliothèque glibc, les corrections de bogues des normes sont incluses lors de la spécification de la version de base; par exemple, POSIX.1-2004 sera toujours inclus avec une valeur de 200112L.

Macro : _XOPEN_SOURCE Macro : _XOPEN_SOURCE_EXTENDED

Si vous définissez cette macro, les fonctionnalités décrites dans le Guide de portabilité X/Open sont incluses. Il s'agit d'un sur-ensemble des fonctionnalités POSIX.1 et POSIX.2 et en fait _POSIX_SOURCE et _POSIX_C_SOURCE sont automatiquement définies.

Comme l'unification de tous les Unix, les fonctionnalités uniquement disponibles dans BSD et SVID sont également incluses.

Si la macro _XOPEN_SOURCE_EXTENDED est également définie, encore plus de fonctionnalités sont disponibles. Les fonctions supplémentaires rendront disponibles toutes les fonctions nécessaires à la marque X/Open Unix.

Si la macro _XOPEN_SOURCE a la valeur 500, cela inclut toutes les fonctionnalités décrites jusqu'à présent ainsi que certaines nouvelles définitions de la spécification Single Unix, version 2. La valeur 600 (correspondant à la sixième révision) inclut les définitions de SUSv3, et l'utilisation de 700 (la septième révision) inclut les définitions de SUSv4.

Macro : _LARGEFILE_SOURCE

Si cette macro est définie, des fonctions supplémentaires sont disponibles, corrigeant quelques lacunes de toutes les normes précédentes. En particulier, les fonctions fseeko et ftello sont disponibles. Sans ces fonctions, la différence entre l'interface ISO C (fseek, ftell) et l'interface POSIX de bas niveau (lseek) entraînerait des problèmes.

Cette macro a été introduite dans le cadre de l'extension Large File Support (LFS).

Macro : _LARGEFILE64_SOURCE

Si vous définissez cette macro, un ensemble supplémentaire de fonctions est mis à disposition, ce qui permet aux systèmes 32 bits d'utiliser des fichiers dont la taille dépasse la limite habituelle de 2 Go. Cette interface n'est pas disponible si le système ne prend pas en charge les fichiers de cette taille. Sur les systèmes où la limite naturelle de taille de fichier est supérieure à 2 Go (c'est-à-dire sur les systèmes 64 bits), les nouvelles fonctions sont identiques aux fonctions remplacées.

La nouvelle fonctionnalité est mise à disposition par un nouvel ensemble de types et de fonctions remplaçant ceux existants. Les noms de ces nouveaux objets contiennent 64 pour indiquer l'intention, par exemple, off_t contre off64_t et fseeko contre fseeko64.

Cette macro a été introduite dans le cadre de l'extension Large File Support (LFS). Il s'agit d'une interface de transition pour la période où les déplacements 64 bits ne sont généralement pas utilisés (voir _FILE_OFFSET_BITS).

Macro : _FILE_OFFSET_BITS

Cette macro détermine quelle interface de système de fichiers doit être utilisée, l'une remplaçant l'autre. Alors que _LARGEFILE64_SOURCE rend l'interface 64 bits disponible en tant qu'interface supplémentaire, _FILE_OFFSET_BITS permet à l'interface 64 bits de remplacer l'ancienne interface.

Si _FILE_OFFSET_BITS est défini sur la valeur 32, l'interface 32 bits est utilisée et les types comme off_t ont une taille de 32 bits sur les systèmes 32 bits.

Si la macro est définie sur la valeur 64, l'interface de fichier volumineux remplace l'ancienne interface. C'est-à-dire que les fonctions ne sont pas rendues disponibles sous des noms différents (comme c'est le cas avec _LARGEFILE64_SOURCE). Au lieu de cela, les anciens noms de fonction font désormais référence aux nouvelles fonctions, par exemple, un appel à fseeko appelle désormais effectivement fseeko64.

Si la macro n'est pas définie, sa valeur par défaut est actuellement 32, mais cette valeur par défaut est prévue pour changer en raison de la nécessité de mettre à jour time_t pour la sécurité Y2038, et les applications ne doivent pas s'appuyer sur la valeur par défaut.

Cette macro ne doit être sélectionnée que si le système fournit des mécanismes de gestion des fichiers volumineux. Sur les systèmes 64 bits, cette macro n'a aucun effet puisque les fonctions *64 sont identiques aux fonctions normales.

Cette macro a été introduite dans le cadre de l'extension Large File Support (LFS).

Macro : _TIME_BITS

Définissez cette macro pour contrôler la taille en bits de time_t, et donc la taille en bits de tous les types dérivés de time_t et les prototypes de toutes les fonctions associées.

Si _TIME_BITS n'est pas défini, la taille en bits de time_t dépend de l'architecture. Actuellement, elle est par défaut de 64 bits sur la plupart des architectures. Bien qu'elle soit par défaut de 32 bits sur certaines architectures traditionnelles (i686, ARM), cela est prévu pour changer et les applications ne doivent pas s'y fier.

Si _TIME_BITS est défini sur 64, time_t est défini sur un entier de 64 bits. Sur les plates-formes où time_t était traditionnellement de 32 bits, les appels aux appels système appropriés dépendent de la version du noyau Linux sur laquelle le système s'exécute. Pour les versions du noyau Linux supérieures à 5.1, les appels système prenant en charge le temps 64 bits sont utilisés. Sinon, un code de secours est utilisé avec les appels système hérités (c'est-à-dire 32 bits).
Sur de telles plateformes, la bibliothèque glibc définira également __USE_TIME64_REDIRECTS pour indiquer si les déclarations sont étendues à d'autres (soit en redéfinissant le nom du symbole, soit en utilisant des alias de symbole). Par exemple, si le symbole clock_gettime s'étend à __glock_gettime64.
Si _TIME_BITS est défini à 32, time_t est défini comme un entier 32 bits lorsque cela est pris en charge. Cela n'est pas recommandé, car time_t 32 bits cesse de fonctionner en 2038. Pour tout autre cas d'utilisation, une erreur de compilation est émise.

_TIME_BITS=64 ne peut être défini que lorsque _FILE_OFFSET_BITS=64 est également défini.

En utilisant cette macro, certains ports prennent en charge le temps 64 bits et deviennent ainsi immunisés contre le problème Y2038.

Macro : _ISOC99_SOURCE

Si cette macro est définie, les fonctionnalités de la norme ISO C99 sont incluses. Étant donné que ces fonctionnalités sont incluses par défaut, cette macro est particulièrement pertinente lorsque le compilateur utilise une version antérieure du langage.

Macro : _ISOC11_SOURCE

Si cette macro est définie, les extensions ISO C11 à ISO C99 sont incluses.

Macro : _ISOC23_SOURCE

Si cette macro est définie, les extensions ISO C23 à ISO C11 sont incluses. Seules certaines fonctionnalités de ce projet de norme sont prises en charge par la bibliothèque glibc. L'ancien nom _ISOC2X_SOURCE est également pris en charge.

Macro : __STDC_WANT_LIB_EXT2__

Si vous définissez cette macro sur la valeur 1, les fonctionnalités de la norme ISO/IEC TR 24731-2:2010 (fonctions d'allocation dynamique) sont activées. Seules certaines des fonctionnalités de cette norme TR sont prises en charge par la bibliothèque glibc.

Macro : __STDC_WANT_IEC_60559_BFP_EXT__

Si vous définissez cette macro, les fonctionnalités de la norme ISO/IEC TS 18661-1:2014 (Extensions à virgule flottante pour C : arithmétique binaire à virgule flottante) sont activées. Seules certaines des fonctionnalités de cette norme TS sont prises en charge par la bibliothèque glibc.

Macro : __STDC_WANT_IEC_60559_FUNCS_EXT__

Si vous définissez cette macro, les fonctionnalités de la norme ISO/IEC TS 18661-4:2015 (Floating-point extensions for C: Supplementary functions) sont activées. Seules certaines des fonctionnalités de cette norme TS sont prises en charge par la bibliothèque glibc.

Macro : __STDC_WANT_IEC_60559_TYPES_EXT__

Si vous définissez cette macro, les fonctionnalités de la norme ISO/IEC TS 18661-3:2015 (Floating-point extensions for C: Interchange and extended types) sont activées. Seules certaines des fonctionnalités de cette norme TS sont prises en charge par la bibliothèque glibc.

Macro : __STDC_WANT_IEC_60559_EXT__

Si vous définissez cette macro, les fonctionnalités ISO C23 de cette norme sont activées. Cela affecte les déclarations des fonctions totalorder et des fonctions liées aux charges utiles NaN.

Macro : _GNU_SOURCE

Si vous définissez cette macro, tout est inclus : ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS et les extensions GNU. Dans les cas où POSIX.1 entre en conflit avec BSD, les définitions POSIX ont la priorité.

Macro : _DEFAULT_SOURCE

Si vous définissez cette macro, la plupart des fonctionnalités sont incluses, à l'exception des extensions X/Open, LFS et GNU : l'effet est d'activer les fonctionnalités de l'édition 2008 de POSIX, ainsi que certaines fonctionnalités BSD et SVID sans macro de test de fonctionnalité distincte pour les contrôler.

Sachez que les options du compilateur affectent également les fonctionnalités incluses :

Si vous utilisez une option de conformité stricte, les fonctionnalités au-delà de celles de la version linguistique du compilateur seront désactivées, bien que des macros de test de fonctionnalité puissent être utilisées pour les activer.
Les fonctionnalités activées par les options du compilateur ne sont pas remplacées par les macros de test de fonctionnalité.

Macro : _ATFILE_SOURCE

Si cette macro est définie, des interfaces *at supplémentaires sont incluses.

Macro : _FORTIFY_SOURCE

Si cette macro est définie à 1, un renforcement de la sécurité est ajouté à diverses fonctions de la bibliothèque. Si elle est définie à 2, des contrôles encore plus stricts sont appliqués. Si elle est définie à 3, la bibliothèque glibc peut également utiliser des contrôles pouvant entraîner une surcharge de performances supplémentaire.

Macro : _DYNAMIC_STACK_SIZE_SOURCE

Si cette macro est définie, les valeurs correctes (mais non constantes au moment de la compilation) MINSIGSTKSZ, SIGSTKSZ et PTHREAD_STACK_MIN sont définies.

Macro : _REENTRANT Macro : _THREAD_SAFE

Ces macros sont obsolètes. Elles ont le même effet que la définition de _POSIX_C_SOURCE avec la valeur 199506L.
Certaines bibliothèques C très anciennes nécessitaient la définition d'une de ces macros pour que les fonctionnalités de base (par exemple getchar) soient thread-safe.

Nous vous recommandons d'utiliser _GNU_SOURCE dans les nouveaux programmes. Si vous ne spécifiez pas l'option «-ansi» pour GCC, ou d'autres options de conformité telles que -std=c99, et ne définissez aucune de ces macros explicitement, l'effet est le même que la définition de _DEFAULT_SOURCE à 1.

Lorsque vous définissez une macro de test de fonctionnalité pour demander une classe plus large de fonctionnalités, il est inoffensif de définir en plus une macro de test de fonctionnalité pour un sous-ensemble de ces fonctionnalités. Par exemple, si vous définissez _POSIX_C_SOURCE, définir également _POSIX_SOURCE n'a aucun effet. De même, si vous définissez _GNU_SOURCE, définir également _POSIX_SOURCE ou _POSIX_C_SOURCE n'a aucun effet.

PARTAGER CETTE PAGE SUR

Dernière mise à jour : Mercredi, le 1er janvier 2025

	ABAP/4
	Ada
	Assembleur
	Assembly & bytecode
	ASP (Active Server Pages)
	Basic
	C
	C++
	C# (C Sharp)
	Cobol
	ColdFusion
	Fortran
	HTML
	Java
	JavaScript
	LISP
	Logo
	LotusScript
	Oberon
	Pascal
	Perl
	PHP
	PL/1
	Prolog
	Python
	Rebol
	REXX
	Ruby
	Rust
	SAS
	NoSQL
	SQL
	Swift
	X++ (Axapta)

	Assembleur 370
	Assembleur 1802
	Assembleur 4004
	Assembleur 6502
	Assembleur 6800
	Assembleur 68000
	Assembleur 8080 et 8085
	Assembleur 8089
	Assembleur 80x86
	Assembleur AGC4
	Assembleur ARM
	Assembleur DPS 8000
	Assembleur i860
	Assembleur Itanium
	Assembleur MIPS
	Assembleur PDP-11
	Assembleur PowerPC
	Assembleur RISC-V
	Assembleur SPARC
	Assembleur SuperH
	Assembleur UNIVAC I
	Assembleur VAX
	Assembleur Z80
	Assembleur Z8000
	Assembleur z/Architecture

	CIL
	Jasmin
	LLVM
	MSIL
	Parrot
	P-Code (PCode)
	SWEET16

	ASP 1.0
	ASP 2.0
	ASP 3.0
	ASP.NET

	ABasiC (Amiga)
	Adam SmartBASIC
	Altair BASIC
	AmigaBASIC (Amiga)
	AMOS Basic (Amiga)
	Atari Basic (Atari 400, 600 XL, 800, 800XL)
	Basic Apple II (Integer BASIC/APPLESOFT)
	Basic Commodore 64 (CBM-BASIC)
	Basic Commodore 128 (BASIC 7.0)
	Basic Commodore VIC-20 (CBM-BASIC 2.0)
	Basic Coco 1 (Color Basic)
	Basic Coco 2 (Extended Color Basic)
	Basic Coco 3 (Extended Color Basic 2.0)
	BASICA (PC DOS)
	Basic Pro
	BBC BASIC
	Blitz BASIC (Amiga)
	DarkBASIC
	Dartmouth BASIC
	GFA-Basic (Atari ST/Amiga)
	GWBASIC (MS-DOS)
	Liberty BASIC
	Locomotive BASIC (Amstrad CPC)
	MSX-Basic
	Omikron Basic (Atari ST)
	Oric Extended Basic
	Power Basic
	Quick Basic/QBasic (MS-DOS)
	Sinclair BASIC (ZX80, ZX81, ZX Spectrum)
	ST BASIC (Atari ST)
	Turbo Basic
	Vintage BASIC
	VBScript
	Visual Basic (VB)
	Visual Basic .NET (VB .NET)
	Visual Basic pour DOS
	Yabasic

Section courante

A propos

Section administrative du site