Compatibilités glibc et autres libc

Le
Ksh J. Fry
Bonjour,

À 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).

Merci d'avance pour vos éclaircissements.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Marc Boyer
Le #20353851
Le 14-10-2009, Ksh J. Fry
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
Benoit Izac
Le #20357831
Bonjour,

le 14/10/2009 à 13:09, Ksh J. Fry a écrit dans le message

À 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 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
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 :

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

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
espie
Le #20363831
In article Marc Boyer
Le 14-10-2009, Ksh J. Fry
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.



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
Le #20365131
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 :-))
Publicité
Poster une réponse
Anonyme