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"?
Surtout que mon code est déjà dans un #define, et des #if ... dans un #define, ça ne me semble pas possible.
Cela s'écrit ?
Depuis C99, les seules représentations possibles pour les entiers sont binaires (6.2.6.2);
Ils ont gardé les représentation en complément à 1 et en signe + valeur absolue. Il y a une raison? Est-ce que c'est utilisé quelque part?
Oui, dans certains dinosaures de chez Unisys, à ce qu'il paraît, qui ont des compilos C ANSI. Je suis trop jeune et trop pauvre pour avoir accès à ces machines, cependant.
Antoine
En 20041008161305$047d@vinc17.org, Vincent Lefevre va escriure:
Surtout que mon code est déjà dans un #define, et des #if ... dans
un #define, ça ne me semble pas possible.
Cela s'écrit ?
Depuis C99, les seules représentations possibles pour les entiers
sont binaires (6.2.6.2);
Ils ont gardé les représentation en complément à 1 et en signe +
valeur absolue. Il y a une raison? Est-ce que c'est utilisé quelque
part?
Oui, dans certains dinosaures de chez Unisys, à ce qu'il paraît, qui ont des
compilos C ANSI. Je suis trop jeune et trop pauvre pour avoir accès à ces
machines, cependant.
Surtout que mon code est déjà dans un #define, et des #if ... dans un #define, ça ne me semble pas possible.
Cela s'écrit ?
Depuis C99, les seules représentations possibles pour les entiers sont binaires (6.2.6.2);
Ils ont gardé les représentation en complément à 1 et en signe + valeur absolue. Il y a une raison? Est-ce que c'est utilisé quelque part?
Oui, dans certains dinosaures de chez Unisys, à ce qu'il paraît, qui ont des compilos C ANSI. Je suis trop jeune et trop pauvre pour avoir accès à ces machines, cependant.
Antoine
Antoine Leca
En 20041008164722$, Vincent Lefevre va escriure:
Le problème est que tu supposes ici que toutes les expressions constantes sont évaluées à la traduction.
Non. Je suppose qu'elles sont évaluables, et que l'évaluation de celles qui en contrôlent d'autres n'aboutit pas à des comportements indéfinis (sinon, bien sûr, le comportement est indéfini, comme dans static i=1/0;)
Dans 2 || 1 / 0, le compilateur peut très bien choisir d'évaluer le || à l'exécution,
Admettons.
et de ne considérer que l'expression constante 1 / 0 à évaluer à la traduction
Non. Tu sautes le lien de causalité (les points de séquence).
Antoine
En 20041008164722$5b80@vinc17.org, Vincent Lefevre va escriure:
Le problème est que tu supposes ici que toutes les expressions
constantes sont évaluées à la traduction.
Non. Je suppose qu'elles sont évaluables, et que l'évaluation de celles qui
en contrôlent d'autres n'aboutit pas à des comportements indéfinis (sinon,
bien sûr, le comportement est indéfini, comme dans static i=1/0;)
Dans 2 || 1 / 0, le
compilateur peut très bien choisir d'évaluer le || à l'exécution,
Admettons.
et de ne considérer que l'expression constante 1 / 0 à évaluer à
la traduction
Non. Tu sautes le lien de causalité (les points de séquence).
Le problème est que tu supposes ici que toutes les expressions constantes sont évaluées à la traduction.
Non. Je suppose qu'elles sont évaluables, et que l'évaluation de celles qui en contrôlent d'autres n'aboutit pas à des comportements indéfinis (sinon, bien sûr, le comportement est indéfini, comme dans static i=1/0;)
Dans 2 || 1 / 0, le compilateur peut très bien choisir d'évaluer le || à l'exécution,
Admettons.
et de ne considérer que l'expression constante 1 / 0 à évaluer à la traduction
Non. Tu sautes le lien de causalité (les points de séquence).
Antoine
Vincent Lefevre
Dans l'article <ck3thv$36r$, Laurent Deniau écrit:
Vincent Lefevre wrote:
Je te retourne la question. Pourquoi utiliser unsigned long long?
Pour avoir au moins 64 bits (mais j'utilise plutôt les types de <stdint.h>). Eh oui, 32 bits, ça peut ne pas être suffisant. D'où l'idée du type générique.
Tu travailles sur une archi ou tu peux indexer un tableau (ou un segment) sur 64 bits et ou un long ne fait pas 64 bits?
Mon index_t n'indexe pas un tableau (il n'y a pas que les tableaux qu'on peut indexer).
[...]
index_t ne sert-il pas a indexer un tableau?
C'est ici un entier qui donne une position sur un segment (plus ou moins une abscisse relative, et qui peut aussi être vu comme un indice dans un groupe).
Alors je ne comprends pas ton besoin. Si c'est effectivement un offset dans un segment, ca doit tenir dans un registre, donc dans un long.
Ce n'est pas un offset, mais une position. Un segment, ça a une infinité de points, il y a donc une infinité de positions possibles. L'entier est un index r qui donne une abscisse de valeur r * a mod k, où a et k sont des constantes. Dans l'étude mathématique, r est potentiellement infini, mais dans l'algorithme en pratique, il est borné en fonction de paramètres fournis par l'utilisateur.
Dans l'article <ck3thv$36r$1@sunnews.cern.ch>,
Laurent Deniau <Laurent.Deniau@cern.ch> écrit:
Vincent Lefevre wrote:
Je te retourne la question. Pourquoi utiliser unsigned long long?
Pour avoir au moins 64 bits (mais j'utilise plutôt les types de
<stdint.h>). Eh oui, 32 bits, ça peut ne pas être suffisant. D'où
l'idée du type générique.
Tu travailles sur une archi ou tu peux indexer un tableau (ou un
segment) sur 64 bits et ou un long ne fait pas 64 bits?
Mon index_t n'indexe pas un tableau (il n'y a pas que les tableaux
qu'on peut indexer).
[...]
index_t ne sert-il pas a indexer un tableau?
C'est ici un entier qui donne une position sur un segment (plus
ou moins une abscisse relative, et qui peut aussi être vu comme
un indice dans un groupe).
Alors je ne comprends pas ton besoin. Si c'est effectivement un offset
dans un segment, ca doit tenir dans un registre, donc dans un long.
Ce n'est pas un offset, mais une position. Un segment, ça a une
infinité de points, il y a donc une infinité de positions possibles.
L'entier est un index r qui donne une abscisse de valeur r * a mod k,
où a et k sont des constantes. Dans l'étude mathématique, r est
potentiellement infini, mais dans l'algorithme en pratique, il est
borné en fonction de paramètres fournis par l'utilisateur.
Dans l'article <ck3thv$36r$, Laurent Deniau écrit:
Vincent Lefevre wrote:
Je te retourne la question. Pourquoi utiliser unsigned long long?
Pour avoir au moins 64 bits (mais j'utilise plutôt les types de <stdint.h>). Eh oui, 32 bits, ça peut ne pas être suffisant. D'où l'idée du type générique.
Tu travailles sur une archi ou tu peux indexer un tableau (ou un segment) sur 64 bits et ou un long ne fait pas 64 bits?
Mon index_t n'indexe pas un tableau (il n'y a pas que les tableaux qu'on peut indexer).
[...]
index_t ne sert-il pas a indexer un tableau?
C'est ici un entier qui donne une position sur un segment (plus ou moins une abscisse relative, et qui peut aussi être vu comme un indice dans un groupe).
Alors je ne comprends pas ton besoin. Si c'est effectivement un offset dans un segment, ca doit tenir dans un registre, donc dans un long.
Ce n'est pas un offset, mais une position. Un segment, ça a une infinité de points, il y a donc une infinité de positions possibles. L'entier est un index r qui donne une abscisse de valeur r * a mod k, où a et k sont des constantes. Dans l'étude mathématique, r est potentiellement infini, mais dans l'algorithme en pratique, il est borné en fonction de paramètres fournis par l'utilisateur.
Par exemple, si on considère k || 1 / 0 (j'ai pris volontairement quelque chose qui n'était pas constant devant le ||),
Soit k est constant (évaluable pendant la traduction), et alors le fait de cacher une constante derrière un identificateur ne fait que compliquer la discussion.
Soit il n'est pas constant, et on est hors du cadre.
Pourquoi hors du cadre?
Le verset 11 dit:
[#11] The semantic rules for the evaluation of a constant expression are the same as for nonconstant expressions.88)
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.
Tu te mords la queue dans ton explication: tu dis que les expressions non constantes n'ont pas de problèmes, seules les expressions constantes posent problème;
Je n'ai pas dis ça. Certaines expressions non constantes ont un comportement indéfini, et d'autres non.
hors tu concèdes que les expressions constantes s'évaluent selon les règles des expressions non constantes (qui ne posent pas de problème);
Ben non, les expressions non constantes peuvent avoir un comportement indéfini.
pourtant tu vois un problème...
Il y a effectivement problème avec ce que dit strictement la norme.
Dans l'article <ck6h7v$bnh$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
En 20041008162131$2e68@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 est constant (évaluable pendant la traduction), et alors le fait de
cacher une constante derrière un identificateur ne fait que compliquer la
discussion.
Soit il n'est pas constant, et on est hors du cadre.
Pourquoi hors du cadre?
Le verset 11 dit:
[#11] The semantic rules for the evaluation of a constant
expression are the same as for nonconstant expressions.88)
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.
Tu te mords la queue dans ton explication: tu dis que les
expressions non constantes n'ont pas de problèmes, seules les
expressions constantes posent problème;
Je n'ai pas dis ça. Certaines expressions non constantes ont un
comportement indéfini, et d'autres non.
hors tu concèdes que les expressions constantes s'évaluent selon les
règles des expressions non constantes (qui ne posent pas de
problème);
Ben non, les expressions non constantes peuvent avoir un comportement
indéfini.
pourtant tu vois un problème...
Il y a effectivement problème avec ce que dit strictement la norme.
Par exemple, si on considère k || 1 / 0 (j'ai pris volontairement quelque chose qui n'était pas constant devant le ||),
Soit k est constant (évaluable pendant la traduction), et alors le fait de cacher une constante derrière un identificateur ne fait que compliquer la discussion.
Soit il n'est pas constant, et on est hors du cadre.
Pourquoi hors du cadre?
Le verset 11 dit:
[#11] The semantic rules for the evaluation of a constant expression are the same as for nonconstant expressions.88)
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.
Tu te mords la queue dans ton explication: tu dis que les expressions non constantes n'ont pas de problèmes, seules les expressions constantes posent problème;
Je n'ai pas dis ça. Certaines expressions non constantes ont un comportement indéfini, et d'autres non.
hors tu concèdes que les expressions constantes s'évaluent selon les règles des expressions non constantes (qui ne posent pas de problème);
Ben non, les expressions non constantes peuvent avoir un comportement indéfini.
pourtant tu vois un problème...
Il y a effectivement problème avec ce que dit strictement la norme.
et de ne considérer que l'expression constante 1 / 0 à évaluer à la traduction
Non. Tu sautes le lien de causalité (les points de séquence).
Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne doit pas être évalué à la traduction, parce qu'on saute le lien de causalité (en effet, rien ne dit a priori si test() va être exécuté dans le programme). C'est bien ça?
Dans l'article <ck6hsv$e0i$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
En 20041008164722$5b80@vinc17.org, Vincent Lefevre va escriure:
et de ne considérer que l'expression constante 1 / 0 à évaluer à
la traduction
Non. Tu sautes le lien de causalité (les points de séquence).
Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne
doit pas être évalué à la traduction, parce qu'on saute le lien
de causalité (en effet, rien ne dit a priori si test() va être
exécuté dans le programme). C'est bien ça?
et de ne considérer que l'expression constante 1 / 0 à évaluer à la traduction
Non. Tu sautes le lien de causalité (les points de séquence).
Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne doit pas être évalué à la traduction, parce qu'on saute le lien de causalité (en effet, rien ne dit a priori si test() va être exécuté dans le programme). C'est bien ça?
|> Une optimisation ne change pas le fonctionnement observable.
Une optimisation peut très bien changer le fonctionnement observable, dans la mésure que le nouveau fonctionnement est aussi conforme.
-- James Kanze 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
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|> Une optimisation ne change pas le fonctionnement observable.
Une optimisation peut très bien changer le fonctionnement observable,
dans la mésure que le nouveau fonctionnement est aussi conforme.
--
James Kanze
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
|> Une optimisation ne change pas le fonctionnement observable.
Une optimisation peut très bien changer le fonctionnement observable, dans la mésure que le nouveau fonctionnement est aussi conforme.
-- James Kanze 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
James Kanze
"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.)
-- James Kanze 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
"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.)
--
James Kanze
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
|> 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.)
-- James Kanze 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
James Kanze
"Antoine Leca" writes:
|> Oui, dans certains dinosaures de chez Unisys, à ce qu'il paraît, qui |> ont des compilos C ANSI. Je suis trop jeune et trop pauvre pour |> avoir accès à ces machines, cependant.
Certains de ces dinosaures (avec des int de 36 bits, complément à 1) sont encore fabriqués aujourd'hui. D'autres (avec des int de 48 bits, dont 8 bits de rembourrage, magnitude signé) n'ont sorti de la production que depuis quelques années, et se trouvent encore par ce et par là.
-- James Kanze 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
"Antoine Leca" <root@localhost.gov> writes:
|> Oui, dans certains dinosaures de chez Unisys, à ce qu'il paraît, qui
|> ont des compilos C ANSI. Je suis trop jeune et trop pauvre pour
|> avoir accès à ces machines, cependant.
Certains de ces dinosaures (avec des int de 36 bits, complément à 1)
sont encore fabriqués aujourd'hui. D'autres (avec des int de 48 bits,
dont 8 bits de rembourrage, magnitude signé) n'ont sorti de la
production que depuis quelques années, et se trouvent encore par ce et
par là.
--
James Kanze
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, dans certains dinosaures de chez Unisys, à ce qu'il paraît, qui |> ont des compilos C ANSI. Je suis trop jeune et trop pauvre pour |> avoir accès à ces machines, cependant.
Certains de ces dinosaures (avec des int de 36 bits, complément à 1) sont encore fabriqués aujourd'hui. D'autres (avec des int de 48 bits, dont 8 bits de rembourrage, magnitude signé) n'ont sorti de la production que depuis quelques années, et se trouvent encore par ce et par là.
-- James Kanze 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
Vincent Lefevre
Dans l'article , James Kanze écrit:
Gabriel Dos Reis writes:
|> Une optimisation ne change pas le fonctionnement observable.
Une optimisation peut très bien changer le fonctionnement observable, dans la mésure que le nouveau fonctionnement est aussi conforme.
et également quand il y a du comportement indéfini (comme lire une variable non initialisée).
| Dans l'article , | Gabriel Dos Reis écrit: | | > Vincent Lefevre <vincent+ writes: | | > | Dans l'article , | > | Gabriel Dos Reis écrit: | > | | > | > Vincent Lefevre <vincent+ writes: | > | | > | > | Dans l'article <cjvbua$f0p$, | > | > | Charlie Gordon écrit: | > | | > | > | > 1 ? 0 : 1>>32 | > | > | | > | > | L'implémentation peut ne pas évaluer 1>>32. Mais elle peut aussi | > | > | l'évaluer en tant que sous-expression constante (sans chercher à | > | > | savoir si la valeur pourra être utilisée ou si elle ne sera jamais | > | > | utilisée), et dans ce cas, il y a comportement indéfini. | > | | > | > Bah non ; ce n'est pas un comportement possible de la machine | > | > abstraite. | > | | > | Sur quoi tu te bases? | | > Le machin que tu cites à tout le monde. | | Ça ne dit pas que ce n'est pas un comportement possible de la machine | abstraite.
Bah si.
Si la machine abstraite ne l'évalue pas, alors tu ne peux pas l'observer.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <m31xgagkpd.fsf@merlin.cs.tamu.edu>,
| Gabriel Dos Reis <gdr@cs.tamu.edu> écrit:
|
| > Vincent Lefevre <vincent+news@vinc17.org> writes:
|
| > | Dans l'article <m34ql8lgx0.fsf@merlin.cs.tamu.edu>,
| > | Gabriel Dos Reis <gdr@cs.tamu.edu> écrit:
| > |
| > | > Vincent Lefevre <vincent+news@vinc17.org> writes:
| > |
| > | > | Dans l'article <cjvbua$f0p$1@news.tiscali.fr>,
| > | > | Charlie Gordon <news@chqrlie.org> écrit:
| > |
| > | > | > 1 ? 0 : 1>>32
| > | > |
| > | > | L'implémentation peut ne pas évaluer 1>>32. Mais elle peut aussi
| > | > | l'évaluer en tant que sous-expression constante (sans chercher à
| > | > | savoir si la valeur pourra être utilisée ou si elle ne sera jamais
| > | > | utilisée), et dans ce cas, il y a comportement indéfini.
| > |
| > | > Bah non ; ce n'est pas un comportement possible de la machine
| > | > abstraite.
| > |
| > | Sur quoi tu te bases?
|
| > Le machin que tu cites à tout le monde.
|
| Ça ne dit pas que ce n'est pas un comportement possible de la machine
| abstraite.
Bah si.
Si la machine abstraite ne l'évalue pas, alors tu ne peux pas l'observer.
| Dans l'article , | Gabriel Dos Reis écrit: | | > Vincent Lefevre <vincent+ writes: | | > | Dans l'article , | > | Gabriel Dos Reis écrit: | > | | > | > Vincent Lefevre <vincent+ writes: | > | | > | > | Dans l'article <cjvbua$f0p$, | > | > | Charlie Gordon écrit: | > | | > | > | > 1 ? 0 : 1>>32 | > | > | | > | > | L'implémentation peut ne pas évaluer 1>>32. Mais elle peut aussi | > | > | l'évaluer en tant que sous-expression constante (sans chercher à | > | > | savoir si la valeur pourra être utilisée ou si elle ne sera jamais | > | > | utilisée), et dans ce cas, il y a comportement indéfini. | > | | > | > Bah non ; ce n'est pas un comportement possible de la machine | > | > abstraite. | > | | > | Sur quoi tu te bases? | | > Le machin que tu cites à tout le monde. | | Ça ne dit pas que ce n'est pas un comportement possible de la machine | abstraite.
Bah si.
Si la machine abstraite ne l'évalue pas, alors tu ne peux pas l'observer.
