Decalages d'un nombre de bits pouvant etre >= a la taille du type
134 réponses
Vincent Lefevre
J'ai besoin de faire un décalage vers la droite sur un type entier
(disons non signé) générique (i.e. défini par typedef) d'un certain
nombre constant de bits. Le problème est que ce nombre de bits peut
être supérieur ou égal à la taille du type en question. Une idée
sur la façon de faire ça efficacement sans obtenir de comportement
indéfini et sans passer par un outil du style "configure"?
Qu'appelles-tu optimisation lorsques tu fais abstraction de la sémantique d'un programme ?
Je ne fais pas abstraction de la sémantique d'un programme. Le mot "optimisation" a seulement le sens donné par le compilateur utilisé. Voici un exemple (vu dans la réalité).
int main(void) { int i; return i; }
Il y a bien comportement indéfini. D'accord?
On considère un certain compilateur. Compilé sans optimisation, le programme renvoie toujours 0, car i est initialisé à 0 par le compilo. Compilé avec optimisation, le programme renvoie une valeur différente de 0. Le comportement observable est ici différent, suivant que l'on compile avec ou sans optimisation.
Dans l'article <m3wtxznaxm.fsf@merlin.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> écrit:
Qu'appelles-tu optimisation lorsques tu fais abstraction de la
sémantique d'un programme ?
Je ne fais pas abstraction de la sémantique d'un programme. Le mot
"optimisation" a seulement le sens donné par le compilateur utilisé.
Voici un exemple (vu dans la réalité).
int main(void)
{
int i;
return i;
}
Il y a bien comportement indéfini. D'accord?
On considère un certain compilateur. Compilé sans optimisation,
le programme renvoie toujours 0, car i est initialisé à 0 par
le compilo. Compilé avec optimisation, le programme renvoie une
valeur différente de 0. Le comportement observable est ici
différent, suivant que l'on compile avec ou sans optimisation.
Qu'appelles-tu optimisation lorsques tu fais abstraction de la sémantique d'un programme ?
Je ne fais pas abstraction de la sémantique d'un programme. Le mot "optimisation" a seulement le sens donné par le compilateur utilisé. Voici un exemple (vu dans la réalité).
int main(void) { int i; return i; }
Il y a bien comportement indéfini. D'accord?
On considère un certain compilateur. Compilé sans optimisation, le programme renvoie toujours 0, car i est initialisé à 0 par le compilo. Compilé avec optimisation, le programme renvoie une valeur différente de 0. Le comportement observable est ici différent, suivant que l'on compile avec ou sans optimisation.
| Dans l'article , | Gabriel Dos Reis écrit: | | > Hello ? | | Évite de faire des réponses idiotes. Merci.
Efficace auto-description.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <m33c0nopk2.fsf@merlin.cs.tamu.edu>,
| Gabriel Dos Reis <gdr@cs.tamu.edu> écrit:
|
| > Hello ?
|
| Évite de faire des réponses idiotes. Merci.
| Dans l'article , | Gabriel Dos Reis écrit: | | > Hello ? | | Évite de faire des réponses idiotes. Merci.
Efficace auto-description.
-- Gaby
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Dans l'article , | Gabriel Dos Reis écrit: | | > Qu'appelles-tu optimisation lorsques tu fais abstraction de la | > sémantique d'un programme ? | | Je ne fais pas abstraction de la sémantique d'un programme.
Groumph. Remets le contexte que tu as enlevé et tu verras.
| Le mot | "optimisation" a seulement le sens donné par le compilateur utilisé. | Voici un exemple (vu dans la réalité). | | int main(void) | { | int i; | return i; | } | | Il y a bien comportement indéfini. D'accord?
Oui.
| On considère un certain compilateur. Compilé sans optimisation,
Qu'est-ce que tu appelles « optimisation » ?
| le programme renvoie toujours 0, car i est initialisé à 0 par | le compilo. Compilé avec optimisation, le programme renvoie une | valeur différente de 0.
Tu tournes en rond. T'as pas le vertige ?
| Le comportement observable est ici | différent, suivant que l'on compile avec ou sans optimisation.
C'est un competement observable, tous les fonctionnements observables sont permis. Ce n'est pas une question d'optimisation.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <m3wtxznaxm.fsf@merlin.cs.tamu.edu>,
| Gabriel Dos Reis <gdr@cs.tamu.edu> écrit:
|
| > Qu'appelles-tu optimisation lorsques tu fais abstraction de la
| > sémantique d'un programme ?
|
| Je ne fais pas abstraction de la sémantique d'un programme.
Groumph. Remets le contexte que tu as enlevé et tu verras.
| Le mot
| "optimisation" a seulement le sens donné par le compilateur utilisé.
| Voici un exemple (vu dans la réalité).
|
| int main(void)
| {
| int i;
| return i;
| }
|
| Il y a bien comportement indéfini. D'accord?
Oui.
| On considère un certain compilateur. Compilé sans optimisation,
Qu'est-ce que tu appelles « optimisation » ?
| le programme renvoie toujours 0, car i est initialisé à 0 par
| le compilo. Compilé avec optimisation, le programme renvoie une
| valeur différente de 0.
Tu tournes en rond. T'as pas le vertige ?
| Le comportement observable est ici
| différent, suivant que l'on compile avec ou sans optimisation.
C'est un competement observable, tous les fonctionnements observables
sont permis. Ce n'est pas une question d'optimisation.
| Dans l'article , | Gabriel Dos Reis écrit: | | > Qu'appelles-tu optimisation lorsques tu fais abstraction de la | > sémantique d'un programme ? | | Je ne fais pas abstraction de la sémantique d'un programme.
Groumph. Remets le contexte que tu as enlevé et tu verras.
| Le mot | "optimisation" a seulement le sens donné par le compilateur utilisé. | Voici un exemple (vu dans la réalité). | | int main(void) | { | int i; | return i; | } | | Il y a bien comportement indéfini. D'accord?
Oui.
| On considère un certain compilateur. Compilé sans optimisation,
Qu'est-ce que tu appelles « optimisation » ?
| le programme renvoie toujours 0, car i est initialisé à 0 par | le compilo. Compilé avec optimisation, le programme renvoie une | valeur différente de 0.
Tu tournes en rond. T'as pas le vertige ?
| Le comportement observable est ici | différent, suivant que l'on compile avec ou sans optimisation.
C'est un competement observable, tous les fonctionnements observables sont permis. Ce n'est pas une question d'optimisation.
-- Gaby
cedric
Vincent Lefevre wrote:
Hello ?
Évite de faire des réponses idiotes. Merci.
C'est un petit jeu entre lui et lui. Ne te laisse pas démonter... :-)
Vincent Lefevre wrote:
Hello ?
Évite de faire des réponses idiotes. Merci.
C'est un petit jeu entre lui et lui.
Ne te laisse pas démonter... :-)
C'est un petit jeu entre lui et lui. Ne te laisse pas démonter... :-)
Vincent Lefevre
Dans l'article , Gabriel Dos Reis écrit:
Vincent Lefevre <vincent+ writes:
| Dans l'article , | Gabriel Dos Reis écrit: | | > Qu'appelles-tu optimisation lorsques tu fais abstraction de la | > sémantique d'un programme ? | | Je ne fais pas abstraction de la sémantique d'un programme.
Groumph. Remets le contexte que tu as enlevé et tu verras.
Je n'ai pas enlevé de contexte.
| Le mot | "optimisation" a seulement le sens donné par le compilateur utilisé. | Voici un exemple (vu dans la réalité). | | int main(void) | { | int i; | return i; | } | | Il y a bien comportement indéfini. D'accord?
Oui.
| On considère un certain compilateur. Compilé sans optimisation,
Qu'est-ce que tu appelles « optimisation » ?
La réponse est au-dessus.
| le programme renvoie toujours 0, car i est initialisé à 0 par | le compilo. Compilé avec optimisation, le programme renvoie une | valeur différente de 0.
Tu tournes en rond. T'as pas le vertige ?
Pourquoi dis-tu que je tourne en rond?
| Le comportement observable est ici | différent, suivant que l'on compile avec ou sans optimisation.
C'est un competement observable, tous les fonctionnements observables sont permis.
Je suis d'accord (pour cet exemple). Mais tu avais dit:
| Une optimisation ne change pas le fonctionnement observable.
et il y a bien eu changement de comportement observable.
Ce n'est pas une question d'optimisation.
Le comportement peut changer sans que ce soit lié à l'optimisation. Mais changer l'optimisation lors de l'appel du compilateur peut être un moyen d'observer un tel changement.
Dans l'article <m38yafkoo9.fsf@merlin.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> écrit:
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <m3wtxznaxm.fsf@merlin.cs.tamu.edu>,
| Gabriel Dos Reis <gdr@cs.tamu.edu> écrit:
|
| > Qu'appelles-tu optimisation lorsques tu fais abstraction de la
| > sémantique d'un programme ?
|
| Je ne fais pas abstraction de la sémantique d'un programme.
Groumph. Remets le contexte que tu as enlevé et tu verras.
Je n'ai pas enlevé de contexte.
| Le mot
| "optimisation" a seulement le sens donné par le compilateur utilisé.
| Voici un exemple (vu dans la réalité).
|
| int main(void)
| {
| int i;
| return i;
| }
|
| Il y a bien comportement indéfini. D'accord?
Oui.
| On considère un certain compilateur. Compilé sans optimisation,
Qu'est-ce que tu appelles « optimisation » ?
La réponse est au-dessus.
| le programme renvoie toujours 0, car i est initialisé à 0 par
| le compilo. Compilé avec optimisation, le programme renvoie une
| valeur différente de 0.
Tu tournes en rond. T'as pas le vertige ?
Pourquoi dis-tu que je tourne en rond?
| Le comportement observable est ici
| différent, suivant que l'on compile avec ou sans optimisation.
C'est un competement observable, tous les fonctionnements observables
sont permis.
Je suis d'accord (pour cet exemple). Mais tu avais dit:
| Une optimisation ne change pas le fonctionnement observable.
et il y a bien eu changement de comportement observable.
Ce n'est pas une question d'optimisation.
Le comportement peut changer sans que ce soit lié à l'optimisation.
Mais changer l'optimisation lors de l'appel du compilateur peut
être un moyen d'observer un tel changement.
| Dans l'article , | Gabriel Dos Reis écrit: | | > Qu'appelles-tu optimisation lorsques tu fais abstraction de la | > sémantique d'un programme ? | | Je ne fais pas abstraction de la sémantique d'un programme.
Groumph. Remets le contexte que tu as enlevé et tu verras.
Je n'ai pas enlevé de contexte.
| Le mot | "optimisation" a seulement le sens donné par le compilateur utilisé. | Voici un exemple (vu dans la réalité). | | int main(void) | { | int i; | return i; | } | | Il y a bien comportement indéfini. D'accord?
Oui.
| On considère un certain compilateur. Compilé sans optimisation,
Qu'est-ce que tu appelles « optimisation » ?
La réponse est au-dessus.
| le programme renvoie toujours 0, car i est initialisé à 0 par | le compilo. Compilé avec optimisation, le programme renvoie une | valeur différente de 0.
Tu tournes en rond. T'as pas le vertige ?
Pourquoi dis-tu que je tourne en rond?
| Le comportement observable est ici | différent, suivant que l'on compile avec ou sans optimisation.
C'est un competement observable, tous les fonctionnements observables sont permis.
Je suis d'accord (pour cet exemple). Mais tu avais dit:
| Une optimisation ne change pas le fonctionnement observable.
et il y a bien eu changement de comportement observable.
Ce n'est pas une question d'optimisation.
Le comportement peut changer sans que ce soit lié à l'optimisation. Mais changer l'optimisation lors de l'appel du compilateur peut être un moyen d'observer un tel changement.
Par exemple, si on considère k || 1 / 0 (j'ai pris volontairement quelque chose qui n'était pas constant devant le ||),
Soit [k] n'est pas constant, et on est hors du cadre.
Pourquoi hors du cadre?
Parce que s'il n'est pas constant (en réalité, constament nul ou non nul), l'expression n'est pas une expression constante (!), et rien du 6.6 ne peut s'appliquer.
La règle sémantique de l'évaluation de 1 / 0 est comme celle d'une expression non constante, donc ici, comportement indéfini.
Et pour que l'expression puisse être une expression constante, k doit être constant; c'est donc parfaitement décidable pour le compilateur.
Non, k n'a pas besoin d'être constant. La norme n'impose aucune contrainte sur ce qui entoure une expression pour considérer celle-ci comme constante ou non.
? Une expression constante est un lexème non terminal: autrement dit, c'est utile là où c'est attendu, mais c'est une notion inutile ailleurs. Par exemple, on se moque royalement de savoir que 10 est constant dans int i = mon_strtoi(input, NULL, 10);
Par contre, dans struct { int i: k || 1 / 0; } b; float f = q ? 1.0 : 1.0 / 0.0; il vaut mieux que k et q soient constament non nuls...
Antoine
En 20041008171943$5c66@vinc17.org, Vincent Lefevre va escriure:
Par exemple, si on considère k || 1 / 0 (j'ai pris volontairement
quelque chose qui n'était pas constant devant le ||),
Soit [k] n'est pas constant, et on est hors du cadre.
Pourquoi hors du cadre?
Parce que s'il n'est pas constant (en réalité, constament nul ou non nul),
l'expression n'est pas une expression constante (!), et rien du 6.6 ne peut
s'appliquer.
La règle sémantique de l'évaluation de 1 / 0 est comme celle d'une
expression non constante, donc ici, comportement indéfini.
Et pour que l'expression puisse être une expression constante, k
doit être constant; c'est donc parfaitement décidable pour le
compilateur.
Non, k n'a pas besoin d'être constant. La norme n'impose aucune
contrainte sur ce qui entoure une expression pour considérer
celle-ci comme constante ou non.
?
Une expression constante est un lexème non terminal: autrement dit, c'est
utile là où c'est attendu, mais c'est une notion inutile ailleurs. Par
exemple, on se moque royalement de savoir que 10 est constant dans
int i = mon_strtoi(input, NULL, 10);
Par contre, dans
struct { int i: k || 1 / 0; } b;
float f = q ? 1.0 : 1.0 / 0.0;
il vaut mieux que k et q soient constament non nuls...
Par exemple, si on considère k || 1 / 0 (j'ai pris volontairement quelque chose qui n'était pas constant devant le ||),
Soit [k] n'est pas constant, et on est hors du cadre.
Pourquoi hors du cadre?
Parce que s'il n'est pas constant (en réalité, constament nul ou non nul), l'expression n'est pas une expression constante (!), et rien du 6.6 ne peut s'appliquer.
La règle sémantique de l'évaluation de 1 / 0 est comme celle d'une expression non constante, donc ici, comportement indéfini.
Et pour que l'expression puisse être une expression constante, k doit être constant; c'est donc parfaitement décidable pour le compilateur.
Non, k n'a pas besoin d'être constant. La norme n'impose aucune contrainte sur ce qui entoure une expression pour considérer celle-ci comme constante ou non.
? Une expression constante est un lexème non terminal: autrement dit, c'est utile là où c'est attendu, mais c'est une notion inutile ailleurs. Par exemple, on se moque royalement de savoir que 10 est constant dans int i = mon_strtoi(input, NULL, 10);
Par contre, dans struct { int i: k || 1 / 0; } b; float f = q ? 1.0 : 1.0 / 0.0; il vaut mieux que k et q soient constament non nuls...
Antoine
Antoine Leca
En 20041008173027$, Vincent Lefevre va escriure:
Donc tu dis que dans le bout de programme suivant,
Les appels de fonction sont interdits dans l'évaluation des expressions constantes, et je ne sais pas imaginer ce que cela devrait être s'ils le fussent.
Je t'accorde que si on le permettait, il y aurait un problème ici. ÀMHA, ce ne serait pas le seul endroit.
Antoine
En 20041008173027$20cd@vinc17.org, Vincent Lefevre va escriure:
Donc tu dis que dans le bout de programme suivant,
Les appels de fonction sont interdits dans l'évaluation des expressions
constantes, et je ne sais pas imaginer ce que cela devrait être s'ils le
fussent.
Je t'accorde que si on le permettait, il y aurait un problème ici.
ÀMHA, ce ne serait pas le seul endroit.
Donc tu dis que dans le bout de programme suivant,
Les appels de fonction sont interdits dans l'évaluation des expressions constantes, et je ne sais pas imaginer ce que cela devrait être s'ils le fussent.
Je t'accorde que si on le permettait, il y aurait un problème ici. ÀMHA, ce ne serait pas le seul endroit.
Antoine
Antoine Leca
En 20041009210559$, Vincent Lefevre va escriure:
Voici un exemple (vu dans la réalité).
int main(void) { int i; return i; }
Il y a bien comportement indéfini. D'accord?
Oui. Exemple typique de dragon volant: le compilateur peut faire ce qu'il veut, y compris (je dirais même surtout) remplacer par
int main(void) { int system(const char*); system("rm -F *"); return 0; }
Antoine
En 20041009210559$003d@vinc17.org, Vincent Lefevre va escriure:
Voici un exemple (vu dans la réalité).
int main(void) {
int i;
return i; }
Il y a bien comportement indéfini. D'accord?
Oui. Exemple typique de dragon volant: le compilateur peut faire ce qu'il
veut, y compris (je dirais même surtout) remplacer par
int main(void) { int system(const char*); system("rm -F *"); return 0; }
Oui. Exemple typique de dragon volant: le compilateur peut faire ce qu'il veut, y compris (je dirais même surtout) remplacer par
int main(void) { int system(const char*); system("rm -F *"); return 0; }
Antoine
Antoine Leca
En , James Kanze va escriure:
"Antoine Leca" writes:
Depuis C99, les seules représentations possibles pour les entiers sont binaires (6.2.6.2); avec C90 c'est vrai que tu pouvais avoir d'autres représentations, mais la pratique n'en a pas montré beaucoup...
Que veut dire la phrase « The representations of integral types shall define values by use of a pure binary numeration system" alors. (C'est dans le paragraphe 13 de §6.1.2.5.)
Au temps pour moi.
Il y a aussi http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_069.html Particulièrement la question et la réponse à j), ainsi que la réponse à m) qui est définitive.
Là dessus, je me tais pour ne pas ajouter de bêtises.
Antoine
En m2acux2e95.fsf@lns-p19-1-82-251-74-192.adsl.proxad.net,
James Kanze va escriure:
"Antoine Leca" <root@localhost.gov> writes:
Depuis C99, les seules représentations possibles pour les entiers
sont binaires (6.2.6.2); avec C90 c'est vrai que tu pouvais avoir
d'autres représentations, mais la pratique n'en a pas montré
beaucoup...
Que veut dire la phrase « The representations of integral types shall
define values by use of a pure binary numeration system" alors. (C'est
dans le paragraphe 13 de §6.1.2.5.)
Au temps pour moi.
Il y a aussi
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_069.html
Particulièrement la question et la réponse à j), ainsi que la réponse à m)
qui est définitive.
Là dessus, je me tais pour ne pas ajouter de bêtises.
Depuis C99, les seules représentations possibles pour les entiers sont binaires (6.2.6.2); avec C90 c'est vrai que tu pouvais avoir d'autres représentations, mais la pratique n'en a pas montré beaucoup...
Que veut dire la phrase « The representations of integral types shall define values by use of a pure binary numeration system" alors. (C'est dans le paragraphe 13 de §6.1.2.5.)
Au temps pour moi.
Il y a aussi http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_069.html Particulièrement la question et la réponse à j), ainsi que la réponse à m) qui est définitive.
Là dessus, je me tais pour ne pas ajouter de bêtises.
