Non je parlais du WEB. C'est clair depuis le début. Je me cite à nouveau:
> Moi:
> > Vincent:
> > Tout dépend de l'implémentation, qui peut très bien utiliser
> > 1 à chaque fois (sauf pour zéro). Je rappelle que l'exposant est
> > binaire.
>
> Binaire? genre p-10 veut dire 2-16? la doc que j'ai trouvée
> http://www.opengroup.org/onlinepubs/000095399/functions/printf.html
> dit exposant décimal (donc 2-10 = 1/1024 ici).
Son conseil aurait été plus utile s'il avait filé l'url ou, mieux,
recopié le passage de la norme qui s'y réfère. Je l'ai fait, il dit que
ca parle de "binary exponent", je ne l'ai pas retrouvé. :-/
Non je parlais du WEB. C'est clair depuis le début. Je me cite à nouveau:
> Moi:
> > Vincent:
> > Tout dépend de l'implémentation, qui peut très bien utiliser
> > 1 à chaque fois (sauf pour zéro). Je rappelle que l'exposant est
> > binaire.
>
> Binaire? genre p-10 veut dire 2-16? la doc que j'ai trouvée
> http://www.opengroup.org/onlinepubs/000095399/functions/printf.html
> dit exposant décimal (donc 2-10 = 1/1024 ici).
Son conseil aurait été plus utile s'il avait filé l'url ou, mieux,
recopié le passage de la norme qui s'y réfère. Je l'ai fait, il dit que
ca parle de "binary exponent", je ne l'ai pas retrouvé. :-/
Non je parlais du WEB. C'est clair depuis le début. Je me cite à nouveau:
> Moi:
> > Vincent:
> > Tout dépend de l'implémentation, qui peut très bien utiliser
> > 1 à chaque fois (sauf pour zéro). Je rappelle que l'exposant est
> > binaire.
>
> Binaire? genre p-10 veut dire 2-16? la doc que j'ai trouvée
> http://www.opengroup.org/onlinepubs/000095399/functions/printf.html
> dit exposant décimal (donc 2-10 = 1/1024 ici).
Son conseil aurait été plus utile s'il avait filé l'url ou, mieux,
recopié le passage de la norme qui s'y réfère. Je l'ai fait, il dit que
ca parle de "binary exponent", je ne l'ai pas retrouvé. :-/
Désolé. Sur http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf je
n'ai pas trouvé "binary exponent part" dans la description de printf
The exponent always contains at least one digit, and only as manymore
digits as necessary to represent the decimal exponent of 2.
Désolé. Sur http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf je
n'ai pas trouvé "binary exponent part" dans la description de printf
The exponent always contains at least one digit, and only as manymore
digits as necessary to represent the decimal exponent of 2.
Désolé. Sur http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf je
n'ai pas trouvé "binary exponent part" dans la description de printf
The exponent always contains at least one digit, and only as manymore
digits as necessary to represent the decimal exponent of 2.
../.. et là où le problème devient brûlant,
c'est que sur les plateformes les plus répandues à l'heure actuelle, on
ne se rend pas compte du problème, car il se trouve que unsigned et long
ont la même représentation mémoire.
Sur une machine 16 bits, printf("%x", un_long) marche effectivement
(sauf cas /très/ particuliers), mais n'affiche pas le même résultat que
sur une machine « habituelle », et ÀMHA le résultat « faux » est celui
de la machine 16 bits.Perso je n'aime pas les phrases sèches: "ce code est faux".
Je crois qu'on avait compris. Cependant, il ne m'a pas semblé avoir
écrit cela, et sûrement pas dans le mien message auquel tu réponds.
Il lui manque quelque chose indiquant sous quelle hypothèse c'est
faux.
Mmm. D'abord, je pense faire en général un effort pour indiquer, au
moins sommairement, pourquoi je considère qu'un code ne va donner le
résultat escompté. Il est vrai que c'est parfois trop bref, cf. supra.
Ensuite, un des principes de la norme C, c'est de définir « bon », qui
s'y épelle « strictement conforme », et qui est en gros défini comme
« produit le même effet partout » ; après, on peut ergoter sur faux par
rapport à strictement conforme, toussa (surtout que pour compliquer, on
a la notion de « programme conforme » qui signifie « accepté par un
compilateur C conforme », ce qui inclut donc tous les programmes Fortran
et assembleur compilables par GCC...)Un code peut être faux sous C99 et légitime sous C89.
C'est vrai mais c'est plutôt rare ; et c'est le plus souvent à cause de
l'utilisation de fonctionnalités comme le int implicite, qu'il vaut
mieux corriger le plus vite possible. Un autre problème peut venir des
noms de fonctions standards introduits par C99, et là aussi dans la
pratique, le programmeur va être obligé de suivre le train (c'est pareil
pour les mots clés de C++ ou les fonctions de Posix).
Après, je sais très bien qu'il y a des programmes écrits pour C89,
considérés comme bien écrits, qui posent problème lorsqu'on les passe
sur un compilateur C99 : le plus évident sont les (quelques) programmes
qui s'appuient sur la certitude que long est le plus grand type entier ;
cependant, je crois qu'ils servent beaucoup plus souvent d'alibi pour
cacher une multitude de programmes mal écrits, par exemple qui supposent
que long est un entier sur 32 bits.
Antoine
../.. et là où le problème devient brûlant,
c'est que sur les plateformes les plus répandues à l'heure actuelle, on
ne se rend pas compte du problème, car il se trouve que unsigned et long
ont la même représentation mémoire.
Sur une machine 16 bits, printf("%x", un_long) marche effectivement
(sauf cas /très/ particuliers), mais n'affiche pas le même résultat que
sur une machine « habituelle », et ÀMHA le résultat « faux » est celui
de la machine 16 bits.
Perso je n'aime pas les phrases sèches: "ce code est faux".
Je crois qu'on avait compris. Cependant, il ne m'a pas semblé avoir
écrit cela, et sûrement pas dans le mien message auquel tu réponds.
Il lui manque quelque chose indiquant sous quelle hypothèse c'est
faux.
Mmm. D'abord, je pense faire en général un effort pour indiquer, au
moins sommairement, pourquoi je considère qu'un code ne va donner le
résultat escompté. Il est vrai que c'est parfois trop bref, cf. supra.
Ensuite, un des principes de la norme C, c'est de définir « bon », qui
s'y épelle « strictement conforme », et qui est en gros défini comme
« produit le même effet partout » ; après, on peut ergoter sur faux par
rapport à strictement conforme, toussa (surtout que pour compliquer, on
a la notion de « programme conforme » qui signifie « accepté par un
compilateur C conforme », ce qui inclut donc tous les programmes Fortran
et assembleur compilables par GCC...)
Un code peut être faux sous C99 et légitime sous C89.
C'est vrai mais c'est plutôt rare ; et c'est le plus souvent à cause de
l'utilisation de fonctionnalités comme le int implicite, qu'il vaut
mieux corriger le plus vite possible. Un autre problème peut venir des
noms de fonctions standards introduits par C99, et là aussi dans la
pratique, le programmeur va être obligé de suivre le train (c'est pareil
pour les mots clés de C++ ou les fonctions de Posix).
Après, je sais très bien qu'il y a des programmes écrits pour C89,
considérés comme bien écrits, qui posent problème lorsqu'on les passe
sur un compilateur C99 : le plus évident sont les (quelques) programmes
qui s'appuient sur la certitude que long est le plus grand type entier ;
cependant, je crois qu'ils servent beaucoup plus souvent d'alibi pour
cacher une multitude de programmes mal écrits, par exemple qui supposent
que long est un entier sur 32 bits.
Antoine
../.. et là où le problème devient brûlant,
c'est que sur les plateformes les plus répandues à l'heure actuelle, on
ne se rend pas compte du problème, car il se trouve que unsigned et long
ont la même représentation mémoire.
Sur une machine 16 bits, printf("%x", un_long) marche effectivement
(sauf cas /très/ particuliers), mais n'affiche pas le même résultat que
sur une machine « habituelle », et ÀMHA le résultat « faux » est celui
de la machine 16 bits.Perso je n'aime pas les phrases sèches: "ce code est faux".
Je crois qu'on avait compris. Cependant, il ne m'a pas semblé avoir
écrit cela, et sûrement pas dans le mien message auquel tu réponds.
Il lui manque quelque chose indiquant sous quelle hypothèse c'est
faux.
Mmm. D'abord, je pense faire en général un effort pour indiquer, au
moins sommairement, pourquoi je considère qu'un code ne va donner le
résultat escompté. Il est vrai que c'est parfois trop bref, cf. supra.
Ensuite, un des principes de la norme C, c'est de définir « bon », qui
s'y épelle « strictement conforme », et qui est en gros défini comme
« produit le même effet partout » ; après, on peut ergoter sur faux par
rapport à strictement conforme, toussa (surtout que pour compliquer, on
a la notion de « programme conforme » qui signifie « accepté par un
compilateur C conforme », ce qui inclut donc tous les programmes Fortran
et assembleur compilables par GCC...)Un code peut être faux sous C99 et légitime sous C89.
C'est vrai mais c'est plutôt rare ; et c'est le plus souvent à cause de
l'utilisation de fonctionnalités comme le int implicite, qu'il vaut
mieux corriger le plus vite possible. Un autre problème peut venir des
noms de fonctions standards introduits par C99, et là aussi dans la
pratique, le programmeur va être obligé de suivre le train (c'est pareil
pour les mots clés de C++ ou les fonctions de Posix).
Après, je sais très bien qu'il y a des programmes écrits pour C89,
considérés comme bien écrits, qui posent problème lorsqu'on les passe
sur un compilateur C99 : le plus évident sont les (quelques) programmes
qui s'appuient sur la certitude que long est le plus grand type entier ;
cependant, je crois qu'ils servent beaucoup plus souvent d'alibi pour
cacher une multitude de programmes mal écrits, par exemple qui supposent
que long est un entier sur 32 bits.
Antoine
Dans l'article <4bbb03ab$0$8366$,
Samuel DEVULDER écrit:Désolé. Sur http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf je
n'ai pas trouvé "binary exponent part" dans la description de printf
Ce n'était pas dans la description de printf (le format en question
revient à plusieurs endroits dans la norme, pas seulement avec
printf).
[Norme C, printf]The exponent always contains at least one digit, and only as manymore
digits as necessary to represent the decimal exponent of 2.
C'est horriblement mal dit, et AMHA, devrait être vu comme un défaut
(d'ailleurs, "binary exponent" est majoritaire).
Ce n'est pas le seul endroit où la norme est mal écrite, et
Dans l'article <4bbb03ab$0$8366$426a74cc@news.free.fr>,
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> écrit:
Désolé. Sur http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf je
n'ai pas trouvé "binary exponent part" dans la description de printf
Ce n'était pas dans la description de printf (le format en question
revient à plusieurs endroits dans la norme, pas seulement avec
printf).
[Norme C, printf]
The exponent always contains at least one digit, and only as manymore
digits as necessary to represent the decimal exponent of 2.
C'est horriblement mal dit, et AMHA, devrait être vu comme un défaut
(d'ailleurs, "binary exponent" est majoritaire).
Ce n'est pas le seul endroit où la norme est mal écrite, et
Dans l'article <4bbb03ab$0$8366$,
Samuel DEVULDER écrit:Désolé. Sur http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf je
n'ai pas trouvé "binary exponent part" dans la description de printf
Ce n'était pas dans la description de printf (le format en question
revient à plusieurs endroits dans la norme, pas seulement avec
printf).
[Norme C, printf]The exponent always contains at least one digit, and only as manymore
digits as necessary to represent the decimal exponent of 2.
C'est horriblement mal dit, et AMHA, devrait être vu comme un défaut
(d'ailleurs, "binary exponent" est majoritaire).
Ce n'est pas le seul endroit où la norme est mal écrite, et
Samuel DEVULDER écrivit :Antoine Leca a écrit :Je ne sais pas si dans ta pensée, le mot littérature ci-dessus avait ce
sens ;
Non je parlais du WEB. C'est clair depuis le début.
Je suis probablement un autre crétin, et certainement d'un autre siècle,
mais il ne m'est jamais venu à l'idée de lire « web » derrière
« littérature » ; même scientifique.
Je dis tout cela pour que comprennes un peu nos réactions, il n'y a pas
d'acrimonie, il y a juste parfois des différences d'interprétation.
Cela étant, la norme Posix que tu cites (site opengroup.org) est
effectivement un exemple de littérature au sens où je l'ai décris
(et je suppose que tu lus l'introduction de cette page, marqué CX).Oui peut être, mais en quoi le background change ce qu'on dit?
? Si quelqu'un te dit « Viens ici ! », est-ce que ta manière de réagir
change selon que
- il s'agit de ta mère (et tu as 5 ans) ;
- il s'agit d'un policier en tenue ;
- il s'agit d'une femme également « en tenue », vers Pigalle ;
- il s'agit d'un homme visiblement éméché.
Je n'ai pas dit que Vincent rentre dans une quelconque de ces cases !
Est-ce qu'un type ultra compétant est plus utile qu'un crétin quand
tous les deux disent "Ce code est faux, cf C99"?
Je me referai au conseil à propos des ouvrages de référence sur les
flottants.
écrire « compétent »).
Par ailleurs, il y a un « style Usenet » (que l'on rencontre aussi dans
les courriers électroniques), qui cultive un laconisme esthétique. Ce
style se perd ; les littéraires traditionalistes s'en réjouiront,
d'autres y voient la mort de Usenet ; mais il paraît difficile
aujourd'hui de le fustiger, surtout sur Usenet, il faut donc faire avec.Son conseil aurait été plus utile s'il avait filé l'url ou, mieux,
recopié le passage de la norme qui s'y réfère. Je l'ai fait, il dit que
ca parle de "binary exponent", je ne l'ai pas retrouvé. :-/
6.4.4.2 (et par conséquent 7.20.1.3)
Le fait que l'on trouve "decimal exponent of 2" dans 7.19.6.1 (et 7.24)
ne me semble pas cohérent. Mais c'est un avis purement personnel.
De toute manière, toute formulation aura une part d'ambiguïté.
Les documents auxquels tu fais référence insistent (et je le comprend
tout-à-fait, car ce n'est pas évident, surtout du fait du contexte) sur
la forme --en base 10, donc-- de la valeur de l'exposant ;
C'est ce qu'on veut savoir quand on fait un printf (le fait que ce soit
binaire en mémoire on s'en tamponne pour une sortie).
Pas exactement. C'est en fait tellement gros que tu le considère comme
évident, mais tu as _aussi_ besoin de savoir quelle est la base de la
numération (B=2 pour %a) pour comprendre comment interpréter le nombre
m×B^e ; en effet 16 aurait aussi bien pu être utilisé, car après tout
les chiffres de la mantisse sont en base 16, eux.
Par contre, c'est vrai que le fait que ce soit stocké en mémoire en base
2, 16 ou 10 n'a aucune espèce d'importance.
Samuel DEVULDER écrivit :
Antoine Leca a écrit :
Je ne sais pas si dans ta pensée, le mot littérature ci-dessus avait ce
sens ;
Non je parlais du WEB. C'est clair depuis le début.
Je suis probablement un autre crétin, et certainement d'un autre siècle,
mais il ne m'est jamais venu à l'idée de lire « web » derrière
« littérature » ; même scientifique.
Je dis tout cela pour que comprennes un peu nos réactions, il n'y a pas
d'acrimonie, il y a juste parfois des différences d'interprétation.
Cela étant, la norme Posix que tu cites (site opengroup.org) est
effectivement un exemple de littérature au sens où je l'ai décris
(et je suppose que tu lus l'introduction de cette page, marqué CX).
Oui peut être, mais en quoi le background change ce qu'on dit?
? Si quelqu'un te dit « Viens ici ! », est-ce que ta manière de réagir
change selon que
- il s'agit de ta mère (et tu as 5 ans) ;
- il s'agit d'un policier en tenue ;
- il s'agit d'une femme également « en tenue », vers Pigalle ;
- il s'agit d'un homme visiblement éméché.
Je n'ai pas dit que Vincent rentre dans une quelconque de ces cases !
Est-ce qu'un type ultra compétant est plus utile qu'un crétin quand
tous les deux disent "Ce code est faux, cf C99"?
Je me referai au conseil à propos des ouvrages de référence sur les
flottants.
écrire « compétent »).
Par ailleurs, il y a un « style Usenet » (que l'on rencontre aussi dans
les courriers électroniques), qui cultive un laconisme esthétique. Ce
style se perd ; les littéraires traditionalistes s'en réjouiront,
d'autres y voient la mort de Usenet ; mais il paraît difficile
aujourd'hui de le fustiger, surtout sur Usenet, il faut donc faire avec.
Son conseil aurait été plus utile s'il avait filé l'url ou, mieux,
recopié le passage de la norme qui s'y réfère. Je l'ai fait, il dit que
ca parle de "binary exponent", je ne l'ai pas retrouvé. :-/
6.4.4.2 (et par conséquent 7.20.1.3)
Le fait que l'on trouve "decimal exponent of 2" dans 7.19.6.1 (et 7.24)
ne me semble pas cohérent. Mais c'est un avis purement personnel.
De toute manière, toute formulation aura une part d'ambiguïté.
Les documents auxquels tu fais référence insistent (et je le comprend
tout-à-fait, car ce n'est pas évident, surtout du fait du contexte) sur
la forme --en base 10, donc-- de la valeur de l'exposant ;
C'est ce qu'on veut savoir quand on fait un printf (le fait que ce soit
binaire en mémoire on s'en tamponne pour une sortie).
Pas exactement. C'est en fait tellement gros que tu le considère comme
évident, mais tu as _aussi_ besoin de savoir quelle est la base de la
numération (B=2 pour %a) pour comprendre comment interpréter le nombre
m×B^e ; en effet 16 aurait aussi bien pu être utilisé, car après tout
les chiffres de la mantisse sont en base 16, eux.
Par contre, c'est vrai que le fait que ce soit stocké en mémoire en base
2, 16 ou 10 n'a aucune espèce d'importance.
Samuel DEVULDER écrivit :Antoine Leca a écrit :Je ne sais pas si dans ta pensée, le mot littérature ci-dessus avait ce
sens ;
Non je parlais du WEB. C'est clair depuis le début.
Je suis probablement un autre crétin, et certainement d'un autre siècle,
mais il ne m'est jamais venu à l'idée de lire « web » derrière
« littérature » ; même scientifique.
Je dis tout cela pour que comprennes un peu nos réactions, il n'y a pas
d'acrimonie, il y a juste parfois des différences d'interprétation.
Cela étant, la norme Posix que tu cites (site opengroup.org) est
effectivement un exemple de littérature au sens où je l'ai décris
(et je suppose que tu lus l'introduction de cette page, marqué CX).Oui peut être, mais en quoi le background change ce qu'on dit?
? Si quelqu'un te dit « Viens ici ! », est-ce que ta manière de réagir
change selon que
- il s'agit de ta mère (et tu as 5 ans) ;
- il s'agit d'un policier en tenue ;
- il s'agit d'une femme également « en tenue », vers Pigalle ;
- il s'agit d'un homme visiblement éméché.
Je n'ai pas dit que Vincent rentre dans une quelconque de ces cases !
Est-ce qu'un type ultra compétant est plus utile qu'un crétin quand
tous les deux disent "Ce code est faux, cf C99"?
Je me referai au conseil à propos des ouvrages de référence sur les
flottants.
écrire « compétent »).
Par ailleurs, il y a un « style Usenet » (que l'on rencontre aussi dans
les courriers électroniques), qui cultive un laconisme esthétique. Ce
style se perd ; les littéraires traditionalistes s'en réjouiront,
d'autres y voient la mort de Usenet ; mais il paraît difficile
aujourd'hui de le fustiger, surtout sur Usenet, il faut donc faire avec.Son conseil aurait été plus utile s'il avait filé l'url ou, mieux,
recopié le passage de la norme qui s'y réfère. Je l'ai fait, il dit que
ca parle de "binary exponent", je ne l'ai pas retrouvé. :-/
6.4.4.2 (et par conséquent 7.20.1.3)
Le fait que l'on trouve "decimal exponent of 2" dans 7.19.6.1 (et 7.24)
ne me semble pas cohérent. Mais c'est un avis purement personnel.
De toute manière, toute formulation aura une part d'ambiguïté.
Les documents auxquels tu fais référence insistent (et je le comprend
tout-à-fait, car ce n'est pas évident, surtout du fait du contexte) sur
la forme --en base 10, donc-- de la valeur de l'exposant ;
C'est ce qu'on veut savoir quand on fait un printf (le fait que ce soit
binaire en mémoire on s'en tamponne pour une sortie).
Pas exactement. C'est en fait tellement gros que tu le considère comme
évident, mais tu as _aussi_ besoin de savoir quelle est la base de la
numération (B=2 pour %a) pour comprendre comment interpréter le nombre
m×B^e ; en effet 16 aurait aussi bien pu être utilisé, car après tout
les chiffres de la mantisse sont en base 16, eux.
Par contre, c'est vrai que le fait que ce soit stocké en mémoire en base
2, 16 ou 10 n'a aucune espèce d'importance.
POSIX contient de nombreuses erreurs (il n'y a qu'à voir ce qui passe
sur la liste de l'Austin Group). Un autre exemple: la confusion entre
NULL et pointeur nul.
Son conseil aurait été plus utile s'il avait filé l'url ou, mieux,
recopié le passage de la norme qui s'y réfère. Je l'ai fait, il dit que
ca parle de "binary exponent", je ne l'ai pas retrouvé. :-/
7.20.1.3
[...]
a 0x or 0X, then a nonempty sequence of hexadecimal digits
optionally containing a decimal-point character, then an optional
binary exponent part as defined in 6.4.4.2;
^^^^^^^^^^^^^^^
POSIX contient de nombreuses erreurs (il n'y a qu'à voir ce qui passe
sur la liste de l'Austin Group). Un autre exemple: la confusion entre
NULL et pointeur nul.
Son conseil aurait été plus utile s'il avait filé l'url ou, mieux,
recopié le passage de la norme qui s'y réfère. Je l'ai fait, il dit que
ca parle de "binary exponent", je ne l'ai pas retrouvé. :-/
7.20.1.3
[...]
a 0x or 0X, then a nonempty sequence of hexadecimal digits
optionally containing a decimal-point character, then an optional
binary exponent part as defined in 6.4.4.2;
^^^^^^^^^^^^^^^
POSIX contient de nombreuses erreurs (il n'y a qu'à voir ce qui passe
sur la liste de l'Austin Group). Un autre exemple: la confusion entre
NULL et pointeur nul.
Son conseil aurait été plus utile s'il avait filé l'url ou, mieux,
recopié le passage de la norme qui s'y réfère. Je l'ai fait, il dit que
ca parle de "binary exponent", je ne l'ai pas retrouvé. :-/
7.20.1.3
[...]
a 0x or 0X, then a nonempty sequence of hexadecimal digits
optionally containing a decimal-point character, then an optional
binary exponent part as defined in 6.4.4.2;
^^^^^^^^^^^^^^^
Dans l'article <4bbb4fc0$0$23437$,
Samuel DEVULDER écrit:Encore faut il que ce soit une vraie erreur. Un bout de code
juste pour C89 pourra être considéré comme une erreur en C99.
C'est très rare.Peut-être, mais depuis être très rare quand devient une raison valable?
J'aurais pu ajouter que les codes qui ne compilent plus en C99
sont dans leur très grande majorité des codes sales (je ne connais
même pas de code "propre" qui provoque une erreur en C99).
Voici quelques exemples (non exhaustifs) de ce qui passait sous C89 mais
plus sous C99:
http://usenix.org/publications/login/2002-10/pdfs/mccluskey.pdf
Du code C89 sale... D'ailleurs, certains exemples sont mauvais même
en C99, e.g. oubli du "return 0;".
Si on râle à propos du code incorrect, et même sale, c'est pour
une bonne raison...
Autre truc. C99 est plus stricte que C89. Normalement C89 laisse passer
ce qui suit, mais pas C99:
char *s=...
unsigned char *t=s; /* erreur avec C99 */
Ça me semble valide en C99. Pourquoi ne le serait-ce pas?
Quand on ne précise pas le contexte, c'est celui de la norme C ISO.
La seule norme C est actuellement la version de 1999 (a.k.a. C99).
C89 n'est plus une norme, même si on peut en parler...Pourquoi ?
Parce que C89 n'est plus une norme.
Dans l'article <4bbb4fc0$0$23437$426a74cc@news.free.fr>,
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> écrit:
Encore faut il que ce soit une vraie erreur. Un bout de code
juste pour C89 pourra être considéré comme une erreur en C99.
C'est très rare.
Peut-être, mais depuis être très rare quand devient une raison valable?
J'aurais pu ajouter que les codes qui ne compilent plus en C99
sont dans leur très grande majorité des codes sales (je ne connais
même pas de code "propre" qui provoque une erreur en C99).
Voici quelques exemples (non exhaustifs) de ce qui passait sous C89 mais
plus sous C99:
http://usenix.org/publications/login/2002-10/pdfs/mccluskey.pdf
Du code C89 sale... D'ailleurs, certains exemples sont mauvais même
en C99, e.g. oubli du "return 0;".
Si on râle à propos du code incorrect, et même sale, c'est pour
une bonne raison...
Autre truc. C99 est plus stricte que C89. Normalement C89 laisse passer
ce qui suit, mais pas C99:
char *s=...
unsigned char *t=s; /* erreur avec C99 */
Ça me semble valide en C99. Pourquoi ne le serait-ce pas?
Quand on ne précise pas le contexte, c'est celui de la norme C ISO.
La seule norme C est actuellement la version de 1999 (a.k.a. C99).
C89 n'est plus une norme, même si on peut en parler...
Pourquoi ?
Parce que C89 n'est plus une norme.
Dans l'article <4bbb4fc0$0$23437$,
Samuel DEVULDER écrit:Encore faut il que ce soit une vraie erreur. Un bout de code
juste pour C89 pourra être considéré comme une erreur en C99.
C'est très rare.Peut-être, mais depuis être très rare quand devient une raison valable?
J'aurais pu ajouter que les codes qui ne compilent plus en C99
sont dans leur très grande majorité des codes sales (je ne connais
même pas de code "propre" qui provoque une erreur en C99).
Voici quelques exemples (non exhaustifs) de ce qui passait sous C89 mais
plus sous C99:
http://usenix.org/publications/login/2002-10/pdfs/mccluskey.pdf
Du code C89 sale... D'ailleurs, certains exemples sont mauvais même
en C99, e.g. oubli du "return 0;".
Si on râle à propos du code incorrect, et même sale, c'est pour
une bonne raison...
Autre truc. C99 est plus stricte que C89. Normalement C89 laisse passer
ce qui suit, mais pas C99:
char *s=...
unsigned char *t=s; /* erreur avec C99 */
Ça me semble valide en C99. Pourquoi ne le serait-ce pas?
Quand on ne précise pas le contexte, c'est celui de la norme C ISO.
La seule norme C est actuellement la version de 1999 (a.k.a. C99).
C89 n'est plus une norme, même si on peut en parler...Pourquoi ?
Parce que C89 n'est plus une norme.
Les machines ayant un CHAR_BIT de 12 sont rares elles aussi, et pourtant
j'en connais qui grognent quand ils voient écrit:
char buf[sizeof(double)];
parce que ça introduit des pad-bits pas super clairement.
Voici quelques exemples (non exhaustifs) de ce qui passait sous C89 mais
plus sous C99:
http://usenix.org/publications/login/2002-10/pdfs/mccluskey.pdf
Autre truc. C99 est plus stricte que C89. Normalement C89 laisse passer
ce qui suit, mais pas C99:
char *s=...
unsigned char *t=s; /* erreur avec C99 */
Autre trucs venant directement de K&R et devenus invalide au fil du
temps (et encore, je crois qu'on en discute encore de la validité de
telle constructions dans les milieux zotorizécomondi):
http://www.c-faq.com/struct/structhack.html
Les machines ayant un CHAR_BIT de 12 sont rares elles aussi, et pourtant
j'en connais qui grognent quand ils voient écrit:
char buf[sizeof(double)];
parce que ça introduit des pad-bits pas super clairement.
Voici quelques exemples (non exhaustifs) de ce qui passait sous C89 mais
plus sous C99:
http://usenix.org/publications/login/2002-10/pdfs/mccluskey.pdf
Autre truc. C99 est plus stricte que C89. Normalement C89 laisse passer
ce qui suit, mais pas C99:
char *s=...
unsigned char *t=s; /* erreur avec C99 */
Autre trucs venant directement de K&R et devenus invalide au fil du
temps (et encore, je crois qu'on en discute encore de la validité de
telle constructions dans les milieux zotorizécomondi):
http://www.c-faq.com/struct/structhack.html
Les machines ayant un CHAR_BIT de 12 sont rares elles aussi, et pourtant
j'en connais qui grognent quand ils voient écrit:
char buf[sizeof(double)];
parce que ça introduit des pad-bits pas super clairement.
Voici quelques exemples (non exhaustifs) de ce qui passait sous C89 mais
plus sous C99:
http://usenix.org/publications/login/2002-10/pdfs/mccluskey.pdf
Autre truc. C99 est plus stricte que C89. Normalement C89 laisse passer
ce qui suit, mais pas C99:
char *s=...
unsigned char *t=s; /* erreur avec C99 */
Autre trucs venant directement de K&R et devenus invalide au fil du
temps (et encore, je crois qu'on en discute encore de la validité de
telle constructions dans les milieux zotorizécomondi):
http://www.c-faq.com/struct/structhack.html
Antoine Leca a écrit :../.. et là où le problème devient brûlant,
c'est que sur les plateformes les plus répandues à l'heure actuelle, on
ne se rend pas compte du problème, car il se trouve que unsigned et long
ont la même représentation mémoire.
Oui. D'un coté on peut se demander si un problème qui ne se manifeste
pas est un vrai pb ou un faux pb.
Le tout est de savoir si le bénéfice de l'anticipation dépasse
le risque de casser un truc qui marchait.
Et encore j'ai cru voir que sur certains aspects, la
norme est imprécise et peut avoir deux interprétations distinctes.
Disons que la norme diminue le risque d'avoir un code qui ne produise
pas le même effet partout. C'est une probabilité, pas une certitude.
Après, je sais très bien qu'il y a des programmes écrits pour C89,
considérés comme bien écrits, qui posent problème lorsqu'on les passe
sur un compilateur C99 : le plus évident sont les (quelques) programmes
qui s'appuient sur la certitude que long est le plus grand type entier ;
C'était vrai et le reste pour beaucoup de monde.
Je sais pas pourquoi, mais j'ai toujours connu sizeof(long)=4 depuis
très très longtemps (et même à une époque où sizeof(int)==2).
Bon j'ai laissé tombé unix il y a
quelques années, mais même à l'époque sur le HP et les sparcs il me
semble que sizeof(long) était aussi lui à 4 (machines 64bits pourtant).
Antoine Leca a écrit :
../.. et là où le problème devient brûlant,
c'est que sur les plateformes les plus répandues à l'heure actuelle, on
ne se rend pas compte du problème, car il se trouve que unsigned et long
ont la même représentation mémoire.
Oui. D'un coté on peut se demander si un problème qui ne se manifeste
pas est un vrai pb ou un faux pb.
Le tout est de savoir si le bénéfice de l'anticipation dépasse
le risque de casser un truc qui marchait.
Et encore j'ai cru voir que sur certains aspects, la
norme est imprécise et peut avoir deux interprétations distinctes.
Disons que la norme diminue le risque d'avoir un code qui ne produise
pas le même effet partout. C'est une probabilité, pas une certitude.
Après, je sais très bien qu'il y a des programmes écrits pour C89,
considérés comme bien écrits, qui posent problème lorsqu'on les passe
sur un compilateur C99 : le plus évident sont les (quelques) programmes
qui s'appuient sur la certitude que long est le plus grand type entier ;
C'était vrai et le reste pour beaucoup de monde.
Je sais pas pourquoi, mais j'ai toujours connu sizeof(long)=4 depuis
très très longtemps (et même à une époque où sizeof(int)==2).
Bon j'ai laissé tombé unix il y a
quelques années, mais même à l'époque sur le HP et les sparcs il me
semble que sizeof(long) était aussi lui à 4 (machines 64bits pourtant).
Antoine Leca a écrit :../.. et là où le problème devient brûlant,
c'est que sur les plateformes les plus répandues à l'heure actuelle, on
ne se rend pas compte du problème, car il se trouve que unsigned et long
ont la même représentation mémoire.
Oui. D'un coté on peut se demander si un problème qui ne se manifeste
pas est un vrai pb ou un faux pb.
Le tout est de savoir si le bénéfice de l'anticipation dépasse
le risque de casser un truc qui marchait.
Et encore j'ai cru voir que sur certains aspects, la
norme est imprécise et peut avoir deux interprétations distinctes.
Disons que la norme diminue le risque d'avoir un code qui ne produise
pas le même effet partout. C'est une probabilité, pas une certitude.
Après, je sais très bien qu'il y a des programmes écrits pour C89,
considérés comme bien écrits, qui posent problème lorsqu'on les passe
sur un compilateur C99 : le plus évident sont les (quelques) programmes
qui s'appuient sur la certitude que long est le plus grand type entier ;
C'était vrai et le reste pour beaucoup de monde.
Je sais pas pourquoi, mais j'ai toujours connu sizeof(long)=4 depuis
très très longtemps (et même à une époque où sizeof(int)==2).
Bon j'ai laissé tombé unix il y a
quelques années, mais même à l'époque sur le HP et les sparcs il me
semble que sizeof(long) était aussi lui à 4 (machines 64bits pourtant).
Il y a eu une période (plus longue chez Sun qu'ailleurs) où les deux
modèles (ILP32 et LP64) cohabitaient (mal), justement à cause de la
base. Depuis un peu plus de 10 ans (LFS ?), il n'y a plus de débat dans
le monde Unix, c'est LP64 autrement dit longd bits.
Il y a eu une période (plus longue chez Sun qu'ailleurs) où les deux
modèles (ILP32 et LP64) cohabitaient (mal), justement à cause de la
base. Depuis un peu plus de 10 ans (LFS ?), il n'y a plus de débat dans
le monde Unix, c'est LP64 autrement dit longd bits.
Il y a eu une période (plus longue chez Sun qu'ailleurs) où les deux
modèles (ILP32 et LP64) cohabitaient (mal), justement à cause de la
base. Depuis un peu plus de 10 ans (LFS ?), il n'y a plus de débat dans
le monde Unix, c'est LP64 autrement dit longd bits.