Vincent Lefevre <vincent+***@vinc17.org> writes:
| Dans l'article <***@merlin.cs.tamu.edu>,
| Gabriel Dos Reis <***@cs.tamu.edu> écrit:
|
| > Vincent Lefevre <vincent+***@vinc17.org> writes:
|
| > | Dans l'article <***@merlin.cs.tamu.edu>,
| > | Gabriel Dos Reis <***@cs.tamu.edu> écrit:
| > | > Le bottom line est que les expressions constantes ne sont évaluées par
| > | > la machine abstraite que lorsque nécessaire.
| > |
| > | Où est-ce que la norme dit cela?
|
| > Tu as certainement lu « le bottom line », non ?
|
| Qu'est-ce que c'est que le "bottom line"? (Cette expression n'est
| mentionnée nulle part dans la norme, ni dans mon dictionnaire
| d'anglais.)
C'est dommage qu'ils pratiquent plus les bonnets d'âne. Tu fais quoi
dans la vie déjà ?
| > | Le 6.6#2 dit:
| > |
| > | [#2] A constant expression can be evaluated during
| > | translation rather than runtime, and accordingly may be used
| > | in any place that a constant may be.
| > |
| > | Pas de "nécessaire" ici.
|
| > mais en ce qui concerne le fonctionnement de la machine abstraite, le
| > compilateur ne peut pas introduire un fonctionnement indéfini là où
| > cela n'existe pas.
|
| Si j'écris
|
| if (cond)
| x = 1 / 0;
|
| et que la norme autorise à ce que le 1 / 0 soit évalué à la traduction
| (ce n'est pas ce que dit le 6.6#2 dans la mesure où toutes les
| contraintes sont vérifiées?), alors on ne peut pas nier la possibilité
| d'un fonctionnement indéfini lors de cette évaluation. Et ceci, même
| si cond est toujours faux dans la pratique.
Du point de vue de la machine abstraite, il n'y a de fonctionnement
indéfini que si l'expression « cond » est vraie. Donc quoi que fasse
ton compilateur, il ne peut introduire de fonctionnement indéfini là
où il n'y en a pas. C'est compilqué pour toi ?
| > Du point de vue la machine abstraite, cela se passe comme si
| > l'évaluation n'a lieu que si c'est nécessaire
|
| > Semantics
|
| > [#5] An expression that evaluates to a constant is required
| > in several contexts. If a floating expression is evaluated
| > in the translation environment, the arithmetic precision and
| > range shall be at least as great as if the expression were
| > being evaluated in the execution environment.
|
| > [...]
|
| > [#11] The semantic rules for the evaluation of a constant
| > expression are the same as for nonconstant expressions.97)
|
| Je n'ai jamais contredit le #11.
Bah si. Tu crois que tu peux évaluer la condition d'une branche if
même si elle n'est jamais prises.
| Par exemple, dans l'exemple ci-dessus
|
| if (cond)
| x = 1 / 0;
|
| l'évaluation de 1 / 0 génère un comportement indéfini, comme pour
parc que cond est vraie ?
| une expression non constante. Tout ce que je fais, c'est *ajouter*
| des choses à la traduction, autorisées par le 6.6#2.
Bah non, tu changes la sémantique du programme.
| > | Ou alors par "machine abstraite",
|
| > oui, je parle de la machine abstraite
|
| > | tu entends
| > | seulement ce qui se passe à l'exécution. Mais ce qui m'intéresse là,
|
| > La norme C décrit le fonctionnement d'une machine abstraite avec des
| > paramètres.
|
| Mais la norme décrit aussi comment se passe la traduction (il peut
| y avoir des diagnostics, etc.).
et as-tu bien lu ce qu'elle décrit ou te contentes-tu de dire qu'elle
décrit comment se passe la traduction.
| > [#3] A program that is correct in all other aspects,
| > operating on correct data, containing unspecified behavior
| > shall be a correct program and act in accordance with
| > 5.1.2.3.
|
|
| > 5.1.2.3 Program execution
|
| > [#1] The semantic descriptions in this International
| > Standard describe the behavior of an abstract machine in
| > which issues of optimization are irrelevant.
|
| > | c'est ce qui se passe à la traduction.
|
| > Mauvaise question.
|
| Pourquoi mauvaise question?
Parce qu'elle en est une.
| > [#11] The semantic rules for the evaluation of a constant
| > expression are the same as for nonconstant expressions.97)
|
| > Ah.
|
| Cf ma remarque plus haut concernant le #11.
|
| [...]
| > | > La notion de fonctionnement indéfini est fondamentalement une *notion
| > | > « runtime »*. Il peut apparaître en translation-time uniquement
| > | > lorsque l'implémentation peut prouver que tous les chemins d'éxécution
| > | > passent par ce fonctionnement.
| > |
| > | Où est-ce que la norme dit cela? À la rigueur, c'est le 6.6#11 qui s'y
| > | rapproche le plus, mais il parle de la sémantique de l'évaluation d'une
| > | expression constante et non de la sémantique du programme (ce n'est pas
| > | pareil).
|
| > Voir ci-dessus. 6.6/11 ne fait que rappeler ce qui a déjà en 5.1.2.3/1.
| > C'est si dur pour toi à comprendre ?
|
| Je ne vois pas en quoi le 5.1.2.3/1 change quelque chose.
ce paragraphe te dit que tout ce que la norme te dit à propos de la
sémantique, c'est pour la machine abstraitre. Mais toi tu veux refuse
de comprendre que ce qui importe c'est comment la machine abtraitre
est censée fonctionner.
| Note que le
| 5.1.2.3 est "Program execution" alors que le problème que je signale
| se passe à la traduction.
Mais ce que tu ne comprends pas, c'est que ton programme est
interprété selon les règles sémantiques qui elles sont à
l'éxécution.
1. Scope
[#1] This International Standard specifies the form and
establishes the interpretation of programs written in the C
programming language.1) It specifies
-- the representation of C programs;
-- the syntax and constraints of the C language;
-- the semantic rules for interpreting C programs;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| Dès lors qu'il y a un comportement indéfini
| intervenant quelque part (dans n'importe quelle phase de traduction),
| le comportement à l'exécution (s'il y a exécution) est indéfini, non?
Et la question est : y a-t-il fonctionnement indéfini dans ton
programme
if (cond)
x = 1/ 0;
La réponse est oui si et seulement si il existe un chemin d'exécution
qui passe par cette instruction et pour lequel cond évalue à vrai. Si
ton compilateur peut le prouver alors il peut faire kidnapper ta
cervelle. Autrement, non (à moins que tu aies d'autres fonctionnements
indéfinis ailleurs).
| > | En tout cas, il y a au moins un compilateur qui évalue les expressions
| > | constantes à la traduction même si leurs valeurs ne seront jamais
| > | utilisées: MSVC6.
|
| > Et tu crois que cela pourve quoi ? La dernière fois que j'ai vérifié
| > MSVC6 n'est pas une référence en matière de conformité de traducteur
| > de programme C.
|
| > | En particulier, la compilation de MPFR échoue parce
| > | qu'à un endroit, on renvoie 0.0/0.0 (dans mpfr_get_d, qui converti un
|
| > Si tu utilises un compilateur qui implémente la sémantique de C90 dans
| > ce cas, tu n'as pas grand chose à dire.
|
| Quelle était la sémantique de C90? C'est peut-être la raison...
Pratiquement rien n'était imposé sur les floating points.
(désolé je n'ai plus de copies de C90 et la seule que l'AFNOR m'a
envoyée a été kidnappée par quelqu'un. J'ai demandé à John la semaine
dernière s'il y avait un diff ou une copie electronique, il m'a
répondu "non").
Le support de fp dans C99 est une nouveau par rapport à C90 et K+R.
| (Je n'ai pas accès au compilo, mais de toute façon, que ce soit
| un bug du compilo ou que ce soit parce que la sémantique de C90
| est implémentée, ça ne change pas grand chose pour la compilation
| de MPFR.)
Écoute, si tu écris des programmes buggués, c'est ton problème.
| > | nombre MPFR en double, dans le cas où le nombre MPFR est un NaN). Je
| > | précise que le 0.0/0.0 n'est pas utilisé dans une initialisation.
|
| > Si tu veux la sémantique C99 utilise C99 -- NAN.
|
| C'est une possibilité, maintenant qu'on s'est réellement séparé de GMP
| (les développeurs de GMP ne voulaient pas). Mais ça ne résout pas le
| fond du problème, car la macro NAN n'est pas forcément définie. Dans
| ce cas, qu'est-ce que tu suggères pour renvoyer un signaling NaN?
Ce que ton compilateur dit (en supposant qu'il support les sNaN).
C'est pas tous les compilateurs qui le supportent, et c'est pas
forcément surpporté sur toutes les machines.
-- Gaby