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 ?
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Emmanuel Delahaye <emdelYOURBRA@noos.fr> wrote:
--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Alexandre BACQUART
Marc Boyer wrote:
Alexandre BACQUART wrote:
Gaël Le Mignot wrote:
int robust_strcmp(const char s1[], const char s2[]){ if (s1 == s2 ){ // Cas NULL == NULL
Commentaire faux et superflu.
Pourquoi faux ? Si la sémantique du hp-strcmp est que hp-strcmp(0,0) == 0, c'est ce que cela doit faire.
C'est le cas s1 == s2 tout simplement. Le strcmp hp-unix retourne "égal" (autrement dit 0) qu'on lui donne (NULL,NULL), ("glop","glop") ou (str, str).
De plus tu retournes true et false alors que tu devrais retourner un int.
-- Tek
Marc Boyer wrote:
Alexandre BACQUART wrote:
Gaël Le Mignot wrote:
int robust_strcmp(const char s1[], const char s2[]){
if (s1 == s2 ){ // Cas NULL == NULL
Commentaire faux et superflu.
Pourquoi faux ? Si la sémantique du hp-strcmp est que
hp-strcmp(0,0) == 0, c'est ce que cela doit faire.
C'est le cas s1 == s2 tout simplement. Le strcmp hp-unix retourne "égal"
(autrement dit 0) qu'on lui donne (NULL,NULL), ("glop","glop") ou (str,
str).
De plus tu retournes true et false alors que tu devrais retourner un int.
int robust_strcmp(const char s1[], const char s2[]){ if (s1 == s2 ){ // Cas NULL == NULL
Commentaire faux et superflu.
Pourquoi faux ? Si la sémantique du hp-strcmp est que hp-strcmp(0,0) == 0, c'est ce que cela doit faire.
C'est le cas s1 == s2 tout simplement. Le strcmp hp-unix retourne "égal" (autrement dit 0) qu'on lui donne (NULL,NULL), ("glop","glop") ou (str, str).
De plus tu retournes true et false alors que tu devrais retourner un int.
-- Tek
Horst Kraemer
On Thu, 27 May 2004 14:11:53 +0200, "Seb" wrote:
"Horst Kraemer" a écrit dans le message news:
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.
Par curiosité je suis allé voir les man du Hp Unix
Et on peut lire ceci :
strcmp() Compares its arguments and returns an integer less than, equal to, or greater than zero, depending on whether s1 is lexicographically less than, equal to, or greater than s2. The comparison of corresponding characters is done as if the type of the characters were unsigned char. Null pointer values for s1 and s2 are treated the same as pointers to empty strings.
La conclusion : c'était légal il y a un certain temps ....
C'était légal il y a un certain temps sur HP Unix mais ce n'était jamais légal d'après la norme du langage C apparue en 1990.
-- Horst
On Thu, 27 May 2004 14:11:53 +0200, "Seb" <nospam@yahoo.net> wrote:
"Horst Kraemer" <horst.kraemer@epost.de> a écrit dans le message news:
aedbb09atkvbrtdavvluk9o0pe8el4t36a@4ax.com
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.
Par curiosité je suis allé voir les man du Hp Unix
Et on peut lire ceci :
strcmp() Compares its arguments and returns an integer less
than, equal to, or greater than zero, depending on
whether s1 is lexicographically less than, equal to, or
greater than s2. The comparison of corresponding
characters is done as if the type of the characters
were unsigned char. Null pointer values for s1 and s2
are treated the same as pointers to empty strings.
La conclusion : c'était légal il y a un certain temps ....
C'était légal il y a un certain temps sur HP Unix mais ce n'était
jamais légal d'après la norme du langage C apparue en 1990.
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.
Par curiosité je suis allé voir les man du Hp Unix
Et on peut lire ceci :
strcmp() Compares its arguments and returns an integer less than, equal to, or greater than zero, depending on whether s1 is lexicographically less than, equal to, or greater than s2. The comparison of corresponding characters is done as if the type of the characters were unsigned char. Null pointer values for s1 and s2 are treated the same as pointers to empty strings.
La conclusion : c'était légal il y a un certain temps ....
C'était légal il y a un certain temps sur HP Unix mais ce n'était jamais légal d'après la norme du langage C apparue en 1990.
Elégant ! Mais si strcmp est une macro a base d'arithmétique de pointeurs, je me demande ce que ça donne.
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...
Elégant !
Mais si strcmp est une macro a base d'arithmétique de pointeurs,
je me demande ce que ça donne.
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...
Elégant ! Mais si strcmp est une macro a base d'arithmétique de pointeurs, je me demande ce que ça donne.
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...
Elégant ! Mais si strcmp est une macro a base d'arithmétique de pointeurs, je me demande ce que ça donne.
(hum) Tu fais comment pour implémenter de la comparaison de chaînes sans déréférencer les pointeurs que tu passes ?
Je vois pas le sens de ta question mais ma remarque était pas tres pertinente non plus. Ma remarque était guidée par le fait que je croyais avoir lu de se mefier des str* dans le sens ou elle etait parfois implementées par des macros, avec pb d'évaluation multiple des arguments. Mais en rereflechissant au probleme, primo je n'arrive pas a ecrire une telle macro, et ensuite se serait une bien prietre implementation.
Donc, il ne faut garder de mon post que la remarque d'elegance de la solution d'Emmanuel.
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...
Elégant !
Mais si strcmp est une macro a base d'arithmétique de pointeurs,
je me demande ce que ça donne.
(hum) Tu fais comment pour implémenter de la comparaison de chaînes
sans déréférencer les pointeurs que tu passes ?
Je vois pas le sens de ta question mais ma remarque était pas
tres pertinente non plus.
Ma remarque était guidée par le fait que je croyais avoir lu de
se mefier des str* dans le sens ou elle etait parfois implementées
par des macros, avec pb d'évaluation multiple des arguments.
Mais en rereflechissant au probleme, primo je n'arrive pas a
ecrire une telle macro, et ensuite se serait une bien prietre
implementation.
Donc, il ne faut garder de mon post que la remarque d'elegance
de la solution d'Emmanuel.
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...
Elégant ! Mais si strcmp est une macro a base d'arithmétique de pointeurs, je me demande ce que ça donne.
(hum) Tu fais comment pour implémenter de la comparaison de chaînes sans déréférencer les pointeurs que tu passes ?
Je vois pas le sens de ta question mais ma remarque était pas tres pertinente non plus. Ma remarque était guidée par le fait que je croyais avoir lu de se mefier des str* dans le sens ou elle etait parfois implementées par des macros, avec pb d'évaluation multiple des arguments. Mais en rereflechissant au probleme, primo je n'arrive pas a ecrire une telle macro, et ensuite se serait une bien prietre implementation.
Donc, il ne faut garder de mon post que la remarque d'elegance de la solution d'Emmanuel.
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
Marc Boyer wrote:
Ma remarque était guidée par le fait que je croyais avoir lu de se mefier des str* dans le sens ou elle etait parfois implementées par des macros, avec pb d'évaluation multiple des arguments.
Mmh, je ne pense pas...
Si l'algo strcmp est implémenté en hardware par ex., une macro pourraît router l'appel sur une fonction spéciale de la lib C, genre :
#define strcmp(a,b) __imp__strcmp((a),(b))
Donc strcmp() EST une macro dans ce cas, sans problème d'évaluation multiple. Je ne pense pas qu'une implémentation de strcmp() ou autres str*() en macro soit possible et utilisable partout en tant qu'expression, ce qui expliquerait pourquoi tu ne sais pas la faire, et moi non plus :) (mais je me méfie, il y a des gens capables de tout). Bref, tout ça pour dire que les str*() ne sont pas forcément des fonctions, nuance importante rendant par exemple l'utilisation des pointeurs de fonction sur str*() non portable.
-- Tek
Marc Boyer wrote:
Ma remarque était guidée par le fait que je croyais avoir lu de
se mefier des str* dans le sens ou elle etait parfois implementées
par des macros, avec pb d'évaluation multiple des arguments.
Mmh, je ne pense pas...
Si l'algo strcmp est implémenté en hardware par ex., une macro pourraît
router l'appel sur une fonction spéciale de la lib C, genre :
#define strcmp(a,b) __imp__strcmp((a),(b))
Donc strcmp() EST une macro dans ce cas, sans problème d'évaluation
multiple. Je ne pense pas qu'une implémentation de strcmp() ou autres
str*() en macro soit possible et utilisable partout en tant
qu'expression, ce qui expliquerait pourquoi tu ne sais pas la faire, et
moi non plus :) (mais je me méfie, il y a des gens capables de tout).
Bref, tout ça pour dire que les str*() ne sont pas forcément des
fonctions, nuance importante rendant par exemple l'utilisation des
pointeurs de fonction sur str*() non portable.
Ma remarque était guidée par le fait que je croyais avoir lu de se mefier des str* dans le sens ou elle etait parfois implementées par des macros, avec pb d'évaluation multiple des arguments.
Mmh, je ne pense pas...
Si l'algo strcmp est implémenté en hardware par ex., une macro pourraît router l'appel sur une fonction spéciale de la lib C, genre :
#define strcmp(a,b) __imp__strcmp((a),(b))
Donc strcmp() EST une macro dans ce cas, sans problème d'évaluation multiple. Je ne pense pas qu'une implémentation de strcmp() ou autres str*() en macro soit possible et utilisable partout en tant qu'expression, ce qui expliquerait pourquoi tu ne sais pas la faire, et moi non plus :) (mais je me méfie, il y a des gens capables de tout). Bref, tout ça pour dire que les str*() ne sont pas forcément des fonctions, nuance importante rendant par exemple l'utilisation des pointeurs de fonction sur str*() non portable.
-- Tek
DINH Viêt Hoà
Donc strcmp() EST une macro dans ce cas, sans problème d'évaluation multiple. Je ne pense pas qu'une implémentation de strcmp() ou autres str*() en macro soit possible et utilisable partout en tant qu'expression, ce qui expliquerait pourquoi tu ne sais pas la faire, et moi non plus :) (mais je me méfie, il y a des gens capables de tout).
quoiqu'on peut faire une implémentation à base de macro avec une limitation aux chaînes de 2 caractères.
-- DINH V. Hoa,
"sinon je suis le meilleur ingénieur du monde" -- Arsunik [2]
Donc strcmp() EST une macro dans ce cas, sans problème d'évaluation
multiple. Je ne pense pas qu'une implémentation de strcmp() ou autres
str*() en macro soit possible et utilisable partout en tant
qu'expression, ce qui expliquerait pourquoi tu ne sais pas la faire, et
moi non plus :) (mais je me méfie, il y a des gens capables de tout).
quoiqu'on peut faire une implémentation à base de macro avec une
limitation aux chaînes de 2 caractères.
--
DINH V. Hoa,
"sinon je suis le meilleur ingénieur du monde" -- Arsunik [2]
Donc strcmp() EST une macro dans ce cas, sans problème d'évaluation multiple. Je ne pense pas qu'une implémentation de strcmp() ou autres str*() en macro soit possible et utilisable partout en tant qu'expression, ce qui expliquerait pourquoi tu ne sais pas la faire, et moi non plus :) (mais je me méfie, il y a des gens capables de tout).
quoiqu'on peut faire une implémentation à base de macro avec une limitation aux chaînes de 2 caractères.
-- DINH V. Hoa,
"sinon je suis le meilleur ingénieur du monde" -- Arsunik [2]
kanze
Horst Kraemer wrote in message news:...
On Thu, 27 May 2004 14:11:53 +0200, "Seb" wrote:
"Horst Kraemer" a écrit dans le message news:
Oui. Parfaitement normal. Le comportement d'un appel de strcmp avec un pointeur nul est indéfini. Le code n'a pas de sens.
Par curiosité je suis allé voir les man du Hp Unix
Et on peut lire ceci :
strcmp() Compares its arguments and returns an integer less than, equal to, or greater than zero, depending on whether s1 is lexicographically less than, equal to, or greater than s2. The comparison of corresponding characters is done as if the type of the characters were unsigned char. Null pointer values for s1 and s2 are treated the same as pointers to empty strings.
La conclusion : c'était légal il y a un certain temps ....
C'était légal il y a un certain temps sur HP Unix mais ce n'était jamais légal d'après la norme du langage C apparue en 1990.
Ce n'était même pas légal dans le C de K&R, si je me rappelle bien de la doc. En revanche, dans les Unix de l'époque, l'adresse 0 n'était pas protégée en lecture, et contenait un 0. Du coup, légal ou non, ça marchait. Et certains ont crû que c'était exprès, et s'en sont servis. (Quand on a modifié le noyau pour que la page 0 ne soit pas mappé la première fois, il a fallu faire marche en arrière, parce qu'à peu près un tier des utilitaires faisait des core.)
Du coup, pour des raisons de compatibilité, un bon nombre d'implémentations le supportaient.
La bonne solution n'est pas facile. Il faut chercher où sont affecté ces pointeurs nuls au départ, et les corriger pour utiliser "" à la place. À la place de chercher strcmp et al., je chercherais NULL, et regarderait alors s'il est affecté à un char*, et si oui, qu'est-ce qu'on fait de ce char*.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Horst Kraemer <horst.kraemer@epost.de> wrote in message
news:<04ocb099nntdmfvq0c2hkhmv44egoqsa6q@4ax.com>...
On Thu, 27 May 2004 14:11:53 +0200, "Seb" <nospam@yahoo.net> wrote:
"Horst Kraemer" <horst.kraemer@epost.de> a écrit dans le message news:
aedbb09atkvbrtdavvluk9o0pe8el4t36a@4ax.com
Oui. Parfaitement normal. Le comportement d'un appel de strcmp
avec un pointeur nul est indéfini. Le code n'a pas de sens.
Par curiosité je suis allé voir les man du Hp Unix
Et on peut lire ceci :
strcmp() Compares its arguments and returns an integer less
than, equal to, or greater than zero, depending on
whether s1 is lexicographically less than, equal to, or
greater than s2. The comparison of corresponding
characters is done as if the type of the characters
were unsigned char. Null pointer values for s1 and s2
are treated the same as pointers to empty strings.
La conclusion : c'était légal il y a un certain temps ....
C'était légal il y a un certain temps sur HP Unix mais ce n'était
jamais légal d'après la norme du langage C apparue en 1990.
Ce n'était même pas légal dans le C de K&R, si je me rappelle bien de la
doc. En revanche, dans les Unix de l'époque, l'adresse 0 n'était pas
protégée en lecture, et contenait un 0. Du coup, légal ou non, ça
marchait. Et certains ont crû que c'était exprès, et s'en sont servis.
(Quand on a modifié le noyau pour que la page 0 ne soit pas mappé la
première fois, il a fallu faire marche en arrière, parce qu'à peu près
un tier des utilitaires faisait des core.)
Du coup, pour des raisons de compatibilité, un bon nombre
d'implémentations le supportaient.
La bonne solution n'est pas facile. Il faut chercher où sont affecté ces
pointeurs nuls au départ, et les corriger pour utiliser "" à la place. À
la place de chercher strcmp et al., je chercherais NULL, et regarderait
alors s'il est affecté à un char*, et si oui, qu'est-ce qu'on fait de ce
char*.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oui. Parfaitement normal. Le comportement d'un appel de strcmp avec un pointeur nul est indéfini. Le code n'a pas de sens.
Par curiosité je suis allé voir les man du Hp Unix
Et on peut lire ceci :
strcmp() Compares its arguments and returns an integer less than, equal to, or greater than zero, depending on whether s1 is lexicographically less than, equal to, or greater than s2. The comparison of corresponding characters is done as if the type of the characters were unsigned char. Null pointer values for s1 and s2 are treated the same as pointers to empty strings.
La conclusion : c'était légal il y a un certain temps ....
C'était légal il y a un certain temps sur HP Unix mais ce n'était jamais légal d'après la norme du langage C apparue en 1990.
Ce n'était même pas légal dans le C de K&R, si je me rappelle bien de la doc. En revanche, dans les Unix de l'époque, l'adresse 0 n'était pas protégée en lecture, et contenait un 0. Du coup, légal ou non, ça marchait. Et certains ont crû que c'était exprès, et s'en sont servis. (Quand on a modifié le noyau pour que la page 0 ne soit pas mappé la première fois, il a fallu faire marche en arrière, parce qu'à peu près un tier des utilitaires faisait des core.)
Du coup, pour des raisons de compatibilité, un bon nombre d'implémentations le supportaient.
La bonne solution n'est pas facile. Il faut chercher où sont affecté ces pointeurs nuls au départ, et les corriger pour utiliser "" à la place. À la place de chercher strcmp et al., je chercherais NULL, et regarderait alors s'il est affecté à un char*, et si oui, qu'est-ce qu'on fait de ce char*.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
espie
In article <40b5c469$0$3204$, Alexandre BACQUART wrote:
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).
Le coup du strcmp qui marche avec un pointeur nul, c'est malheureusement atrocement courant, et source de multiples bugs.
In article <40b5c469$0$3204$626a14ce@news.free.fr>,
Alexandre BACQUART <tek512@hotmail.com> wrote:
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).
Le coup du strcmp qui marche avec un pointeur nul, c'est malheureusement
atrocement courant, et source de multiples bugs.
In article <40b5c469$0$3204$, Alexandre BACQUART wrote:
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).
Le coup du strcmp qui marche avec un pointeur nul, c'est malheureusement atrocement courant, et source de multiples bugs.
