feature_test_macros
Macros de test de fonctionnalités
- Provided by: manpages-fr (Version: 3.65d1p1-1)
- Report a bug
Macros de test de fonctionnalités
#include <features.h>
Les macros de test de fonctionnalités permettent au programmeur de contrôler quelles définitions sont exposées par les fichiers d'en‐têtes système lorsqu'un programme est compilé.
NOTE : pour avoir un effet, une macro de test de fonctionnalité doit être définie avant d'inclure tout fichier d'en‐tête. Cela peut être accompli soit dans la ligne de commande de compilation (cc -DMACRO=valeur), soit en définissant la macro dans le code source avant d'inclure tout en‐tête.
Certaines macros de test de fonctionnalités sont utiles pour créer des applications portables, en empêchant des définitions non normalisées d'être exposées. D'autres macros peuvent être utilisées pour exposer des définitions non normalisées qui ne sont pas exposées par défaut. Les effets précis de chacune des macros décrites ci‐dessous peuvent être vérifiés en inspectant le fichier d'en‐tête <features.h>
Quand une fonction nécessite qu'une macro de test de fonctionnalité soit définie, la section SYNOPSIS de la page de manuel comprend généralement une note de la forme suivante (exemple pris dans la page de manuel acct(2)) :
#include <unistd.h>
int acct(const char *filename);
Exigences de macros de test de fonctionnalités pour la glibc (consultez feature_test_macros(7)) :
acct() : _BSD_SOURCE || (_XOPEN_SOURCE && _XOPEN_SOURCE < 500)
Les doubles barres || signifient que pour obtenir la déclaration de acct(2) depuis <unistd.h>, une des définitions de macros doit être utilisée avant d'inclure les fichiers d'en-tête :
#define _BSD_SOURCE #define _XOPEN_SOURCE /* ou toute valeur < 500 */
Autrement, les définitions équivalentes peuvent être faites lors de l'appel au compilateur :
cc -D_BSD_SOURCE cc -D_XOPEN_SOURCE # Ou toute valeur < 500
Veuillez noter que, comme décrit ci-dessous, certaines macros de test de fonctionnalité sont définies par défaut, et il n'est donc pas toujours nécessaire de spécifier explicitement les macros indiquées dans le SYNOPSIS.
Dans certains cas, les pages de manuel utilisent des raccourcis pour exprimer la nécessité de certaines macros de test (exemple tiré de readahead(2)) :
#define _GNU_SOURCE #include <fcntl.h> ssize_t readahead(int fd, off64_t *offset, size_t count);
Ce format est utilisé dans les cas où seule une macro de test de fonctionnalité peut être utilisée pour exposer la déclaration de la fonction et quand cette macro n'est pas définie par défaut.
Les paragraphes suivants expliquent comment les macros de test de fonctionnalité sont gérées les glibc Linux 2.x, x > 0.
La glibc de Linux comprend les macros de test de fonctionnalité suivantes :
Les versions antérieures de la glibc 2.1.x reconnaissaient une macro équivalent appelée _ISOC9X_SOURCE (parce que la norme C99 n'était pas finalisée). Même si l'utilisation de cette dernière macro est à proscrire, la glibc continue à la reconnaître pour des raisons de compatibilité ascendante.
Si _ISOC99_SOURCE est définie, les définitions du premier amendement au C ISO (1990) (aussi appelé C95) sont aussi exposées. La première modification de C95 était la prise en charge des jeux de caractères internationaux.
Les systèmes 64 bits permettent d'office d'utiliser des fichiers de taille supérieure à 2 gigaoctets, et sur ces système cette macro n'a aucun effet.
Jusqu’à la glibc 2.18 inclue, les définitions BSD sont préférées dans les situations où les normes sont en conflit, sauf si au moins une des macros _SVID_SOURCE, _POSIX_SOURCE, _POSIX_C_SOURCE, _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED ou _GNU_SOURCE est définie, auquel cas les définitions BSD sont défavorisées. Depuis la glibc 2.19, _BSD_SOURCE ne force plus la préférence des définitions BSD en cas de conflit.
Depuis la glibc 2.20, cette macro est obsolète. Sa définition a le même effet que la définition de _DEFAULT_SOURCE, mais génère un avertissement de compilation (à moins que _DEFAULT_SOURCE soit également définie). Utilisez _DEFAULT_SOURCE à la place. Pour permettre au code nécessitant _BSD_SOURCE dans glibc 2.19 et versions antérieures, et _DEFAULT_SOURCE dans glibc 2.20 et version suivantes, de compiler sans avertissement, définissez à la fois _BSD_SOURCE et _DEFAULT_SOURCE.
Depuis la glibc 2.20, cette macro est obsolète de la même manière que _BSD_SOURCE.
Les définitions par « défaut » comprennent celles requises par POSIX.1-2008 ainsi que plusieurs définitions dérivées de BSD et System V. Avec la glibc 2.19 et avant, ces définitions par défaut sont à peu près équivalentes à la définition explicite suivante :
cc -D_BSD_SOURCE -D_SVID_SOURCE -D_POSIX_C_SOURCE=200809
Depuis glibc 2.19, définir _GNU_SOURCE provoque la définition implicite de _DEFAULT_SOURCE. Dans les versions antérieures à 2.20, définir _GNU_SOURCE provoque la définition implicite de _BSD_SOURCE et _SVID_SOURCE.
Actuellement, des vérifications sont ajoutées aux appels memcpy(3), mempcpy(3), memmove(3), memset(3), stpcpy(3), strcpy(3), strncpy(3), strcat(3), strncat(3), sprintf(3), snprintf(3), vsprintf(3), vsnprintf(3) et gets(3).
Si _FORTIFY_SOURCE est défini à 1, avec un niveau d'optimisation de 1 ou plus (gcc -O1), des vérifications sans influence sur le comportement des programmes corrects sont faites. Avec _FORTIFY_SOURCE défini à 2, des vérifications supplémentaires sont ajoutées, mais certains programmes conformes peuvent échouer. Certaines vérifications peuvent être effectuées à la compilation et génèrent des avertissements du compilateur ; d'autres ont lieu à l'exécution et causent une erreur si le test échoue.
L'utilisation de cette macro nécessite une gestion par le compilateur, qui est disponible dans gcc(1) depuis la version 4.0.
Si aucune macro de test de fonctionnalité n'est définie explicitement, alors les macros de test suivantes sont définies par défaut : _BSD_SOURCE (dans la glibc 2.19 et avant), _SVID_SOURCE (dans la glibc 2.19 et avant), _DEFAULT_SOURCE (depuis glibc 2.19), _POSIX_SOURCE et _POSIX_C_SOURCE=200809L (200112L dans les versions de la glibc antérieures à 2.10 ; 199506L dans les versions de la glibc antérieures à 2.4 ; 199309L dans les versions de la glibc antérieures à ).
Si une des macros __STRICT_ANSI__, _ISOC99_SOURCE, _POSIX_SOURCE, _POSIX_C_SOURCE, _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED, _BSD_SOURCE (dans la glibc 2.19 et avant) ou _SVID_SOURCE (dans la glibc 2.19 et avant) est définie explicitement, alors _BSD_SOURCE et _SVID_SOURCE ne sont pas définies par défaut.
Si ni _POSIX_SOURCE ni _POSIX_C_SOURCE ne sont définies explicitement et que soit __STRICT_ANSI__ n'est pas définie soit _XOPEN_SOURCE est définie à une valeur supérieure ou égale à 500, alors
Plusieurs macros peuvent être définies ; les résultats sont additifs.
POSIX.1 spécifie _POSIX_C_SOURCE, _POSIX_SOURCE et _XOPEN_SOURCE. _XOPEN_SOURCE_EXTENDED est spécifiée par XPG4v2 (alias SUSv1).
_FILE_OFFSET_BITS n'est spécifiée par aucune norme, mais est utilisée par d'autres implémentations.
_BSD_SOURCE, _SVID_SOURCE, _DEFAULT_SOURCE, _ATFILE_SOURCE, _GNU_SOURCE, _FORTIFY_SOURCE, _REENTRANT et _THREAD_SAFE sont spécifiques à Linux (glibc).
<features.h> est un fichier d'en‐tête spécifique à Linux/glibc. D'autres systèmes ont un fichier similaire, mais typiquement sous un nom différent. Ce fichier est inclus automatiquement par les autres en‐têtes si nécessaire : il n'est pas nécessaire de l'inclure explicitement pour utiliser les macros de test de fonctionnalité.
Selon quelles macros de test de fonctionnalité ci‐dessus sont définies, <features.h> définit diverses autres macros qui sont testées par les en‐têtes de la glibc. Ces macros ont des noms préfixés par deux caractères underscore (par exemple __USE_MISC). Les programmes ne doivent jamais définir ces macros directement ; ils doivent utiliser les macros de test de fonctionnalité de la liste précédente.
Le programme ci-dessous peut être utilisé pour
explorer comment les différentes macros de test de
fonctionnalités sont configurées en fonction de la version de
la glibc et quelle macros sont explicitement définies.
L'exécution qui suit dans un interpréteur de commandes, sur un
système avec la glibc 2.10, montre quelques exemples de ce
qu'on peut voir :
$ cc ftm.c $ ./a.out _POSIX_SOURCE définie _POSIX_C_SOURCE définie : 200809L _BSD_SOURCE définie _SVID_SOURCE définie _ATFILE_SOURCE définie $ cc -D_XOPEN_SOURCE=500 ftm.c $ ./a.out _POSIX_SOURCE définie _POSIX_C_SOURCE définie : 199506L _XOPEN_SOURCE définie : 500 $ cc -D_GNU_SOURCE ftm.c $ ./a.out _POSIX_SOURCE définie _POSIX_C_SOURCE définie : 200809L _ISOC99_SOURCE définie _XOPEN_SOURCE définie : 700 _XOPEN_SOURCE_EXTENDED définie _LARGEFILE64_SOURCE définie _BSD_SOURCE définie _SVID_SOURCE définie _ATFILE_SOURCE définie _GNU_SOURCE définie
/* ftm.c */
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
int
main(int argc, char *argv[])
{
#ifdef _POSIX_SOURCE
printf("_POSIX_SOURCE définie\n");
#endif
#ifdef _POSIX_C_SOURCE
printf("_POSIX_C_SOURCE définie : %ldL\n", (long) _POSIX_C_SOURCE);
#endif
#ifdef _ISOC99_SOURCE
printf("_ISOC99_SOURCE définie\n");
#endif
#ifdef _ISOC11_SOURCE
printf("_ISOC11_SOURCE définie\n");
#endif
#ifdef _XOPEN_SOURCE
printf("_XOPEN_SOURCE définie : %d\n", _XOPEN_SOURCE);
#endif
#ifdef _XOPEN_SOURCE_EXTENDED
printf("_XOPEN_SOURCE_EXTENDED définie\n");
#endif
#ifdef _LARGEFILE64_SOURCE
printf("_LARGEFILE64_SOURCE définie\n");
#endif
#ifdef _FILE_OFFSET_BITS
printf("_FILE_OFFSET_BITS définie : %d\n", _FILE_OFFSET_BITS);
#endif
#ifdef _BSD_SOURCE
printf("_BSD_SOURCE définie\n");
#endif
#ifdef _SVID_SOURCE
printf("_SVID_SOURCE définie\n");
#endif
#ifdef _DEFAULT_SOURCE
printf("_DEFAULT_SOURCE définie\n");
#endif
#ifdef _ATFILE_SOURCE
printf("_ATFILE_SOURCE définie\n");
#endif
#ifdef _GNU_SOURCE
printf("_GNU_SOURCE définie\n");
#endif
#ifdef _REENTRANT
printf("_REENTRANT définie\n");
#endif
#ifdef _THREAD_SAFE
printf("_THREAD_SAFE définie\n");
#endif
#ifdef _FORTIFY_SOURCE
printf("_FORTIFY_SOURCE définie\n");
#endif
exit(EXIT_SUCCESS);
}
La section « Feature Test Macros » de info libc.
/usr/include/features.h
Cette page fait partie de la publication 3.65 du projet man-pages Linux. Une description du projet et des instructions pour signaler des anomalies peuvent être trouvées à l'adresse http://www.kernel.org/doc/man-pages/.
Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a <http://po4a.alioth.debian.org/> par l'équipe de traduction francophone au sein du projet perkamon <http://perkamon.alioth.debian.org/>.
Julien Cristau et l'équipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C <section> <page_de_man> ».