À quoi servent exactement les macros _GNU_SOURCE, _BSD_SOURCE etc ?
J'ai vu que pour déclarer certaines fonctions ou certains comportements
il fallait les définir (à priori seulement si on utilise la libc de GNU).
- Est ce pour des questions de retro compatibilités ?
- Quel impact ont ils sur le code en général (quelles fonctions sont
concernés et pourquoi) ?
- Comment bien s'en servir ?
En fait je code sur FreeBSD (avec la libc BSD donc) et ma documentation
sont les pages de manuel de FreeBSD. Le problème c'est que là dedans il
n'est nullement question de _GNU_SOURCE _BSD_SOURCE etc... Et bien
souvent il faut faire quelques aménagements pour que ça compile sur les
systèmes qui utilisent glibc. Est ce qu'il y a des pages de manuel
'portables' (au moins sur un maximum d'UNIX) disponibles en ligne ?
Un exemple frappant c'est la struct dirent de dirent.h. Dans la libc BSD
il y a l'enum d_type qui peut prendre les valeurs DT_DIR etc. Mais avec
la glibc, pour que cette enumération soit correctement déclarée il faut
un #define _BSD_SOURCE. J'ai finalement utilisé stat(2) pour que ce soit
portable sans definir _BSD_SOURCE (car j'ignore la portée que cette
macro a sur le code).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marc Boyer
Le 14-10-2009, Ksh J. Fry a écrit :
Bonjour,
Je m'attendais à ce que Marc Espie, dévelopeur OpenBSD et contributeur régulier de ce forum te réponde, mais comme il a l'air ailleurs, voilà quelques infos.
En fait, une libc (celle de BSD, celle de GNU, celle de Sun) est une sorte d'interface entre un OS et des applis. Son but est d'implanter un certain nombre d'appels systèmes "portable", en gros, répondant à certaines normes.
Sauf que celle de Sun par example n'a vocation qu'à tourner sur du solaris, alors que celle de GNU essaye d'être portable sur pleins d'OS distincts.
De plus, il existe pleins de normes: ma page de man de "stat(2)", sur ma machine linux, dans sa partie "CONFORMING TO" évoque les normes SVr4, 4.3BSD et POSIX.1-2001.
Et puis chacun veut rajouter ses petites avancées: si un OS décide d'avoir une super fonctionnalité dans son système de fichier (le couleur du ciel lors de la dernière modif du fichier), il va ajouter un moyent d'y accéder surement quelque part dans sa libc, et ce ne sera pas présent sur les autres OS.
Donc, je suppose que ces macros servent à adapter le comportement de la libc GNU à différents contextes.
En fait je code sur FreeBSD (avec la libc BSD donc) et ma documentation sont les pages de manuel de FreeBSD. Le problème c'est que là dedans il n'est nullement question de _GNU_SOURCE _BSD_SOURCE etc... Et bien souvent il faut faire quelques aménagements pour que ça compile sur les systèmes qui utilisent glibc. Est ce qu'il y a des pages de manuel 'portables' (au moins sur un maximum d'UNIX) disponibles en ligne ?
En fait, il existes plusieurs normes (cf ci dessus), et quand on développe un code, il faudrait dire pour quelle norme on code. Mais souvent, comme les système Unix-like se ressemblent, on oublie.
Il existe un consortium qui possède la marque Unix http://www.unix.org/ et ils mettent de la doc en ligne. Mais c'est peut-être trop complexe pour tes besoins.
Une autre solution, c'est d'utiliser des machines virtuelles, et d'y installer les systèmes cible.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Le 14-10-2009, Ksh J. Fry <phil@philpep.org> a écrit :
Bonjour,
Je m'attendais à ce que Marc Espie, dévelopeur OpenBSD et
contributeur régulier de ce forum te réponde, mais comme
il a l'air ailleurs, voilà quelques infos.
En fait, une libc (celle de BSD, celle de GNU, celle de Sun) est
une sorte d'interface entre un OS et des applis. Son but est d'implanter
un certain nombre d'appels systèmes "portable", en gros, répondant
à certaines normes.
Sauf que celle de Sun par example n'a vocation qu'à tourner sur
du solaris, alors que celle de GNU essaye d'être portable sur
pleins d'OS distincts.
De plus, il existe pleins de normes: ma page de man de "stat(2)",
sur ma machine linux, dans sa partie "CONFORMING TO" évoque les
normes SVr4, 4.3BSD et POSIX.1-2001.
Et puis chacun veut rajouter ses petites avancées: si un OS
décide d'avoir une super fonctionnalité dans son système de fichier
(le couleur du ciel lors de la dernière modif du fichier), il
va ajouter un moyent d'y accéder surement quelque part dans
sa libc, et ce ne sera pas présent sur les autres OS.
Donc, je suppose que ces macros servent à adapter le comportement
de la libc GNU à différents contextes.
En fait je code sur FreeBSD (avec la libc BSD donc) et ma documentation
sont les pages de manuel de FreeBSD. Le problème c'est que là dedans il
n'est nullement question de _GNU_SOURCE _BSD_SOURCE etc... Et bien
souvent il faut faire quelques aménagements pour que ça compile sur les
systèmes qui utilisent glibc. Est ce qu'il y a des pages de manuel
'portables' (au moins sur un maximum d'UNIX) disponibles en ligne ?
En fait, il existes plusieurs normes (cf ci dessus), et quand on
développe un code, il faudrait dire pour quelle norme on code.
Mais souvent, comme les système Unix-like se ressemblent, on
oublie.
Il existe un consortium qui possède la marque Unix
http://www.unix.org/
et ils mettent de la doc en ligne. Mais c'est peut-être trop complexe
pour tes besoins.
Une autre solution, c'est d'utiliser des machines virtuelles, et d'y
installer les systèmes cible.
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Je m'attendais à ce que Marc Espie, dévelopeur OpenBSD et contributeur régulier de ce forum te réponde, mais comme il a l'air ailleurs, voilà quelques infos.
En fait, une libc (celle de BSD, celle de GNU, celle de Sun) est une sorte d'interface entre un OS et des applis. Son but est d'implanter un certain nombre d'appels systèmes "portable", en gros, répondant à certaines normes.
Sauf que celle de Sun par example n'a vocation qu'à tourner sur du solaris, alors que celle de GNU essaye d'être portable sur pleins d'OS distincts.
De plus, il existe pleins de normes: ma page de man de "stat(2)", sur ma machine linux, dans sa partie "CONFORMING TO" évoque les normes SVr4, 4.3BSD et POSIX.1-2001.
Et puis chacun veut rajouter ses petites avancées: si un OS décide d'avoir une super fonctionnalité dans son système de fichier (le couleur du ciel lors de la dernière modif du fichier), il va ajouter un moyent d'y accéder surement quelque part dans sa libc, et ce ne sera pas présent sur les autres OS.
Donc, je suppose que ces macros servent à adapter le comportement de la libc GNU à différents contextes.
En fait je code sur FreeBSD (avec la libc BSD donc) et ma documentation sont les pages de manuel de FreeBSD. Le problème c'est que là dedans il n'est nullement question de _GNU_SOURCE _BSD_SOURCE etc... Et bien souvent il faut faire quelques aménagements pour que ça compile sur les systèmes qui utilisent glibc. Est ce qu'il y a des pages de manuel 'portables' (au moins sur un maximum d'UNIX) disponibles en ligne ?
En fait, il existes plusieurs normes (cf ci dessus), et quand on développe un code, il faudrait dire pour quelle norme on code. Mais souvent, comme les système Unix-like se ressemblent, on oublie.
Il existe un consortium qui possède la marque Unix http://www.unix.org/ et ils mettent de la doc en ligne. Mais c'est peut-être trop complexe pour tes besoins.
Une autre solution, c'est d'utiliser des machines virtuelles, et d'y installer les systèmes cible.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Benoit Izac
Bonjour,
le 14/10/2009 à 13:09, Ksh J. Fry a écrit dans le message <4ad5b1d6$0$25285$ :
À quoi servent exactement les macros _GNU_SOURCE, _BSD_SOURCE etc ? J'ai vu que pour déclarer certaines fonctions ou certains comportements il fallait les définir (à priori seulement si on utilise la libc de GNU).
Ce groupe n'est pas le plus adapté pour ce genre de question car il traite de la norme AINSI C comme définit par les standards C89 (ANSI X3.159-1989) ou C99 (ISO/IEC 9899:1999). GNU ou BSD étant plus large, le groupe le plus adapté pour en parler est plutôt fr.comp.os.unix.
- Est ce pour des questions de retro compatibilités ?
Non. Disons plutôt que ce sont des extensions au standard POSIX (IEEE Std 1003.1) ou à la norme C (POSIX étant déjà une extension à C).
- Quel impact ont ils sur le code en général (quelles fonctions sont concernés et pourquoi) ?
C'est assez vaste. Définir ces macros peut t'apporter des fonctions ou des type supplémentaires ou encore modifier le comportement d'une fonction. Pourquoi ? Parce que chacun a une vision différente de ce qui doit être fait.
- Comment bien s'en servir ?
#define _GNU_SOURCE #include <unistd.h> ret = setresuid(ruid, euid, suid);
Sans le #define _GNU_SOURCE, la fonction setresuid n'existe pas (sur mon sytème, sur d'autre, avec ou sans elle n'existera pas).
En fait je code sur FreeBSD (avec la libc BSD donc) et ma documentation sont les pages de manuel de FreeBSD. Le problème c'est que là dedans il n'est nullement question de _GNU_SOURCE _BSD_SOURCE etc... Et bien souvent il faut faire quelques aménagements pour que ça compile sur les systèmes qui utilisent glibc. Est ce qu'il y a des pages de manuel 'portables' (au moins sur un maximum d'UNIX) disponibles en ligne ?
Normalement tout code se conforment à Single Unix Specification <http://www.unix.org/single_unix_specification/> devrait compiler sur un système UNIX. Note que beaucoup moins de fonctions existent que sur ton système.
Un exemple frappant c'est la struct dirent de dirent.h. Dans la libc BSD il y a l'enum d_type qui peut prendre les valeurs DT_DIR etc. Mais avec la glibc, pour que cette enumération soit correctement déclarée il faut un #define _BSD_SOURCE. J'ai finalement utilisé stat(2) pour que ce soit portable sans definir _BSD_SOURCE (car j'ignore la portée que cette macro a sur le code).
POSIX se moque de d_type : <http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html>
Dans la page de manuel de readdir(3) sous Linux :
| Other than Linux, the d_type field is available mainly only on BSD | systems. This field makes it possible to avoid the expense of calling | lstat(2) if further actions depend on the type of the file. If the | _BSD_SOURCE feature test macro is defined, then glibc defines the fol‐ | lowing macro constants for the value returned in d_type: | | DT_BLK This is a block device. | DT_CHR This is a character device. | DT_DIR This is a directory. | DT_FIFO This is a named pipe (FIFO). | DT_LNK This is a symbolic link. | DT_REG This is a regular file. | DT_SOCK This is a Unix domain socket. | DT_UNKNOWN The file type is unknown.
voir aussi <http://www.kernel.org/doc/man-pages/online/pages/man7/feature_test_macros.7.html>
Après, il y a certaine fonctions que tu trouveras sur un système et que tu ne trouveras pas sur un autre même avec _BSD_SOURCE (au hasard strlcpy ;-)).
-- Benoit Izac
Bonjour,
le 14/10/2009 à 13:09, Ksh J. Fry a écrit dans le message
<4ad5b1d6$0$25285$426a74cc@news.free.fr> :
À quoi servent exactement les macros _GNU_SOURCE, _BSD_SOURCE etc ?
J'ai vu que pour déclarer certaines fonctions ou certains comportements
il fallait les définir (à priori seulement si on utilise la libc de GNU).
Ce groupe n'est pas le plus adapté pour ce genre de question car il
traite de la norme AINSI C comme définit par les standards C89 (ANSI
X3.159-1989) ou C99 (ISO/IEC 9899:1999). GNU ou BSD étant plus large, le
groupe le plus adapté pour en parler est plutôt fr.comp.os.unix.
- Est ce pour des questions de retro compatibilités ?
Non. Disons plutôt que ce sont des extensions au standard POSIX (IEEE
Std 1003.1) ou à la norme C (POSIX étant déjà une extension à C).
- Quel impact ont ils sur le code en général (quelles fonctions sont
concernés et pourquoi) ?
C'est assez vaste. Définir ces macros peut t'apporter des fonctions ou
des type supplémentaires ou encore modifier le comportement d'une
fonction. Pourquoi ? Parce que chacun a une vision différente de ce qui
doit être fait.
- Comment bien s'en servir ?
#define _GNU_SOURCE
#include <unistd.h>
ret = setresuid(ruid, euid, suid);
Sans le #define _GNU_SOURCE, la fonction setresuid n'existe pas (sur mon
sytème, sur d'autre, avec ou sans elle n'existera pas).
En fait je code sur FreeBSD (avec la libc BSD donc) et ma documentation
sont les pages de manuel de FreeBSD. Le problème c'est que là dedans il
n'est nullement question de _GNU_SOURCE _BSD_SOURCE etc... Et bien
souvent il faut faire quelques aménagements pour que ça compile sur les
systèmes qui utilisent glibc. Est ce qu'il y a des pages de manuel
'portables' (au moins sur un maximum d'UNIX) disponibles en ligne ?
Normalement tout code se conforment à Single Unix Specification
<http://www.unix.org/single_unix_specification/> devrait compiler sur un
système UNIX. Note que beaucoup moins de fonctions existent que sur ton
système.
Un exemple frappant c'est la struct dirent de dirent.h. Dans la libc BSD
il y a l'enum d_type qui peut prendre les valeurs DT_DIR etc. Mais avec
la glibc, pour que cette enumération soit correctement déclarée il faut
un #define _BSD_SOURCE. J'ai finalement utilisé stat(2) pour que ce soit
portable sans definir _BSD_SOURCE (car j'ignore la portée que cette
macro a sur le code).
POSIX se moque de d_type :
<http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html>
Dans la page de manuel de readdir(3) sous Linux :
| Other than Linux, the d_type field is available mainly only on BSD
| systems. This field makes it possible to avoid the expense of calling
| lstat(2) if further actions depend on the type of the file. If the
| _BSD_SOURCE feature test macro is defined, then glibc defines the fol‐
| lowing macro constants for the value returned in d_type:
|
| DT_BLK This is a block device.
| DT_CHR This is a character device.
| DT_DIR This is a directory.
| DT_FIFO This is a named pipe (FIFO).
| DT_LNK This is a symbolic link.
| DT_REG This is a regular file.
| DT_SOCK This is a Unix domain socket.
| DT_UNKNOWN The file type is unknown.
voir aussi
<http://www.kernel.org/doc/man-pages/online/pages/man7/feature_test_macros.7.html>
Après, il y a certaine fonctions que tu trouveras sur un système et que
tu ne trouveras pas sur un autre même avec _BSD_SOURCE (au hasard
strlcpy ;-)).
le 14/10/2009 à 13:09, Ksh J. Fry a écrit dans le message <4ad5b1d6$0$25285$ :
À quoi servent exactement les macros _GNU_SOURCE, _BSD_SOURCE etc ? J'ai vu que pour déclarer certaines fonctions ou certains comportements il fallait les définir (à priori seulement si on utilise la libc de GNU).
Ce groupe n'est pas le plus adapté pour ce genre de question car il traite de la norme AINSI C comme définit par les standards C89 (ANSI X3.159-1989) ou C99 (ISO/IEC 9899:1999). GNU ou BSD étant plus large, le groupe le plus adapté pour en parler est plutôt fr.comp.os.unix.
- Est ce pour des questions de retro compatibilités ?
Non. Disons plutôt que ce sont des extensions au standard POSIX (IEEE Std 1003.1) ou à la norme C (POSIX étant déjà une extension à C).
- Quel impact ont ils sur le code en général (quelles fonctions sont concernés et pourquoi) ?
C'est assez vaste. Définir ces macros peut t'apporter des fonctions ou des type supplémentaires ou encore modifier le comportement d'une fonction. Pourquoi ? Parce que chacun a une vision différente de ce qui doit être fait.
- Comment bien s'en servir ?
#define _GNU_SOURCE #include <unistd.h> ret = setresuid(ruid, euid, suid);
Sans le #define _GNU_SOURCE, la fonction setresuid n'existe pas (sur mon sytème, sur d'autre, avec ou sans elle n'existera pas).
En fait je code sur FreeBSD (avec la libc BSD donc) et ma documentation sont les pages de manuel de FreeBSD. Le problème c'est que là dedans il n'est nullement question de _GNU_SOURCE _BSD_SOURCE etc... Et bien souvent il faut faire quelques aménagements pour que ça compile sur les systèmes qui utilisent glibc. Est ce qu'il y a des pages de manuel 'portables' (au moins sur un maximum d'UNIX) disponibles en ligne ?
Normalement tout code se conforment à Single Unix Specification <http://www.unix.org/single_unix_specification/> devrait compiler sur un système UNIX. Note que beaucoup moins de fonctions existent que sur ton système.
Un exemple frappant c'est la struct dirent de dirent.h. Dans la libc BSD il y a l'enum d_type qui peut prendre les valeurs DT_DIR etc. Mais avec la glibc, pour que cette enumération soit correctement déclarée il faut un #define _BSD_SOURCE. J'ai finalement utilisé stat(2) pour que ce soit portable sans definir _BSD_SOURCE (car j'ignore la portée que cette macro a sur le code).
POSIX se moque de d_type : <http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html>
Dans la page de manuel de readdir(3) sous Linux :
| Other than Linux, the d_type field is available mainly only on BSD | systems. This field makes it possible to avoid the expense of calling | lstat(2) if further actions depend on the type of the file. If the | _BSD_SOURCE feature test macro is defined, then glibc defines the fol‐ | lowing macro constants for the value returned in d_type: | | DT_BLK This is a block device. | DT_CHR This is a character device. | DT_DIR This is a directory. | DT_FIFO This is a named pipe (FIFO). | DT_LNK This is a symbolic link. | DT_REG This is a regular file. | DT_SOCK This is a Unix domain socket. | DT_UNKNOWN The file type is unknown.
voir aussi <http://www.kernel.org/doc/man-pages/online/pages/man7/feature_test_macros.7.html>
Après, il y a certaine fonctions que tu trouveras sur un système et que tu ne trouveras pas sur un autre même avec _BSD_SOURCE (au hasard strlcpy ;-)).
J'etais a Budapest a faire du OpenBSD toute la semaine. Je lirai plus en detail ta reponse, et verrait si j'ai des details a apporter, depuis mes tranchees... ;-)
In article <hb6pnv$ssg$1@news.cict.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
J'etais a Budapest a faire du OpenBSD toute la semaine. Je lirai plus
en detail ta reponse, et verrait si j'ai des details a apporter, depuis
mes tranchees... ;-)
J'etais a Budapest a faire du OpenBSD toute la semaine. Je lirai plus en detail ta reponse, et verrait si j'ai des details a apporter, depuis mes tranchees... ;-)
Ksh J. Fry
Je crois avoir compris le truc, je vais lire attentivement les pages de man de la spécification UNIX en cas de doute pour que le code soit portable.
Merci pour tous vos éclaircissements (surtout le lien vers opengroup.org qui occupe maintenant une grosse part de ma documentation C :-))
Je crois avoir compris le truc, je vais lire attentivement les pages de
man de la spécification UNIX en cas de doute pour que le code soit portable.
Merci pour tous vos éclaircissements (surtout le lien vers opengroup.org
qui occupe maintenant une grosse part de ma documentation C :-))
