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 ./ ?
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 ./ ?
Si tu appellais ta m^H fonction xKill ?
-- http://harpo.free.fr/
the.chojin wrote:
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 ./ ?
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 ./ ?
Si tu appellais ta m^H fonction xKill ?
-- http://harpo.free.fr/
the.chojin
J'y ai bien pensé, mais c'est dans le cadre de la compilation sous cygwin d'une application que je n'ai pas réalisé, j'imagine que le reste du code contient d'autres pépins du même genre, je préfére résoudre le problème à la racine. Merci.
"Harpo" a écrit dans le message de news: 43cc0862$0$29216$
the.chojin wrote:
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 ./ ?
Si tu appellais ta m^H fonction xKill ?
-- http://harpo.free.fr/
J'y ai bien pensé, mais c'est dans le cadre de la compilation sous cygwin
d'une application que je n'ai pas réalisé, j'imagine que le reste du code
contient d'autres pépins du même genre, je préfére résoudre le problème à la
racine.
Merci.
"Harpo" <trashcan@hotmail.com> a écrit dans le message de news:
43cc0862$0$29216$8fcfb975@news.wanadoo.fr...
the.chojin wrote:
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 ./ ?
J'y ai bien pensé, mais c'est dans le cadre de la compilation sous cygwin d'une application que je n'ai pas réalisé, j'imagine que le reste du code contient d'autres pépins du même genre, je préfére résoudre le problème à la racine. Merci.
"Harpo" a écrit dans le message de news: 43cc0862$0$29216$
the.chojin wrote:
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 ./ ?
Si tu appellais ta m^H fonction xKill ?
-- http://harpo.free.fr/
Emmanuel Delahaye
j'ai une methode
? Pas de /méthodes/ en C. Des fonctions, des macros...
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 ./ ?
Changer de nom. Utiliser un nom utilisé par l'implémentation invoque un comportement indéfini.
-- A+
Emmanuel Delahaye
j'ai une methode
? Pas de /méthodes/ en C. Des fonctions, des macros...
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 ./ ?
Changer de nom. Utiliser un nom utilisé par l'implémentation invoque un
comportement indéfini.
? Pas de /méthodes/ en C. Des fonctions, des macros...
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 ./ ?
Changer de nom. Utiliser un nom utilisé par l'implémentation invoque un comportement indéfini.
-- A+
Emmanuel Delahaye
Harpo
the.chojin wrote:
J'y ai bien pensé, mais c'est dans le cadre de la compilation sous cygwin d'une application que je n'ai pas réalisé, j'imagine que le reste du code contient d'autres pépins du même genre, je préfére résoudre le problème à la racine.
Parfois, il ne faut pas hésiter à taillader dans le code mais bon. Je ne connais pas windows, il faut plutôt voir du coté des options du linker et/ou des variables d'environement pour qu'une bibliothèque soit prise avant une autre. Pour le linker, voir le manuel, 'man ld', peut-être l'option --library-path Sous un Unix, on peut jouer avec la variable d'environement LD_LIBRARY_PATH au moment de l'exécution, mais je ne suis pas certain que ce soit une bonne idée du point de vue de la sécurité de se fier à une variable d'environement.
Une chose est certaine, le rapport avec le langage C est ténu.
the.chojin wrote:
J'y ai bien pensé, mais c'est dans le cadre de la compilation sous
cygwin d'une application que je n'ai pas réalisé, j'imagine que le
reste du code contient d'autres pépins du même genre, je préfére
résoudre le problème à la racine.
Parfois, il ne faut pas hésiter à taillader dans le code mais bon.
Je ne connais pas windows, il faut plutôt voir du coté des options du
linker et/ou des variables d'environement pour qu'une bibliothèque soit
prise avant une autre.
Pour le linker, voir le manuel, 'man ld', peut-être l'option
--library-path
Sous un Unix, on peut jouer avec la variable d'environement
LD_LIBRARY_PATH au moment de l'exécution, mais je ne suis pas certain
que ce soit une bonne idée du point de vue de la sécurité de se fier à
une variable d'environement.
Une chose est certaine, le rapport avec le langage C est ténu.
J'y ai bien pensé, mais c'est dans le cadre de la compilation sous cygwin d'une application que je n'ai pas réalisé, j'imagine que le reste du code contient d'autres pépins du même genre, je préfére résoudre le problème à la racine.
Parfois, il ne faut pas hésiter à taillader dans le code mais bon. Je ne connais pas windows, il faut plutôt voir du coté des options du linker et/ou des variables d'environement pour qu'une bibliothèque soit prise avant une autre. Pour le linker, voir le manuel, 'man ld', peut-être l'option --library-path Sous un Unix, on peut jouer avec la variable d'environement LD_LIBRARY_PATH au moment de l'exécution, mais je ne suis pas certain que ce soit une bonne idée du point de vue de la sécurité de se fier à une variable d'environement.
Une chose est certaine, le rapport avec le langage C est ténu.
Harpo
Emmanuel Delahaye wrote:
j'ai une methode
? Pas de /méthodes/ en C. Des fonctions, des macros...
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 ./ ?
Changer de nom. Utiliser un nom utilisé par l'implémentation invoque un comportement indéfini.
Je suis certain, Emm, que si on te remplaçait par un automate, je veux dire une FSM, tes réactions seraient tellement aussi déterminées que personne ne se rendrait compte de la substitution.
-- http://harpo.free.fr/
Emmanuel Delahaye wrote:
j'ai une methode
? Pas de /méthodes/ en C. Des fonctions, des macros...
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 ./ ?
Changer de nom. Utiliser un nom utilisé par l'implémentation invoque
un comportement indéfini.
Je suis certain, Emm, que si on te remplaçait par un automate, je veux
dire une FSM, tes réactions seraient tellement aussi déterminées que
personne ne se rendrait compte de la substitution.
? Pas de /méthodes/ en C. Des fonctions, des macros...
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 ./ ?
Changer de nom. Utiliser un nom utilisé par l'implémentation invoque un comportement indéfini.
Je suis certain, Emm, que si on te remplaçait par un automate, je veux dire une FSM, tes réactions seraient tellement aussi déterminées que personne ne se rendrait compte de la substitution.
-- http://harpo.free.fr/
the.chojin
"Harpo" a écrit dans le message de news: 43cc15df$0$29200$
the.chojin wrote:
J'y ai bien pensé, mais c'est dans le cadre de la compilation sous cygwin d'une application que je n'ai pas réalisé, j'imagine que le reste du code contient d'autres pépins du même genre, je préfére résoudre le problème à la racine.
Parfois, il ne faut pas hésiter à taillader dans le code mais bon. Je ne connais pas windows, il faut plutôt voir du coté des options du linker et/ou des variables d'environement pour qu'une bibliothèque soit prise avant une autre.
L'erreur a lieu au niveau de la compilation.
Pour le linker, voir le manuel, 'man ld', peut-être l'option --library-path Sous un Unix, on peut jouer avec la variable d'environement LD_LIBRARY_PATH au moment de l'exécution, mais je ne suis pas certain que ce soit une bonne idée du point de vue de la sécurité de se fier à une variable d'environement.
Une chose est certaine, le rapport avec le langage C est ténu.
A bien y reflechir ce n'est pas faux, suis je complétement hors sujet ?
"Harpo" <trashcan@hotmail.com> a écrit dans le message de news:
43cc15df$0$29200$8fcfb975@news.wanadoo.fr...
the.chojin wrote:
J'y ai bien pensé, mais c'est dans le cadre de la compilation sous
cygwin d'une application que je n'ai pas réalisé, j'imagine que le
reste du code contient d'autres pépins du même genre, je préfére
résoudre le problème à la racine.
Parfois, il ne faut pas hésiter à taillader dans le code mais bon.
Je ne connais pas windows, il faut plutôt voir du coté des options du
linker et/ou des variables d'environement pour qu'une bibliothèque soit
prise avant une autre.
L'erreur a lieu au niveau de la compilation.
Pour le linker, voir le manuel, 'man ld', peut-être l'option
--library-path
Sous un Unix, on peut jouer avec la variable d'environement
LD_LIBRARY_PATH au moment de l'exécution, mais je ne suis pas certain
que ce soit une bonne idée du point de vue de la sécurité de se fier à
une variable d'environement.
Une chose est certaine, le rapport avec le langage C est ténu.
A bien y reflechir ce n'est pas faux, suis je complétement hors sujet ?
"Harpo" a écrit dans le message de news: 43cc15df$0$29200$
the.chojin wrote:
J'y ai bien pensé, mais c'est dans le cadre de la compilation sous cygwin d'une application que je n'ai pas réalisé, j'imagine que le reste du code contient d'autres pépins du même genre, je préfére résoudre le problème à la racine.
Parfois, il ne faut pas hésiter à taillader dans le code mais bon. Je ne connais pas windows, il faut plutôt voir du coté des options du linker et/ou des variables d'environement pour qu'une bibliothèque soit prise avant une autre.
L'erreur a lieu au niveau de la compilation.
Pour le linker, voir le manuel, 'man ld', peut-être l'option --library-path Sous un Unix, on peut jouer avec la variable d'environement LD_LIBRARY_PATH au moment de l'exécution, mais je ne suis pas certain que ce soit une bonne idée du point de vue de la sécurité de se fier à une variable d'environement.
Une chose est certaine, le rapport avec le langage C est ténu.
A bien y reflechir ce n'est pas faux, suis je complétement hors sujet ?
Harpo
the.chojin wrote:
Parfois, il ne faut pas hésiter à taillader dans le code mais bon. Je ne connais pas windows, il faut plutôt voir du coté des options du linker et/ou des variables d'environement pour qu'une bibliothèque soit prise avant une autre.
L'erreur a lieu au niveau de la compilation.
OK, je ne me rappelais plus le message initial, c'est le conflit avec signal.h
C'est simple, on ne peut pas identifier plusieurs objets par un même nom dans un même name space, le compilateur ne saurait comment retrouver ses petits.
Je comprends parfaitement que tu ne veuilles pas modifier le programme, parfois il faut éviter de trop remuer la vase, parfois aussi on ne peut l'éviter sans risquer de faire des vagues.
Il faut d'abord se demander comment ce code compilait avant si <signal.h> était inclu, si c'était bien par un compilateur C, quelle version de la libc, voir le ChangeLog etc. Voir aussi ce que fait la fonction kill() de ton programme, peut-être a-t-elle été écrite pour pallier l'inexistance d'une fonction kill dans signal.h et cette fonction kill aurait maintenant été implémentée dans signal.h (??).
En gros, je ne vois pas comment éviter de toucher au source, soit tu renommes la fonction kill, soit tu l'enlèves ce qui est le meilleur si elle a la même utilisation que la fonction kill de signal.h.
Une chose est certaine, le rapport avec le langage C est ténu.
A bien y reflechir ce n'est pas faux, suis je complétement hors sujet ?
Non, pas du tout, je me suis mépris, j'avais pensé que c'était une erreur au link.
-- http://harpo.free.fr/
the.chojin wrote:
Parfois, il ne faut pas hésiter à taillader dans le code mais bon.
Je ne connais pas windows, il faut plutôt voir du coté des options du
linker et/ou des variables d'environement pour qu'une bibliothèque
soit prise avant une autre.
L'erreur a lieu au niveau de la compilation.
OK, je ne me rappelais plus le message initial, c'est le conflit avec
signal.h
C'est simple, on ne peut pas identifier plusieurs objets par un même nom
dans un même name space, le compilateur ne saurait comment retrouver
ses petits.
Je comprends parfaitement que tu ne veuilles pas modifier le programme,
parfois il faut éviter de trop remuer la vase, parfois aussi on ne peut
l'éviter sans risquer de faire des vagues.
Il faut d'abord se demander comment ce code compilait avant si
<signal.h> était inclu, si c'était bien par un compilateur C, quelle
version de la libc, voir le ChangeLog etc.
Voir aussi ce que fait la fonction kill() de ton programme, peut-être
a-t-elle été écrite pour pallier l'inexistance d'une fonction kill dans
signal.h et cette fonction kill aurait maintenant été implémentée dans
signal.h (??).
En gros, je ne vois pas comment éviter de toucher au source, soit tu
renommes la fonction kill, soit tu l'enlèves ce qui est le meilleur si
elle a la même utilisation que la fonction kill de signal.h.
Une chose est certaine, le rapport avec le langage C est ténu.
A bien y reflechir ce n'est pas faux, suis je complétement hors sujet
?
Non, pas du tout, je me suis mépris, j'avais pensé que c'était une
erreur au link.
Parfois, il ne faut pas hésiter à taillader dans le code mais bon. Je ne connais pas windows, il faut plutôt voir du coté des options du linker et/ou des variables d'environement pour qu'une bibliothèque soit prise avant une autre.
L'erreur a lieu au niveau de la compilation.
OK, je ne me rappelais plus le message initial, c'est le conflit avec signal.h
C'est simple, on ne peut pas identifier plusieurs objets par un même nom dans un même name space, le compilateur ne saurait comment retrouver ses petits.
Je comprends parfaitement que tu ne veuilles pas modifier le programme, parfois il faut éviter de trop remuer la vase, parfois aussi on ne peut l'éviter sans risquer de faire des vagues.
Il faut d'abord se demander comment ce code compilait avant si <signal.h> était inclu, si c'était bien par un compilateur C, quelle version de la libc, voir le ChangeLog etc. Voir aussi ce que fait la fonction kill() de ton programme, peut-être a-t-elle été écrite pour pallier l'inexistance d'une fonction kill dans signal.h et cette fonction kill aurait maintenant été implémentée dans signal.h (??).
En gros, je ne vois pas comment éviter de toucher au source, soit tu renommes la fonction kill, soit tu l'enlèves ce qui est le meilleur si elle a la même utilisation que la fonction kill de signal.h.
Une chose est certaine, le rapport avec le langage C est ténu.
A bien y reflechir ce n'est pas faux, suis je complétement hors sujet ?
Non, pas du tout, je me suis mépris, j'avais pensé que c'était une erreur au link.
-- http://harpo.free.fr/
Targeur fou
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) po ur 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
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) po ur
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=c89 -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;
}
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) po ur 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
Targeur fou
Targeur fou wrote:
Correction,
/* implem. fonction de deguisement */ int myKill(int n);
int myKill(int n)
{
...
Targeur fou wrote:
Correction,
/* implem. fonction de deguisement */
int myKill(int n);
/* implem. fonction de deguisement */ int myKill(int n);
int myKill(int n)
{
...
Emmanuel Delahaye
Je suis certain, Emm, que si on te remplaçait par un automate, je veux dire une FSM, tes réactions seraient tellement aussi déterminées que personne ne se rendrait compte de la substitution.
Et quelle est exactement l'intérêt de cette remarque ? Tu veux souligner que mon raisonnement est cohérent ? C'est grave ? Je dois prendre du Tamiflu ?
-- A+
Emmanuel Delahaye
Je suis certain, Emm, que si on te remplaçait par un automate, je veux
dire une FSM, tes réactions seraient tellement aussi déterminées que
personne ne se rendrait compte de la substitution.
Et quelle est exactement l'intérêt de cette remarque ? Tu veux souligner
que mon raisonnement est cohérent ? C'est grave ? Je dois prendre du
Tamiflu ?
Je suis certain, Emm, que si on te remplaçait par un automate, je veux dire une FSM, tes réactions seraient tellement aussi déterminées que personne ne se rendrait compte de la substitution.
Et quelle est exactement l'intérêt de cette remarque ? Tu veux souligner que mon raisonnement est cohérent ? C'est grave ? Je dois prendre du Tamiflu ?
