gcc : priorité de recherche des methodes dans le système de fichier
21 réponses
the.chojin
Bonjour,
j'ai une methode kill qui rentre en conflit avec celle de signal.h, et
j'aimerais savoir s'il y avait une option dans gcc (je n'en doute pas) pour
lui indiquer de chercher dabort les methodes dans ./ ?
Et quelle est exactement l'intérêt de cette remarque ?
J'aime bien te chambrer, peux pas m'empêcher...
-- http://harpo.free.fr/
the.chojin
Bonsoir,
merci de votre réponse, ca marche parfaitement. C'est intéressant comme solution, merci beaucoup.
"Targeur fou" a écrit dans le message de news:
the.chojin wrote:
Bonjour,
Bonjour,
j'ai une methode kill qui rentre en conflit avec celle de signal.h, et j'aimerais savoir s'il y avait une option dans gcc (je n'en doute pas) pour
lui indiquer de chercher dabort les methodes dans ./ ?
kill() n'est pas une fonction de la bibliothèque standard C. Aussi, si vous utilisez des options de gcc précisant une compilation conforme à un standard C (C90 ou C99), vous ne devriez normalement pas à avoir ce problème. J'e n'ai pas cygwin chez moi mais gcc d'Interix (Windows Services for Unix) et j'ai constaté dans l'en-tête signal.h qu'il n'y avait pas de contrôles de fait par rapport à la macro __STDC__ , i.e. quasiment toutes les déclarations de fonctions, même non-standard sont visibles même avec les flags gcc adéquats (flags utilisés : -stdÈ9 -pedantic -Wall), et ça râle aussi si on déclare une fonction kill. C'est AMA une erreur qui peut être également présente avec Cygwin.
Une solution est de définir une macro kill pour écraser l'ancien nom avec le nom d'une autre fonction, si toutefois on veut utiliser le nom kill :
#include <stdio.h> #include <signal.h>
/* decl fonction de déguisement */ /* ou plutôt usurpateur d'identité */ int myKill(int n);
/* On déguise kill(), il va au bal costumé aujourd'hui */ #define kill(a) myKill ( (a) )
/* implem. fonction de deguisement */ int myKill(int n); { puts("Je suis kill(), en fait myKill() de mon vrai nom"); puts("Je ne suis pas mechant, je ne ferais rien à n"); return n; }
int main(void) { (void)kill(2); return 0; }
A+ Regis
Bonsoir,
merci de votre réponse, ca marche parfaitement.
C'est intéressant comme solution, merci beaucoup.
"Targeur fou" <rtroadec@yahoo.fr> a écrit dans le message de news:
1137513885.292587.135210@f14g2000cwb.googlegroups.com...
the.chojin wrote:
Bonjour,
Bonjour,
j'ai une methode kill qui rentre en conflit avec celle de signal.h, et
j'aimerais savoir s'il y avait une option dans gcc (je n'en doute pas)
pour
lui indiquer de chercher dabort les methodes dans ./ ?
kill() n'est pas une fonction de la bibliothèque standard C. Aussi, si
vous utilisez des options de gcc précisant une compilation conforme à
un standard C (C90 ou C99), vous ne devriez normalement pas à avoir ce
problème. J'e n'ai pas cygwin chez moi mais gcc d'Interix (Windows
Services for Unix) et j'ai constaté dans l'en-tête signal.h qu'il n'y
avait pas de contrôles de fait par rapport à la macro __STDC__ , i.e.
quasiment toutes les déclarations de fonctions, même non-standard
sont visibles même avec les flags gcc adéquats (flags utilisés :
-stdÈ9 -pedantic -Wall), et ça râle aussi si on déclare une
fonction kill.
C'est AMA une erreur qui peut être également présente avec Cygwin.
Une solution est de définir une macro kill pour écraser l'ancien nom
avec le nom d'une autre fonction, si toutefois on veut utiliser le nom
kill :
#include <stdio.h>
#include <signal.h>
/* decl fonction de déguisement */
/* ou plutôt usurpateur d'identité */
int myKill(int n);
/* On déguise kill(), il va au bal costumé aujourd'hui */
#define kill(a) myKill ( (a) )
/* implem. fonction de deguisement */
int myKill(int n);
{
puts("Je suis kill(), en fait myKill() de mon vrai nom");
puts("Je ne suis pas mechant, je ne ferais rien à n");
return n;
}
merci de votre réponse, ca marche parfaitement. C'est intéressant comme solution, merci beaucoup.
"Targeur fou" a écrit dans le message de news:
the.chojin wrote:
Bonjour,
Bonjour,
j'ai une methode kill qui rentre en conflit avec celle de signal.h, et j'aimerais savoir s'il y avait une option dans gcc (je n'en doute pas) pour
lui indiquer de chercher dabort les methodes dans ./ ?
kill() n'est pas une fonction de la bibliothèque standard C. Aussi, si vous utilisez des options de gcc précisant une compilation conforme à un standard C (C90 ou C99), vous ne devriez normalement pas à avoir ce problème. J'e n'ai pas cygwin chez moi mais gcc d'Interix (Windows Services for Unix) et j'ai constaté dans l'en-tête signal.h qu'il n'y avait pas de contrôles de fait par rapport à la macro __STDC__ , i.e. quasiment toutes les déclarations de fonctions, même non-standard sont visibles même avec les flags gcc adéquats (flags utilisés : -stdÈ9 -pedantic -Wall), et ça râle aussi si on déclare une fonction kill. C'est AMA une erreur qui peut être également présente avec Cygwin.
Une solution est de définir une macro kill pour écraser l'ancien nom avec le nom d'une autre fonction, si toutefois on veut utiliser le nom kill :
#include <stdio.h> #include <signal.h>
/* decl fonction de déguisement */ /* ou plutôt usurpateur d'identité */ int myKill(int n);
/* On déguise kill(), il va au bal costumé aujourd'hui */ #define kill(a) myKill ( (a) )
/* implem. fonction de deguisement */ int myKill(int n); { puts("Je suis kill(), en fait myKill() de mon vrai nom"); puts("Je ne suis pas mechant, je ne ferais rien à n"); return n; }
int main(void) { (void)kill(2); return 0; }
A+ Regis
Harpo
Targeur fou wrote:
#include <signal.h>
/* decl fonction de déguisement */ /* ou plutôt usurpateur d'identité */ int myKill(int n);
/* On déguise kill(), il va au bal costumé aujourd'hui */ #define kill(a) myKill ( (a) )
Cela oblige à modifier le source, voire les sources si l'ainsi renommée myKill n'est pas static.
-- http://harpo.free.fr/
Targeur fou wrote:
#include <signal.h>
/* decl fonction de déguisement */
/* ou plutôt usurpateur d'identité */
int myKill(int n);
/* On déguise kill(), il va au bal costumé aujourd'hui */
#define kill(a) myKill ( (a) )
Cela oblige à modifier le source, voire les sources si l'ainsi renommée
myKill n'est pas static.
/* decl fonction de déguisement */ /* ou plutôt usurpateur d'identité */ int myKill(int n);
/* On déguise kill(), il va au bal costumé aujourd'hui */ #define kill(a) myKill ( (a) )
Cela oblige à modifier le source, voire les sources si l'ainsi renommée myKill n'est pas static.
-- http://harpo.free.fr/
the.chojin
Pourquoi modifier plusieurs sources ? Suffit de le renomer la declaration et l'implémentation et declarer le #define a ce niveau (même visibilité). Mais c'est vrai que ca a le désavantage de modifier les sources, je vais essayé de trouver une solution plus propre ... (enfin j'ai mon logiciel qui marche maintenant ^^)
Merci.
"Harpo" a écrit dans le message de news: 43cd6ade$0$20152$
Targeur fou wrote:
#include <signal.h>
/* decl fonction de déguisement */ /* ou plutôt usurpateur d'identité */ int myKill(int n);
/* On déguise kill(), il va au bal costumé aujourd'hui */ #define kill(a) myKill ( (a) )
Cela oblige à modifier le source, voire les sources si l'ainsi renommée myKill n'est pas static.
-- http://harpo.free.fr/
Pourquoi modifier plusieurs sources ?
Suffit de le renomer la declaration et l'implémentation et declarer le
#define a ce niveau (même visibilité).
Mais c'est vrai que ca a le désavantage de modifier les sources, je vais
essayé de trouver une solution plus propre ... (enfin j'ai mon logiciel qui
marche maintenant ^^)
Merci.
"Harpo" <trashcan@hotmail.com> a écrit dans le message de news:
43cd6ade$0$20152$8fcfb975@news.wanadoo.fr...
Targeur fou wrote:
#include <signal.h>
/* decl fonction de déguisement */
/* ou plutôt usurpateur d'identité */
int myKill(int n);
/* On déguise kill(), il va au bal costumé aujourd'hui */
#define kill(a) myKill ( (a) )
Cela oblige à modifier le source, voire les sources si l'ainsi renommée
myKill n'est pas static.
Pourquoi modifier plusieurs sources ? Suffit de le renomer la declaration et l'implémentation et declarer le #define a ce niveau (même visibilité). Mais c'est vrai que ca a le désavantage de modifier les sources, je vais essayé de trouver une solution plus propre ... (enfin j'ai mon logiciel qui marche maintenant ^^)
Merci.
"Harpo" a écrit dans le message de news: 43cd6ade$0$20152$
Targeur fou wrote:
#include <signal.h>
/* decl fonction de déguisement */ /* ou plutôt usurpateur d'identité */ int myKill(int n);
/* On déguise kill(), il va au bal costumé aujourd'hui */ #define kill(a) myKill ( (a) )
Cela oblige à modifier le source, voire les sources si l'ainsi renommée myKill n'est pas static.
-- http://harpo.free.fr/
Harpo
the.chojin wrote:
Pourquoi modifier plusieurs sources ?
Si la fonction n'est pas déclarée comme static, elle peut être utilisée par plusieurs sources (s'il y en a plusieurs dans l'appli), ce qui fait que d'éventuels sources croyant appeler la fonction qui est maintenant myKill pourraient appeler la fonction kill de la libc, surtout si elle a la même signature.
Suffit de le renomer la declaration et l'implémentation et declarer le #define a ce niveau (même visibilité).
Si on met le #define, je ne vois pas l'intérêt de modifier la déclaration et l'implémentation si elles se trouvent après le #define.
Mais c'est vrai que ca a le désavantage de modifier les sources, je vais essayé de trouver une solution plus propre ... (enfin j'ai mon logiciel qui marche maintenant ^^)
Si ça marche, il n'y a a priori pas de problème, le hack est bon si la fonction n'est pas utilisée dans un autre source, ce qui est probablement le cas. Je regarderais quand même ce que fait la fonction kill maintenant myKill et je ferais un grep sur tous les sources de l'appli pour voir si elle n'est pas référencée ailleurs. Si il faut garder cette fonction, je la renommerais plutôt par myKill dans tous le source, des fois qu'on aie ensuite envie d'appeler la 'vraie' fonction kill dans le programme.
-- http://harpo.free.fr/
the.chojin wrote:
Pourquoi modifier plusieurs sources ?
Si la fonction n'est pas déclarée comme static, elle peut être utilisée
par plusieurs sources (s'il y en a plusieurs dans l'appli), ce qui fait
que d'éventuels sources croyant appeler la fonction qui est maintenant
myKill pourraient appeler la fonction kill de la libc, surtout si elle
a la même signature.
Suffit de le renomer la declaration et l'implémentation et declarer le
#define a ce niveau (même visibilité).
Si on met le #define, je ne vois pas l'intérêt de modifier la
déclaration et l'implémentation si elles se trouvent après le #define.
Mais c'est vrai que ca a le désavantage de modifier les sources, je
vais essayé de trouver une solution plus propre ... (enfin j'ai mon
logiciel qui marche maintenant ^^)
Si ça marche, il n'y a a priori pas de problème, le hack est bon si la
fonction n'est pas utilisée dans un autre source, ce qui est
probablement le cas.
Je regarderais quand même ce que fait la fonction kill maintenant myKill
et je ferais un grep sur tous les sources de l'appli pour voir si elle
n'est pas référencée ailleurs.
Si il faut garder cette fonction, je la renommerais plutôt par myKill
dans tous le source, des fois qu'on aie ensuite envie d'appeler la
'vraie' fonction kill dans le programme.
Si la fonction n'est pas déclarée comme static, elle peut être utilisée par plusieurs sources (s'il y en a plusieurs dans l'appli), ce qui fait que d'éventuels sources croyant appeler la fonction qui est maintenant myKill pourraient appeler la fonction kill de la libc, surtout si elle a la même signature.
Suffit de le renomer la declaration et l'implémentation et declarer le #define a ce niveau (même visibilité).
Si on met le #define, je ne vois pas l'intérêt de modifier la déclaration et l'implémentation si elles se trouvent après le #define.
Mais c'est vrai que ca a le désavantage de modifier les sources, je vais essayé de trouver une solution plus propre ... (enfin j'ai mon logiciel qui marche maintenant ^^)
Si ça marche, il n'y a a priori pas de problème, le hack est bon si la fonction n'est pas utilisée dans un autre source, ce qui est probablement le cas. Je regarderais quand même ce que fait la fonction kill maintenant myKill et je ferais un grep sur tous les sources de l'appli pour voir si elle n'est pas référencée ailleurs. Si il faut garder cette fonction, je la renommerais plutôt par myKill dans tous le source, des fois qu'on aie ensuite envie d'appeler la 'vraie' fonction kill dans le programme.
-- http://harpo.free.fr/
Antoine Leca
In news:43cc0798$0$25637$, the.chojin va escriure:
j'ai une methode kill qui rentre en conflit avec celle de signal.h, et j'aimerais savoir s'il y avait une option dans gcc (je n'en doute pas) pour lui indiquer de chercher dabort les methodes dans ./ ?
gcc -ansi ?
Si cela trouve encore le kill() de <signal.h>, faire un rapport de bogue chez le fournisseur de ce <signal.h>.
Antoine
In news:43cc0798$0$25637$636a55ce@news.free.fr,
the.chojin va escriure:
j'ai une methode kill qui rentre en conflit avec celle de signal.h, et
j'aimerais savoir s'il y avait une option dans gcc (je n'en doute
pas) pour lui indiquer de chercher dabort les methodes dans ./ ?
gcc -ansi ?
Si cela trouve encore le kill() de <signal.h>, faire un rapport de bogue
chez le fournisseur de ce <signal.h>.
In news:43cc0798$0$25637$, the.chojin va escriure:
j'ai une methode kill qui rentre en conflit avec celle de signal.h, et j'aimerais savoir s'il y avait une option dans gcc (je n'en doute pas) pour lui indiquer de chercher dabort les methodes dans ./ ?
gcc -ansi ?
Si cela trouve encore le kill() de <signal.h>, faire un rapport de bogue chez le fournisseur de ce <signal.h>.
Antoine
Antoine Leca
En news:43cc0cc6$0$11414$, Emmanuel Delahaye va escriure:
Changer de nom. Utiliser un nom utilisé par l'implémentation invoque un comportement indéfini.
Ne devrait pas, à moins que le nom ne soit réservé. Il y a bien des règles sur les noms réservés ; mais ces règles ne concernent kill(2) _que_ si tu programmes avec _POSIX_C_SOURCE_.
Antoine
En news:43cc0cc6$0$11414$79c14f64@nan-newsreader-05.noos.net,
Emmanuel Delahaye va escriure:
Changer de nom. Utiliser un nom utilisé par l'implémentation invoque
un comportement indéfini.
Ne devrait pas, à moins que le nom ne soit réservé.
Il y a bien des règles sur les noms réservés ; mais ces règles ne concernent
kill(2) _que_ si tu programmes avec _POSIX_C_SOURCE_.
En news:43cc0cc6$0$11414$, Emmanuel Delahaye va escriure:
Changer de nom. Utiliser un nom utilisé par l'implémentation invoque un comportement indéfini.
Ne devrait pas, à moins que le nom ne soit réservé. Il y a bien des règles sur les noms réservés ; mais ces règles ne concernent kill(2) _que_ si tu programmes avec _POSIX_C_SOURCE_.
Antoine
Vincent Lefevre
Dans l'article <dr27ho$i4q$, Antoine Leca écrit:
gcc -ansi ?
Ça ne sélectionne que l'ancienne norme C. "gcc -stdÉ9" ou directement "c99" pour la norme ISO C99.
