POSIX_SOURCE 1 et _XOPEN_SOURCE 600 incompatibles ?
Le
PIGUET Bruno
Bonjour,
Je suis en train d'essayer de compiler du code existant avec gcc 4.4.3,
et je tombe sur un problème dans signals.h.
Avec un code minimal (joint en ps), j'ai le message :
/usr/include/signal.h:155: erreur: expected ‘;’, ‘,’ or ‘)’ before ‘*’
token"
Dès que je supprime l'un des deux #define, le message d'erreur disparaît.
Un peu de recherche web m'a appris que je n'étais pas le seul à avoir ce
problème. Une des solutions suggérées est de modifier la définition POSIX
en :
#define _POSIX_C_SOURCE 200809
S'il y a dans l'auditoire de grands connaisseurs des normes, je serai
heureux d'avoir leur avis.
POSIX_1 et XOPEN 600 sont-il incompatibles par définition ? auquel
cas, mon code est bugué. Ou alors, doit-je faire un bug-report auprès des
auteurs de libc ?
Merci d'avance
Bruno.
PS : l'ECM :
#define _POSIX_SOURCE 1
#define _XOPEN_SOURCE 600
#include <signal.h>
int
main ()
{
return 5;
}
Je suis en train d'essayer de compiler du code existant avec gcc 4.4.3,
et je tombe sur un problème dans signals.h.
Avec un code minimal (joint en ps), j'ai le message :
/usr/include/signal.h:155: erreur: expected ‘;’, ‘,’ or ‘)’ before ‘*’
token"
Dès que je supprime l'un des deux #define, le message d'erreur disparaît.
Un peu de recherche web m'a appris que je n'étais pas le seul à avoir ce
problème. Une des solutions suggérées est de modifier la définition POSIX
en :
#define _POSIX_C_SOURCE 200809
S'il y a dans l'auditoire de grands connaisseurs des normes, je serai
heureux d'avoir leur avis.
POSIX_1 et XOPEN 600 sont-il incompatibles par définition ? auquel
cas, mon code est bugué. Ou alors, doit-je faire un bug-report auprès des
auteurs de libc ?
Merci d'avance
Bruno.
PS : l'ECM :
#define _POSIX_SOURCE 1
#define _XOPEN_SOURCE 600
#include <signal.h>
int
main ()
{
return 5;
}

Poser une question


Bruno PIGUET écrivit dans
<couic>
Cela ne me paraît pas anormal. Chacune des deux définitions indique
l'adhésion à _une_ norme, et ce sont deux normes différentes, en
l'occurence Posix.1 (ISO/CÉI 9945-1:1996) pour la première et X/Open v.6
(alias SUS v3, extension définie par ISO/CÉI 9945-1:2001) pour la seconde.
Il faudrait donc que tu décides quelle est la norme que tu veux suivre,
et t'y tenir. Si tu ne sais pas te décider, et si tu as copié ces
#define à partir de deux sources différentes, il faudra que tu utilises
la seconde, car c'est supposé être un sur-ensemble de la première, de la
même manière que toutes ces normes sont des sur-ensembles de la norme C:
c'est d'ailleurs pour indiquer que tu souhaites utiliser une autre norme
que la norme C (ISO/CÉI 9899), que tu vas utiliser ces #define...
Autrement dit, adhérer à une /troisième/ norme ;-), en l'occurence
ISO/CÉI 9945-1:2008 (la « petite sœur » de X/Open v.7) : si cela marche
pour ton code, cela voudra dire que tu n'as pas besoin des extensions
X/Open et que tu peux rester au niveau Posix (compatible avec plus de
systèmes ouverts).
En fait, il y a un groupe de discussion /beaucoup/ plus connaisseur de
ce sujet, et je redirige vers eux.
Pas vraiment incompatibles, mais surtout différents.
Ce n'est probablement pas la peine, tu risques de te faire fusiller...
Antoine
En fait, c'est ce que j'ai déjà fait.
C'est du code qui était originellement POSIX_1. Il y a quelque temps,
pour pouvoir utiliser la fonction isfinite() (de math.h) sans passer
complètement et explicitement à C99, j'avais rajouté _XOPEN_SOURCE 600
Je n'avais pas vu le problème avec la double déclaration.
Mais dès qu'il a fallu faire un choix, il a été clair.
Je m'en doutais bien, c'est pour ça que j'ai préféré venir papoter ici.
Il y a quand même un comportement qui me chagrine :
- Soit XOPEN_600 est un sur-ensemble de POSIX_1, et une double
définition ne devrait pas être gênante.
- Soit les deux définitions sont exclusives, et alors je préférerais
que le compilateur donne un message du genre "Choisis ton camp, camarade"
plutôt que : expected ‘;’, ‘,’ or ‘)’ before ‘*’ token (Ceci dit, on
fait du C, hein, on sait bien que les messages du compilateur ne seront
jamais de très haut niveau).
Bruno.