je lis partout le terme "d'associativit=E9" des op=E9rateurs ainsi que le
teme de "priorit=E9" des op=E9rateurs je pense avoir compris celui de la
priorit=E9 mais cette notion d'associativit=E9 reste tr=E8s (trop) floue
pour moi et je ne trouve rien qui l'explique clairement sur le net.
Ça ne change rien au fait que des parenthèses dans le cas
a - b - c
pour avoir
a - (b + c)
est largement plus clair.
... et, comme tu l'as toi-même (fort justement) fait remarquer précédemment, un comportement légèrement différent aux limites (genre b proche de a, et c très inférieur en magnitude).
Notez que je ne fais qu'insister sur le contenu de mon précédent message : si le code dépend de la première forme et ne passe pas avec la seconde (ou vice-versa), il faut rajouter des commentaires pour éviter de se poser des questions existentielles.
Antoine
JKB écrivit :
Ça ne change rien au fait que des parenthèses dans le cas
a - b - c
pour avoir
a - (b + c)
est largement plus clair.
... et, comme tu l'as toi-même (fort justement) fait remarquer
précédemment, un comportement légèrement différent aux limites
(genre b proche de a, et c très inférieur en magnitude).
Notez que je ne fais qu'insister sur le contenu de mon précédent message
: si le code dépend de la première forme et ne passe pas avec la seconde
(ou vice-versa), il faut rajouter des commentaires pour éviter de se
poser des questions existentielles.
Ça ne change rien au fait que des parenthèses dans le cas
a - b - c
pour avoir
a - (b + c)
est largement plus clair.
... et, comme tu l'as toi-même (fort justement) fait remarquer précédemment, un comportement légèrement différent aux limites (genre b proche de a, et c très inférieur en magnitude).
Notez que je ne fais qu'insister sur le contenu de mon précédent message : si le code dépend de la première forme et ne passe pas avec la seconde (ou vice-versa), il faut rajouter des commentaires pour éviter de se poser des questions existentielles.
Antoine
JKB
Le Mon, 6 Sep 2010 13:20:56 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
Un warning attendu dans ce cas: if(a = b)...
Qui est malheureusement parfaitement légal. Je me bats tous les jours contre ce genre de conneries parce qu'il y a des OS ou NULL ne vaut pas zéro ! Au hasard VMS avec certaines versions antiques de DEC C.
Tu parles de C pre-K&R, la.
Non, je parle du compilo ANSI de VMS 6 qui utilise 0x1 comme valeur nulle par défaut (une option permet de la forcer à 0x0, mais il y a un tas de VMSeries qui ne sont plus accessibles).
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 6 Sep 2010 13:20:56 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <slrni89q10.tg1.jkb@rayleigh.systella.fr>, JKB <invalid> wrote:
Un warning attendu dans ce cas:
if(a = b)...
Qui est malheureusement parfaitement légal. Je me bats tous les
jours contre ce genre de conneries parce qu'il y a des OS ou NULL ne
vaut pas zéro ! Au hasard VMS avec certaines versions antiques de
DEC C.
Tu parles de C pre-K&R, la.
Non, je parle du compilo ANSI de VMS 6 qui utilise 0x1 comme valeur
nulle par défaut (une option permet de la forcer à 0x0, mais il y a
un tas de VMSeries qui ne sont plus accessibles).
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 6 Sep 2010 13:20:56 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
Un warning attendu dans ce cas: if(a = b)...
Qui est malheureusement parfaitement légal. Je me bats tous les jours contre ce genre de conneries parce qu'il y a des OS ou NULL ne vaut pas zéro ! Au hasard VMS avec certaines versions antiques de DEC C.
Tu parles de C pre-K&R, la.
Non, je parle du compilo ANSI de VMS 6 qui utilise 0x1 comme valeur nulle par défaut (une option permet de la forcer à 0x0, mais il y a un tas de VMSeries qui ne sont plus accessibles).
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Ca me parait autant ANSI que NextStep etait POSIX: on met une option pour forcer le comportement standard, on colle l'etiquette ANSI sur la boite, et le compilo dans son mode utilisable est tout sauf standard...
In article <slrni89tij.tg1.jkb@rayleigh.systella.fr>, JKB <invalid> wrote:
Ca me parait autant ANSI que NextStep etait POSIX: on met une option pour
forcer le comportement standard, on colle l'etiquette ANSI sur la boite,
et le compilo dans son mode utilisable est tout sauf standard...
Ca me parait autant ANSI que NextStep etait POSIX: on met une option pour forcer le comportement standard, on colle l'etiquette ANSI sur la boite, et le compilo dans son mode utilisable est tout sauf standard...
JKB
Le Mon, 6 Sep 2010 14:28:54 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
Le Mon, 6 Sep 2010 13:20:56 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
Un warning attendu dans ce cas: if(a = b)...
Qui est malheureusement parfaitement légal. Je me bats tous les jours contre ce genre de conneries parce qu'il y a des OS ou NULL ne vaut pas zéro ! Au hasard VMS avec certaines versions antiques de DEC C.
Tu parles de C pre-K&R, la.
Non, je parle du compilo ANSI de VMS 6 qui utilise 0x1 comme valeur nulle par défaut (une option permet de la forcer à 0x0, mais il y a un tas de VMSeries qui ne sont plus accessibles).
C'est pas du C ANSI...
Ca me parait autant ANSI que NextStep etait POSIX: on met une option pour forcer le comportement standard, on colle l'etiquette ANSI sur la boite, et le compilo dans son mode utilisable est tout sauf standard...
CC /ANSI est _ANSI_ et NULL vaut 0x0. CC tout court n'est pas _ANSI_ et NULL vaut 0x1.
Depuis, je ne suppose plus que NULL vaut 0x0 et toutes mes comparaisons sont _explicites_. Si je dois porter du code sur des systèmes bizarres ou non standard, ça passe.
Le coup du pointeur NULL qui vaut 0x0, c'est exactement pour moi du même tonneau que getc() qui renvoie un int, un piège grossier dans lequel tout le monde tombe parce qu'on ne fait plus gaffe. Ceux qui connaissent le font naturellement sans forcément comprendre, ceux qui ne connaissent pas se cassent les dents.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 6 Sep 2010 14:28:54 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <slrni89tij.tg1.jkb@rayleigh.systella.fr>, JKB <invalid> wrote:
Le Mon, 6 Sep 2010 13:20:56 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <slrni89q10.tg1.jkb@rayleigh.systella.fr>, JKB <invalid> wrote:
Un warning attendu dans ce cas:
if(a = b)...
Qui est malheureusement parfaitement légal. Je me bats tous les
jours contre ce genre de conneries parce qu'il y a des OS ou NULL ne
vaut pas zéro ! Au hasard VMS avec certaines versions antiques de
DEC C.
Tu parles de C pre-K&R, la.
Non, je parle du compilo ANSI de VMS 6 qui utilise 0x1 comme valeur
nulle par défaut (une option permet de la forcer à 0x0, mais il y a
un tas de VMSeries qui ne sont plus accessibles).
C'est pas du C ANSI...
Ca me parait autant ANSI que NextStep etait POSIX: on met une option pour
forcer le comportement standard, on colle l'etiquette ANSI sur la boite,
et le compilo dans son mode utilisable est tout sauf standard...
CC /ANSI est _ANSI_ et NULL vaut 0x0.
CC tout court n'est pas _ANSI_ et NULL vaut 0x1.
Depuis, je ne suppose plus que NULL vaut 0x0 et toutes mes
comparaisons sont _explicites_. Si je dois porter du code sur des
systèmes bizarres ou non standard, ça passe.
Le coup du pointeur NULL qui vaut 0x0, c'est exactement pour moi du
même tonneau que getc() qui renvoie un int, un piège grossier dans
lequel tout le monde tombe parce qu'on ne fait plus gaffe. Ceux
qui connaissent le font naturellement sans forcément comprendre,
ceux qui ne connaissent pas se cassent les dents.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 6 Sep 2010 14:28:54 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
Le Mon, 6 Sep 2010 13:20:56 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
Un warning attendu dans ce cas: if(a = b)...
Qui est malheureusement parfaitement légal. Je me bats tous les jours contre ce genre de conneries parce qu'il y a des OS ou NULL ne vaut pas zéro ! Au hasard VMS avec certaines versions antiques de DEC C.
Tu parles de C pre-K&R, la.
Non, je parle du compilo ANSI de VMS 6 qui utilise 0x1 comme valeur nulle par défaut (une option permet de la forcer à 0x0, mais il y a un tas de VMSeries qui ne sont plus accessibles).
C'est pas du C ANSI...
Ca me parait autant ANSI que NextStep etait POSIX: on met une option pour forcer le comportement standard, on colle l'etiquette ANSI sur la boite, et le compilo dans son mode utilisable est tout sauf standard...
CC /ANSI est _ANSI_ et NULL vaut 0x0. CC tout court n'est pas _ANSI_ et NULL vaut 0x1.
Depuis, je ne suppose plus que NULL vaut 0x0 et toutes mes comparaisons sont _explicites_. Si je dois porter du code sur des systèmes bizarres ou non standard, ça passe.
Le coup du pointeur NULL qui vaut 0x0, c'est exactement pour moi du même tonneau que getc() qui renvoie un int, un piège grossier dans lequel tout le monde tombe parce qu'on ne fait plus gaffe. Ceux qui connaissent le font naturellement sans forcément comprendre, ceux qui ne connaissent pas se cassent les dents.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Jean-Marc Bourguet
JKB writes:
Ça ne change rien au fait que des parenthèses dans le cas
a - b - c
pour avoir
a - (b + c)
est largement plus clair.
Ce qui est plus clair entre les deux va dependre du contexe pour moi.
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
JKB <jkb@koenigsberg.invalid> writes:
Ça ne change rien au fait que des parenthèses dans le cas
a - b - c
pour avoir
a - (b + c)
est largement plus clair.
Ce qui est plus clair entre les deux va dependre du contexe pour moi.
A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Ça ne change rien au fait que des parenthèses dans le cas
a - b - c
pour avoir
a - (b + c)
est largement plus clair.
Ce qui est plus clair entre les deux va dependre du contexe pour moi.
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Pierre Maurette writes:
Enfin, j'ai remarqué que: a | b & c | d a & b | c & d a || b && c || d a && b || c && d génèrent un warning, alors que: a + b * c + d a * b + c * d laissent gcc muet. Est-ce logique ?
Assez. Ada par exemple ne permet pas les equivalents, ce qui laisse pensez que les auteurs de gcc ne sont pas les seuls a considerer que les priorites relatives des operateur booleens ne sont pas assez bien fixees pour justifier l'absence de parentheses.
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pierre Maurette <maurettepierre@wanadoo.fr> writes:
Enfin, j'ai remarqué que:
a | b & c | d
a & b | c & d
a || b && c || d
a && b || c && d
génèrent un warning, alors que:
a + b * c + d
a * b + c * d
laissent gcc muet. Est-ce logique ?
Assez. Ada par exemple ne permet pas les equivalents, ce qui laisse pensez
que les auteurs de gcc ne sont pas les seuls a considerer que les priorites
relatives des operateur booleens ne sont pas assez bien fixees pour
justifier l'absence de parentheses.
A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Enfin, j'ai remarqué que: a | b & c | d a & b | c & d a || b && c || d a && b || c && d génèrent un warning, alors que: a + b * c + d a * b + c * d laissent gcc muet. Est-ce logique ?
Assez. Ada par exemple ne permet pas les equivalents, ce qui laisse pensez que les auteurs de gcc ne sont pas les seuls a considerer que les priorites relatives des operateur booleens ne sont pas assez bien fixees pour justifier l'absence de parentheses.
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
Antoine Leca
JKB écrivit :
Le coup du pointeur NULL qui vaut 0x0, c'est exactement pour moi du même tonneau que getc() qui renvoie un int,
Tu peux développer STP ? Je vois bien un piège avec le type (et le domaine de valeurs) retourné par getc(), et je vois bien un autre piège avec des échanges indus entre NULL et 0 (du genre que tu décris et d'autres), mais je n'arrive pas à faire l'association entre les deux pièges.
(Par ailleurs, le compilo C qui refuse explicitement d'être conforme à une règle comme les comparaisons entre NULL et 0, à moins que ce ne soit un épiphénomène ce dont je doute, il doit générer une myriade de problèmes... Mais bon, là c'est mon avis personnel.)
Antoine
JKB écrivit :
Le coup du pointeur NULL qui vaut 0x0, c'est exactement pour moi du
même tonneau que getc() qui renvoie un int,
Tu peux développer STP ? Je vois bien un piège avec le type (et le
domaine de valeurs) retourné par getc(), et je vois bien un autre piège
avec des échanges indus entre NULL et 0 (du genre que tu décris et
d'autres), mais je n'arrive pas à faire l'association entre les deux pièges.
(Par ailleurs, le compilo C qui refuse explicitement d'être conforme à
une règle comme les comparaisons entre NULL et 0, à moins que ce ne soit
un épiphénomène ce dont je doute, il doit générer une myriade de
problèmes... Mais bon, là c'est mon avis personnel.)
Le coup du pointeur NULL qui vaut 0x0, c'est exactement pour moi du même tonneau que getc() qui renvoie un int,
Tu peux développer STP ? Je vois bien un piège avec le type (et le domaine de valeurs) retourné par getc(), et je vois bien un autre piège avec des échanges indus entre NULL et 0 (du genre que tu décris et d'autres), mais je n'arrive pas à faire l'association entre les deux pièges.
(Par ailleurs, le compilo C qui refuse explicitement d'être conforme à une règle comme les comparaisons entre NULL et 0, à moins que ce ne soit un épiphénomène ce dont je doute, il doit générer une myriade de problèmes... Mais bon, là c'est mon avis personnel.)
Antoine
Marc Boyer
Le 06-09-2010, JKB a écrit :
Le Mon, 6 Sep 2010 14:28:54 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
CC /ANSI est _ANSI_ et NULL vaut 0x0. CC tout court n'est pas _ANSI_ et NULL vaut 0x1.
Mais on pourrait faire un compilo ANSI où NULL vaut 0x1. Que CC ne sache pas le faire me semble un pb de qualité.
Depuis, je ne suppose plus que NULL vaut 0x0 et toutes mes comparaisons sont _explicites_. Si je dois porter du code sur des systèmes bizarres ou non standard, ça passe.
Que tu sois obligé de faire ça parce que tu maintiens du code VMS, je le comprends tout à fait. De là à en faire une recommandation universelle...
Le coup du pointeur NULL qui vaut 0x0, c'est exactement pour moi du même tonneau que getc() qui renvoie un int, un piège grossier dans lequel tout le monde tombe parce qu'on ne fait plus gaffe.
Sauf que pour getc(), je ne vois pas trop comment faire autrement. Le type de sortie de getc doit contenir tous les char *et* EOF. Ou des signatures du genre bool getc(char* c) pour faire des while( getc(&x) ) en lieu et place du while( i= getc() ){ }
Quand à la fréquence du piège... Le coup de "tout le monde y tombe". J'ai tendance à dire qu'en France, on a plus de chance de tomber sur un fichier texte latin1 avec un ÿ que de coder sur un compilo qui fait presque de C et qui ne sait pas code l'idiome if ( x = malloc(...) )
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Le 06-09-2010, JKB <jkb@koenigsberg.invalid> a écrit :
Le Mon, 6 Sep 2010 14:28:54 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <slrni89tij.tg1.jkb@rayleigh.systella.fr>, JKB <invalid> wrote:
CC /ANSI est _ANSI_ et NULL vaut 0x0.
CC tout court n'est pas _ANSI_ et NULL vaut 0x1.
Mais on pourrait faire un compilo ANSI où NULL vaut 0x1.
Que CC ne sache pas le faire me semble un pb de qualité.
Depuis, je ne suppose plus que NULL vaut 0x0 et toutes mes
comparaisons sont _explicites_. Si je dois porter du code sur des
systèmes bizarres ou non standard, ça passe.
Que tu sois obligé de faire ça parce que tu maintiens du code VMS,
je le comprends tout à fait. De là à en faire une recommandation
universelle...
Le coup du pointeur NULL qui vaut 0x0, c'est exactement pour moi du
même tonneau que getc() qui renvoie un int, un piège grossier dans
lequel tout le monde tombe parce qu'on ne fait plus gaffe.
Sauf que pour getc(), je ne vois pas trop comment faire autrement.
Le type de sortie de getc doit contenir tous les char *et* EOF. Ou
des signatures du genre
bool getc(char* c)
pour faire des
while( getc(&x) )
en lieu et place du
while( i= getc() ){
}
Quand à la fréquence du piège... Le coup de "tout le monde y tombe".
J'ai tendance à dire qu'en France, on a plus de chance
de tomber sur un fichier texte latin1 avec un ÿ que de coder sur un compilo
qui fait presque de C et qui ne sait pas code l'idiome
if ( x = malloc(...) )
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Le Mon, 6 Sep 2010 14:28:54 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
CC /ANSI est _ANSI_ et NULL vaut 0x0. CC tout court n'est pas _ANSI_ et NULL vaut 0x1.
Mais on pourrait faire un compilo ANSI où NULL vaut 0x1. Que CC ne sache pas le faire me semble un pb de qualité.
Depuis, je ne suppose plus que NULL vaut 0x0 et toutes mes comparaisons sont _explicites_. Si je dois porter du code sur des systèmes bizarres ou non standard, ça passe.
Que tu sois obligé de faire ça parce que tu maintiens du code VMS, je le comprends tout à fait. De là à en faire une recommandation universelle...
Le coup du pointeur NULL qui vaut 0x0, c'est exactement pour moi du même tonneau que getc() qui renvoie un int, un piège grossier dans lequel tout le monde tombe parce qu'on ne fait plus gaffe.
Sauf que pour getc(), je ne vois pas trop comment faire autrement. Le type de sortie de getc doit contenir tous les char *et* EOF. Ou des signatures du genre bool getc(char* c) pour faire des while( getc(&x) ) en lieu et place du while( i= getc() ){ }
Quand à la fréquence du piège... Le coup de "tout le monde y tombe". J'ai tendance à dire qu'en France, on a plus de chance de tomber sur un fichier texte latin1 avec un ÿ que de coder sur un compilo qui fait presque de C et qui ne sait pas code l'idiome if ( x = malloc(...) )
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
JKB
Le Mon, 06 Sep 2010 17:12:45 +0200, Antoine Leca écrivait :
JKB écrivit :
Le coup du pointeur NULL qui vaut 0x0, c'est exactement pour moi du même tonneau que getc() qui renvoie un int,
Tu peux développer STP ? Je vois bien un piège avec le type (et le domaine de valeurs) retourné par getc(), et je vois bien un autre piège avec des échanges indus entre NULL et 0 (du genre que tu décris et d'autres), mais je n'arrive pas à faire l'association entre les deux pièges.
C'est très simple : à force d'écrire des trucs comme while(*ptr++), on ne se pose plus la question. Implicitement, on considère que le tableau termine par un NULL. Si ton NULL vaut 0x1, ton code part dans le mur. C'est du même tonneau que les gens qui considèrent que char est un type pour retenir un caractère, ce qui est faut parce que le caractère EOF est un INT et ne tient que rarement dans un char.
(Par ailleurs, le compilo C qui refuse explicitement d'être conforme à une règle comme les comparaisons entre NULL et 0, à moins que ce ne soit un épiphénomène ce dont je doute, il doit générer une myriade de problèmes... Mais bon, là c'est mon avis personnel.)
Sauf si tu écris explicitement tes comparaisons, ce qui n'est pas une mauvaise habitude.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 06 Sep 2010 17:12:45 +0200,
Antoine Leca <root@localhost.invalid> écrivait :
JKB écrivit :
Le coup du pointeur NULL qui vaut 0x0, c'est exactement pour moi du
même tonneau que getc() qui renvoie un int,
Tu peux développer STP ? Je vois bien un piège avec le type (et le
domaine de valeurs) retourné par getc(), et je vois bien un autre piège
avec des échanges indus entre NULL et 0 (du genre que tu décris et
d'autres), mais je n'arrive pas à faire l'association entre les deux pièges.
C'est très simple : à force d'écrire des trucs comme while(*ptr++),
on ne se pose plus la question. Implicitement, on considère que le
tableau termine par un NULL. Si ton NULL vaut 0x1, ton code part
dans le mur. C'est du même tonneau que les gens qui considèrent que
char est un type pour retenir un caractère, ce qui est faut parce
que le caractère EOF est un INT et ne tient que rarement dans un
char.
(Par ailleurs, le compilo C qui refuse explicitement d'être conforme à
une règle comme les comparaisons entre NULL et 0, à moins que ce ne soit
un épiphénomène ce dont je doute, il doit générer une myriade de
problèmes... Mais bon, là c'est mon avis personnel.)
Sauf si tu écris explicitement tes comparaisons, ce qui n'est pas
une mauvaise habitude.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 06 Sep 2010 17:12:45 +0200, Antoine Leca écrivait :
JKB écrivit :
Le coup du pointeur NULL qui vaut 0x0, c'est exactement pour moi du même tonneau que getc() qui renvoie un int,
Tu peux développer STP ? Je vois bien un piège avec le type (et le domaine de valeurs) retourné par getc(), et je vois bien un autre piège avec des échanges indus entre NULL et 0 (du genre que tu décris et d'autres), mais je n'arrive pas à faire l'association entre les deux pièges.
C'est très simple : à force d'écrire des trucs comme while(*ptr++), on ne se pose plus la question. Implicitement, on considère que le tableau termine par un NULL. Si ton NULL vaut 0x1, ton code part dans le mur. C'est du même tonneau que les gens qui considèrent que char est un type pour retenir un caractère, ce qui est faut parce que le caractère EOF est un INT et ne tient que rarement dans un char.
(Par ailleurs, le compilo C qui refuse explicitement d'être conforme à une règle comme les comparaisons entre NULL et 0, à moins que ce ne soit un épiphénomène ce dont je doute, il doit générer une myriade de problèmes... Mais bon, là c'est mon avis personnel.)
Sauf si tu écris explicitement tes comparaisons, ce qui n'est pas une mauvaise habitude.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
JKB
Le Mon, 6 Sep 2010 15:15:50 +0000 (UTC), Marc Boyer écrivait :
Le 06-09-2010, JKB a écrit :
Le Mon, 6 Sep 2010 14:28:54 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
CC /ANSI est _ANSI_ et NULL vaut 0x0. CC tout court n'est pas _ANSI_ et NULL vaut 0x1.
Mais on pourrait faire un compilo ANSI où NULL vaut 0x1. Que CC ne sache pas le faire me semble un pb de qualité.
Il y a une raison à ça. Et dire que NULL vaut 0x1 risque de mettre le bazar dans toutes les expressions du style if (ptr) { }
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 6 Sep 2010 15:15:50 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 06-09-2010, JKB <jkb@koenigsberg.invalid> a écrit :
Le Mon, 6 Sep 2010 14:28:54 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <slrni89tij.tg1.jkb@rayleigh.systella.fr>, JKB <invalid> wrote:
CC /ANSI est _ANSI_ et NULL vaut 0x0.
CC tout court n'est pas _ANSI_ et NULL vaut 0x1.
Mais on pourrait faire un compilo ANSI où NULL vaut 0x1.
Que CC ne sache pas le faire me semble un pb de qualité.
Il y a une raison à ça. Et dire que NULL vaut 0x1 risque de mettre
le bazar dans toutes les expressions du style if (ptr) { }
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
