On m'a demandé de porter du vieux code C depuis une machine HP vers du
Redhat 9. Je me trouve confronté à un étrange problème :
Dans le code (qui est en production), il y a souvent des "strcmp(<chaine>,
<null>)". Et cela fait planter mon appli : J'ai regardé dans le man du
strcmp et on ne parle pas de ce cas. Est ce un comportement normal ?
Dans le code (qui est en production), il y a souvent des "strcmp(<chaine>, <null>)". Et cela fait planter mon appli : J'ai regardé dans le man du strcmp et on ne parle pas de ce cas. Est ce un comportement normal ?
Déjà, strcmp(<chaine>, <null>), ça ne compile pas. Si tu veux dire que le premier est un char* ou const char* et que le second est 0 (ou NULL à l'ancienne), alors le plantage est normal, car je ne pense pas qu'il y ait beaucoup d'implémentations de strcmp() qui perdent du temps à vérifier la validité des pointeurs qu'on leur donne (et dans tous les cas, l'expression perd tout son sens).
-- Tek
Seb wrote:
Bonjour,
Dans le code (qui est en production), il y a souvent des "strcmp(<chaine>,
<null>)". Et cela fait planter mon appli : J'ai regardé dans le man du
strcmp et on ne parle pas de ce cas. Est ce un comportement normal ?
Déjà, strcmp(<chaine>, <null>), ça ne compile pas. Si tu veux dire que
le premier est un char* ou const char* et que le second est 0 (ou NULL à
l'ancienne), alors le plantage est normal, car je ne pense pas qu'il y
ait beaucoup d'implémentations de strcmp() qui perdent du temps à
vérifier la validité des pointeurs qu'on leur donne (et dans tous les
cas, l'expression perd tout son sens).
Dans le code (qui est en production), il y a souvent des "strcmp(<chaine>, <null>)". Et cela fait planter mon appli : J'ai regardé dans le man du strcmp et on ne parle pas de ce cas. Est ce un comportement normal ?
Déjà, strcmp(<chaine>, <null>), ça ne compile pas. Si tu veux dire que le premier est un char* ou const char* et que le second est 0 (ou NULL à l'ancienne), alors le plantage est normal, car je ne pense pas qu'il y ait beaucoup d'implémentations de strcmp() qui perdent du temps à vérifier la validité des pointeurs qu'on leur donne (et dans tous les cas, l'expression perd tout son sens).
-- Tek
Seb
"Alexandre BACQUART" a écrit dans le message news: 40b5b887$0$3204$
Seb wrote:
Bonjour,
Dans le code (qui est en production), il y a souvent des "strcmp(<chaine>, <null>)". Et cela fait planter mon appli : J'ai regardé dans le man du strcmp et on ne parle pas de ce cas. Est ce un comportement normal ?
Déjà, strcmp(<chaine>, <null>), ça ne compile pas. Si tu veux dire que le premier est un char* ou const char* et que le second est 0 (ou NULL à l'ancienne), alors le plantage est normal, car je ne pense pas qu'il y ait beaucoup d'implémentations de strcmp() qui perdent du temps à vérifier la validité des pointeurs qu'on leur donne (et dans tous les cas, l'expression perd tout son sens).
Oui tu as compris ma "syntaxe" :-)
Et bien le vieux compilateur HP semble faire le test, et malheureusement pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si vous avez une solution rapide ça m'aiderait bien
sinon, et bien j'irais à l'huile de coude ...
Sébastien
"Alexandre BACQUART" <tek512@hotmail.com> a écrit dans le message news:
40b5b887$0$3204$626a14ce@news.free.fr
Seb wrote:
Bonjour,
Dans le code (qui est en production), il y a souvent des
"strcmp(<chaine>, <null>)". Et cela fait planter mon appli : J'ai
regardé dans le man du strcmp et on ne parle pas de ce cas. Est ce
un comportement normal ?
Déjà, strcmp(<chaine>, <null>), ça ne compile pas. Si tu veux dire que
le premier est un char* ou const char* et que le second est 0 (ou
NULL à l'ancienne), alors le plantage est normal, car je ne pense pas
qu'il y ait beaucoup d'implémentations de strcmp() qui perdent du
temps à vérifier la validité des pointeurs qu'on leur donne (et dans
tous les cas, l'expression perd tout son sens).
Oui tu as compris ma "syntaxe" :-)
Et bien le vieux compilateur HP semble faire le test, et malheureusement
pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si
vous avez une solution rapide ça m'aiderait bien
"Alexandre BACQUART" a écrit dans le message news: 40b5b887$0$3204$
Seb wrote:
Bonjour,
Dans le code (qui est en production), il y a souvent des "strcmp(<chaine>, <null>)". Et cela fait planter mon appli : J'ai regardé dans le man du strcmp et on ne parle pas de ce cas. Est ce un comportement normal ?
Déjà, strcmp(<chaine>, <null>), ça ne compile pas. Si tu veux dire que le premier est un char* ou const char* et que le second est 0 (ou NULL à l'ancienne), alors le plantage est normal, car je ne pense pas qu'il y ait beaucoup d'implémentations de strcmp() qui perdent du temps à vérifier la validité des pointeurs qu'on leur donne (et dans tous les cas, l'expression perd tout son sens).
Oui tu as compris ma "syntaxe" :-)
Et bien le vieux compilateur HP semble faire le test, et malheureusement pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si vous avez une solution rapide ça m'aiderait bien
sinon, et bien j'irais à l'huile de coude ...
Sébastien
Horst Kraemer
On Thu, 27 May 2004 11:26:49 +0200, "Seb" wrote:
Bonjour,
On m'a demandé de porter du vieux code C depuis une machine HP vers du Redhat 9. Je me trouve confronté à un étrange problème :
Dans le code (qui est en production), il y a souvent des "strcmp(<chaine>, <null>)". Et cela fait planter mon appli : J'ai regardé dans le man du strcmp et on ne parle pas de ce cas. Est ce un comportement normal ?
Oui. Parfaitement normal. Le comportement d'un appel de strcmp avec un pointeur nul est indéfini. Le code n'a pas de sens.
-- Horst
On Thu, 27 May 2004 11:26:49 +0200, "Seb" <nospam@yahoo.net> wrote:
Bonjour,
On m'a demandé de porter du vieux code C depuis une machine HP vers du
Redhat 9. Je me trouve confronté à un étrange problème :
Dans le code (qui est en production), il y a souvent des "strcmp(<chaine>,
<null>)". Et cela fait planter mon appli : J'ai regardé dans le man du
strcmp et on ne parle pas de ce cas. Est ce un comportement normal ?
Oui. Parfaitement normal. Le comportement d'un appel de strcmp avec un
pointeur nul est indéfini. Le code n'a pas de sens.
On m'a demandé de porter du vieux code C depuis une machine HP vers du Redhat 9. Je me trouve confronté à un étrange problème :
Dans le code (qui est en production), il y a souvent des "strcmp(<chaine>, <null>)". Et cela fait planter mon appli : J'ai regardé dans le man du strcmp et on ne parle pas de ce cas. Est ce un comportement normal ?
Oui. Parfaitement normal. Le comportement d'un appel de strcmp avec un pointeur nul est indéfini. Le code n'a pas de sens.
-- Horst
Marc Boyer
Seb wrote:
Et bien le vieux compilateur HP semble faire le test, et malheureusement pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si vous avez une solution rapide ça m'aiderait bien
Quelques pistes de solution 1) Rapide et sale
#define strcmp(X,Y) robust_strcmp(X,Y)
int robust_strcmp(const char s1[], const char s2[]){ if (s1 == s2 ){ // Cas NULL == NULL return true; } else if ( s1 == NULL || s2 == NULL ) { return false; } else return strcmp(s1,s2); }
2) Plus propre grep strcmp * + rechercher/remplacer avec ton éditeur préféré
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Seb wrote:
Et bien le vieux compilateur HP semble faire le test, et malheureusement
pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si
vous avez une solution rapide ça m'aiderait bien
Quelques pistes de solution
1) Rapide et sale
#define strcmp(X,Y) robust_strcmp(X,Y)
int robust_strcmp(const char s1[], const char s2[]){
if (s1 == s2 ){ // Cas NULL == NULL
return true;
} else if ( s1 == NULL || s2 == NULL ) {
return false;
} else
return strcmp(s1,s2);
}
2) Plus propre
grep strcmp *
+ rechercher/remplacer avec ton éditeur préféré
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
Et bien le vieux compilateur HP semble faire le test, et malheureusement pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si vous avez une solution rapide ça m'aiderait bien
Quelques pistes de solution 1) Rapide et sale
#define strcmp(X,Y) robust_strcmp(X,Y)
int robust_strcmp(const char s1[], const char s2[]){ if (s1 == s2 ){ // Cas NULL == NULL return true; } else if ( s1 == NULL || s2 == NULL ) { return false; } else return strcmp(s1,s2); }
2) Plus propre grep strcmp * + rechercher/remplacer avec ton éditeur préféré
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Alexandre BACQUART
Seb wrote:
"Alexandre BACQUART" a écrit dans le message news: 40b5b887$0$3204$
Seb wrote:
Bonjour,
Dans le code (qui est en production), il y a souvent des "strcmp(<chaine>, <null>)". Et cela fait planter mon appli : J'ai regardé dans le man du strcmp et on ne parle pas de ce cas. Est ce un comportement normal ?
Déjà, strcmp(<chaine>, <null>), ça ne compile pas. Si tu veux dire que le premier est un char* ou const char* et que le second est 0 (ou NULL à l'ancienne), alors le plantage est normal, car je ne pense pas qu'il y ait beaucoup d'implémentations de strcmp() qui perdent du temps à vérifier la validité des pointeurs qu'on leur donne (et dans tous les cas, l'expression perd tout son sens).
Oui tu as compris ma "syntaxe" :-)
Et bien le vieux compilateur HP semble faire le test,
Ben non justement, d'où le plantage (facile à deviner : accès en lecture à l'adresse 0).
et malheureusement pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si vous avez une solution rapide ça m'aiderait bien
grep -e "strcmp[c ]*(.*,[c ]*(NULL)|(0).*)" *.c
-- Tek
Seb wrote:
"Alexandre BACQUART" <tek512@hotmail.com> a écrit dans le message news:
40b5b887$0$3204$626a14ce@news.free.fr
Seb wrote:
Bonjour,
Dans le code (qui est en production), il y a souvent des
"strcmp(<chaine>, <null>)". Et cela fait planter mon appli : J'ai
regardé dans le man du strcmp et on ne parle pas de ce cas. Est ce
un comportement normal ?
Déjà, strcmp(<chaine>, <null>), ça ne compile pas. Si tu veux dire que
le premier est un char* ou const char* et que le second est 0 (ou
NULL à l'ancienne), alors le plantage est normal, car je ne pense pas
qu'il y ait beaucoup d'implémentations de strcmp() qui perdent du
temps à vérifier la validité des pointeurs qu'on leur donne (et dans
tous les cas, l'expression perd tout son sens).
Oui tu as compris ma "syntaxe" :-)
Et bien le vieux compilateur HP semble faire le test,
Ben non justement, d'où le plantage (facile à deviner : accès en lecture
à l'adresse 0).
et malheureusement
pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si
vous avez une solution rapide ça m'aiderait bien
"Alexandre BACQUART" a écrit dans le message news: 40b5b887$0$3204$
Seb wrote:
Bonjour,
Dans le code (qui est en production), il y a souvent des "strcmp(<chaine>, <null>)". Et cela fait planter mon appli : J'ai regardé dans le man du strcmp et on ne parle pas de ce cas. Est ce un comportement normal ?
Déjà, strcmp(<chaine>, <null>), ça ne compile pas. Si tu veux dire que le premier est un char* ou const char* et que le second est 0 (ou NULL à l'ancienne), alors le plantage est normal, car je ne pense pas qu'il y ait beaucoup d'implémentations de strcmp() qui perdent du temps à vérifier la validité des pointeurs qu'on leur donne (et dans tous les cas, l'expression perd tout son sens).
Oui tu as compris ma "syntaxe" :-)
Et bien le vieux compilateur HP semble faire le test,
Ben non justement, d'où le plantage (facile à deviner : accès en lecture à l'adresse 0).
et malheureusement pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si vous avez une solution rapide ça m'aiderait bien
grep -e "strcmp[c ]*(.*,[c ]*(NULL)|(0).*)" *.c
-- Tek
kilobug
Seb wrote:
Et bien le vieux compilateur HP semble faire le test, et malheureusement pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si vous avez une solution rapide ça m'aiderait bien
Quelques pistes de solution 1) Rapide et sale
#define strcmp(X,Y) robust_strcmp(X,Y)
int robust_strcmp(const char s1[], const char s2[]){ if (s1 == s2 ){ // Cas NULL == NULL return true; } else if ( s1 == NULL || s2 == NULL ) { return false; } else return strcmp(s1,s2); }
<chipotage> Inverser le #define et la défintion de la fonction me semble plus sage, sinon elle va se rappeller elle-même indéfiniment... le return strcmp(s1,s2); se transformant en return robust_strcmp(s1,s2); </chipotage>
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Seb wrote:
Et bien le vieux compilateur HP semble faire le test, et malheureusement
pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si
vous avez une solution rapide ça m'aiderait bien
Quelques pistes de solution
1) Rapide et sale
#define strcmp(X,Y) robust_strcmp(X,Y)
int robust_strcmp(const char s1[], const char s2[]){
if (s1 == s2 ){ // Cas NULL == NULL
return true;
} else if ( s1 == NULL || s2 == NULL ) {
return false;
} else
return strcmp(s1,s2);
}
<chipotage>
Inverser le #define et la défintion de la fonction me semble plus
sage, sinon elle va se rappeller elle-même indéfiniment... le return
strcmp(s1,s2); se transformant en return robust_strcmp(s1,s2);
</chipotage>
--
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Et bien le vieux compilateur HP semble faire le test, et malheureusement pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si vous avez une solution rapide ça m'aiderait bien
Quelques pistes de solution 1) Rapide et sale
#define strcmp(X,Y) robust_strcmp(X,Y)
int robust_strcmp(const char s1[], const char s2[]){ if (s1 == s2 ){ // Cas NULL == NULL return true; } else if ( s1 == NULL || s2 == NULL ) { return false; } else return strcmp(s1,s2); }
<chipotage> Inverser le #define et la défintion de la fonction me semble plus sage, sinon elle va se rappeller elle-même indéfiniment... le return strcmp(s1,s2); se transformant en return robust_strcmp(s1,s2); </chipotage>
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Alexandre BACQUART
Alexandre BACQUART wrote:
grep -e "strcmp[c ]*(.*,[c ]*(NULL)|(0).*)" *.c
oups pardon, ça devrait être mieux pour les vicieux :
Mais franchement, je me demande d'où sort un code où il y a des centaines d'expressions n'ayant aucun sens comme celles-ci. Je me demande quand-même ce que l'expression retournait si elle ne plantait pas avant (strcmp faisant donc un test de pointeur valide).
-- Tek
Alexandre BACQUART wrote:
grep -e "strcmp[c ]*(.*,[c ]*(NULL)|(0).*)" *.c
oups pardon, ça devrait être mieux pour les vicieux :
Mais franchement, je me demande d'où sort un code où il y a des
centaines d'expressions n'ayant aucun sens comme celles-ci. Je me
demande quand-même ce que l'expression retournait si elle ne plantait
pas avant (strcmp faisant donc un test de pointeur valide).
Mais franchement, je me demande d'où sort un code où il y a des centaines d'expressions n'ayant aucun sens comme celles-ci. Je me demande quand-même ce que l'expression retournait si elle ne plantait pas avant (strcmp faisant donc un test de pointeur valide).
-- Tek
Seb
"Alexandre BACQUART" a écrit dans le message news: 40b5c469$0$3204$
Alexandre BACQUART wrote:
grep -e "strcmp[c ]*(.*,[c ]*(NULL)|(0).*)" *.c
oups pardon, ça devrait être mieux pour les vicieux :
Mais franchement, je me demande d'où sort un code où il y a des centaines d'expressions n'ayant aucun sens comme celles-ci. Je me demande quand-même ce que l'expression retournait si elle ne plantait pas avant (strcmp faisant donc un test de pointeur valide).
J'ai été certainement trop rapide : quand je disais que j'avais un NULL ce n'est pas explicitement écrit c'est qu'un char* vaut 0 au moment de l'éxecution.
Sébastien
"Alexandre BACQUART" <tek512@hotmail.com> a écrit dans le message news:
40b5c469$0$3204$626a14ce@news.free.fr
Alexandre BACQUART wrote:
grep -e "strcmp[c ]*(.*,[c ]*(NULL)|(0).*)" *.c
oups pardon, ça devrait être mieux pour les vicieux :
Mais franchement, je me demande d'où sort un code où il y a des
centaines d'expressions n'ayant aucun sens comme celles-ci. Je me
demande quand-même ce que l'expression retournait si elle ne plantait
pas avant (strcmp faisant donc un test de pointeur valide).
J'ai été certainement trop rapide : quand je disais que j'avais un NULL ce
n'est pas explicitement écrit c'est qu'un char* vaut 0 au moment de
l'éxecution.
Mais franchement, je me demande d'où sort un code où il y a des centaines d'expressions n'ayant aucun sens comme celles-ci. Je me demande quand-même ce que l'expression retournait si elle ne plantait pas avant (strcmp faisant donc un test de pointeur valide).
J'ai été certainement trop rapide : quand je disais que j'avais un NULL ce n'est pas explicitement écrit c'est qu'un char* vaut 0 au moment de l'éxecution.
Sébastien
Alexandre BACQUART
Gaël Le Mignot wrote:
Seb wrote:
Et bien le vieux compilateur HP semble faire le test, et malheureusement pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si vous avez une solution rapide ça m'aiderait bien
Quelques pistes de solution 1) Rapide et sale
#define strcmp(X,Y) robust_strcmp(X,Y)
int robust_strcmp(const char s1[], const char s2[]){ if (s1 == s2 ){ // Cas NULL == NULL
<chipotage> Inverser le #define et la défintion de la fonction me semble plus sage, sinon elle va se rappeller elle-même indéfiniment... le return strcmp(s1,s2); se transformant en return robust_strcmp(s1,s2); </chipotage>
Il y a aussi le problème que strcmp peut déjà être une macro. Dans ce cas, il suffit de faire #undef strcmp avant. Mais tromper comme ça le compilo pour lui faire avaler du code incensé reste potentiellement dangereux à mon avis... mieux vaut perdre une heure à corriger les centaines d'erreurs qui trainent (que le compilo se plaigne ou pas, ce sont des erreurs de logique fondamentale).
-- Tek
Gaël Le Mignot wrote:
Seb wrote:
Et bien le vieux compilateur HP semble faire le test, et malheureusement
pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si
vous avez une solution rapide ça m'aiderait bien
Quelques pistes de solution
1) Rapide et sale
#define strcmp(X,Y) robust_strcmp(X,Y)
int robust_strcmp(const char s1[], const char s2[]){
if (s1 == s2 ){ // Cas NULL == NULL
<chipotage>
Inverser le #define et la défintion de la fonction me semble plus
sage, sinon elle va se rappeller elle-même indéfiniment... le return
strcmp(s1,s2); se transformant en return robust_strcmp(s1,s2);
</chipotage>
Il y a aussi le problème que strcmp peut déjà être une macro. Dans ce
cas, il suffit de faire #undef strcmp avant. Mais tromper comme ça le
compilo pour lui faire avaler du code incensé reste potentiellement
dangereux à mon avis... mieux vaut perdre une heure à corriger les
centaines d'erreurs qui trainent (que le compilo se plaigne ou pas, ce
sont des erreurs de logique fondamentale).
Et bien le vieux compilateur HP semble faire le test, et malheureusement pour moi j'ai des centaines de strcmp qui sont potentiellement "buggés". Si vous avez une solution rapide ça m'aiderait bien
Quelques pistes de solution 1) Rapide et sale
#define strcmp(X,Y) robust_strcmp(X,Y)
int robust_strcmp(const char s1[], const char s2[]){ if (s1 == s2 ){ // Cas NULL == NULL
<chipotage> Inverser le #define et la défintion de la fonction me semble plus sage, sinon elle va se rappeller elle-même indéfiniment... le return strcmp(s1,s2); se transformant en return robust_strcmp(s1,s2); </chipotage>
Il y a aussi le problème que strcmp peut déjà être une macro. Dans ce cas, il suffit de faire #undef strcmp avant. Mais tromper comme ça le compilo pour lui faire avaler du code incensé reste potentiellement dangereux à mon avis... mieux vaut perdre une heure à corriger les centaines d'erreurs qui trainent (que le compilo se plaigne ou pas, ce sont des erreurs de logique fondamentale).
-- Tek
Alexandre BACQUART
Seb wrote:
J'ai été certainement trop rapide : quand je disais que j'avais un NULL ce n'est pas explicitement écrit c'est qu'un char* vaut 0 au moment de l'éxecution.
Je me demandais justement comment ton compilo pouvait accepter ça...
Ben heu... tu as un plus gros problème, sans les sources, on peut pas t'aider.
-- Tek
Seb wrote:
J'ai été certainement trop rapide : quand je disais que j'avais un NULL ce
n'est pas explicitement écrit c'est qu'un char* vaut 0 au moment de
l'éxecution.
Je me demandais justement comment ton compilo pouvait accepter ça...
Ben heu... tu as un plus gros problème, sans les sources, on peut pas
t'aider.
J'ai été certainement trop rapide : quand je disais que j'avais un NULL ce n'est pas explicitement écrit c'est qu'un char* vaut 0 au moment de l'éxecution.
Je me demandais justement comment ton compilo pouvait accepter ça...
Ben heu... tu as un plus gros problème, sans les sources, on peut pas t'aider.
