Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
boutisme et opérations sur les entiers
30 views
Skip to first unread message
Manuel Pégourié-Gonnard
Dec 3, 2012, 3:28:24 AM12/3/12
to
Bonjour,
Bon, c'est un point que je crois avoir compris, mais j'aimerais juste
une confirmation (ou infirmation... et/ou précision) de votre part.
Considérons le programme suivant. Ai-je raison de croire que les
trois premiers paragraphes (jusqu'au commentaire « maintenant on dépend
du boutisme ») donnent un résultat indépendant du boutisme de la
plateforme ? Entre le deuxième et le troisième paragraphe, l'un vous
paraît-il plus lisible que l'autre ?
Merci,
Manuel.
#include <stdio.h>
#include <stdint.h>
#include <string.h>
int main(void)
{
const uint32_t a = 0xA4A3A2A1;
uint16_t b;
/* 1. On veut récupérer les 2 octets de poids fort de a dans b */
b = a >> 16;
printf("Poids fort\nb = 0x%X\n", b);
/* 2. Maintenant les deux octets de poids faible */
b = a & 0xFFFF;
printf("Poids faible\nb = 0x%X\n", b);
/* 3. Pareil, écrit autrement */
b = a;
printf("Poids faible 2\nb = 0x%X\n", b);
/*
* À partir de maintenant les résultats dépendent du boutisme
*/
memcpy(&b, &a, 2);
printf("Premiers octets\nb = 0x%X\n", b);
memcpy(&b, ((char *) &a) + 2, 2);
printf("Derniers octets\nb = 0x%X\n", b);
return 0;
}
--
Manuel Pégourié-Gonnard - http://people.math.jussieu.fr/~mpg/
Bon, c'est un point que je crois avoir compris, mais j'aimerais juste
une confirmation (ou infirmation... et/ou précision) de votre part.
Considérons le programme suivant. Ai-je raison de croire que les
trois premiers paragraphes (jusqu'au commentaire « maintenant on dépend
du boutisme ») donnent un résultat indépendant du boutisme de la
plateforme ? Entre le deuxième et le troisième paragraphe, l'un vous
paraît-il plus lisible que l'autre ?
Merci,
Manuel.
#include <stdio.h>
#include <stdint.h>
#include <string.h>
int main(void)
{
const uint32_t a = 0xA4A3A2A1;
uint16_t b;
/* 1. On veut récupérer les 2 octets de poids fort de a dans b */
b = a >> 16;
printf("Poids fort\nb = 0x%X\n", b);
/* 2. Maintenant les deux octets de poids faible */
b = a & 0xFFFF;
printf("Poids faible\nb = 0x%X\n", b);
/* 3. Pareil, écrit autrement */
b = a;
printf("Poids faible 2\nb = 0x%X\n", b);
/*
* À partir de maintenant les résultats dépendent du boutisme
*/
memcpy(&b, &a, 2);
printf("Premiers octets\nb = 0x%X\n", b);
memcpy(&b, ((char *) &a) + 2, 2);
printf("Derniers octets\nb = 0x%X\n", b);
return 0;
}
--
Manuel Pégourié-Gonnard - http://people.math.jussieu.fr/~mpg/
Lucas Levrel
Dec 3, 2012, 3:52:14 AM12/3/12
to
Le 3 dￜcembre 2012, Manuel Pￜgouriￜ-Gonnard a ￜcrit :
> Considï¿œrons le programme suivant. Ai-je raison de croire que les
> trois premiers paragraphes (jusqu'au commentaire ￜ maintenant on dￜpend
> du boutismeￜￜ) donnent un rￜsultat indￜpendant du boutisme de la
> plateforme ?
Je suis de ton avis, mais je laisse aux experts la confirmation.
> Entre le deuxiï¿œme et le troisiï¿œme paragraphe, l'un vous
> paraï¿œt-il plus lisible que l'autre ?
sera lu avant l'instruction. Sinon, le nￜ 2 me semble mieux (on n'a pas
besoin de se rï¿œfï¿œrer au type des variables pour comprendre).
--
LL
> Considï¿œrons le programme suivant. Ai-je raison de croire que les
> trois premiers paragraphes (jusqu'au commentaire ￜ maintenant on dￜpend
> du boutismeￜￜ) donnent un rￜsultat indￜpendant du boutisme de la
> plateforme ?
Je suis de ton avis, mais je laisse aux experts la confirmation.
> Entre le deuxiï¿œme et le troisiï¿œme paragraphe, l'un vous
> paraï¿œt-il plus lisible que l'autre ?
> /* 2. Maintenant les deux octets de poids faible */
> b = a & 0xFFFF;
> printf("Poids faible\nb = 0x%X\n", b);
>
> /* 3. Pareil, ï¿œcrit autrement */
> b = a & 0xFFFF;
> printf("Poids faible\nb = 0x%X\n", b);
>
> b = a;
> printf("Poids faible 2\nb = 0x%X\n", b);
Dans tout bon programme, c'est ï¿œquivalent puisque c'est le commentaire qui
> printf("Poids faible 2\nb = 0x%X\n", b);
sera lu avant l'instruction. Sinon, le nￜ 2 me semble mieux (on n'a pas
besoin de se rï¿œfï¿œrer au type des variables pour comprendre).
--
LL
Jean-Marc Bourguet
Dec 3, 2012, 4:22:12 AM12/3/12
to
Manuel Pégourié-Gonnard <m...@elzevir.fr> writes:
> Considérons le programme suivant. Ai-je raison de croire que les
> trois premiers paragraphes (jusqu'au commentaire « maintenant on dépend
> du boutisme ») donnent un résultat indépendant du boutisme de la
> plateforme ?
Oui.
> Considérons le programme suivant. Ai-je raison de croire que les
> trois premiers paragraphes (jusqu'au commentaire « maintenant on dépend
> du boutisme ») donnent un résultat indépendant du boutisme de la
> plateforme ?
> Entre le deuxième et le troisième paragraphe, l'un vous paraît-il plus
> lisible que l'autre ?
A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Olivier Miakinen
Dec 3, 2012, 5:43:55 AM12/3/12
to
Bonjour,
Le 03/12/2012 09:28, Manuel Pￜgouriￜ-Gonnard a ￜcrit :
> plateforme ? Entre le deuxiï¿œme et le troisiï¿œme paragraphe, l'un vous
> paraï¿œt-il plus lisible que l'autre ?
Je suis d'accord avec tout (mï¿œme s'il m'a fallu un peu de temps pour
comprendre le troisiￜme exemple car je n'avais pas regardￜ le type des
valeurs), et je suis aussi d'accord avec les rï¿œponses de Lucas et de
Jean-Marc.
Dans un vrai programme, je n'utiliserais que 1 et 2, et surtout pas
les deux derniers exemples.
--
Olivier Miakinen
Le 03/12/2012 09:28, Manuel Pￜgouriￜ-Gonnard a ￜcrit :
>
> Bon, c'est un point que je crois avoir compris, mais j'aimerais juste
> une confirmation (ou infirmation... et/ou prï¿œcision) de votre part.
> Bon, c'est un point que je crois avoir compris, mais j'aimerais juste
>
> Considï¿œrons le programme suivant. Ai-je raison de croire que les
> trois premiers paragraphes (jusqu'au commentaire ￜ maintenant on dￜpend
> du boutisme ￜ) donnent un rￜsultat indￜpendant du boutisme de la
> Considï¿œrons le programme suivant. Ai-je raison de croire que les
> trois premiers paragraphes (jusqu'au commentaire ￜ maintenant on dￜpend
> plateforme ? Entre le deuxiï¿œme et le troisiï¿œme paragraphe, l'un vous
> paraï¿œt-il plus lisible que l'autre ?
Je suis d'accord avec tout (mï¿œme s'il m'a fallu un peu de temps pour
comprendre le troisiￜme exemple car je n'avais pas regardￜ le type des
valeurs), et je suis aussi d'accord avec les rï¿œponses de Lucas et de
Jean-Marc.
Dans un vrai programme, je n'utiliserais que 1 et 2, et surtout pas
les deux derniers exemples.
--
Olivier Miakinen
Dominique MICOLLET
Dec 3, 2012, 6:31:15 AM12/3/12
to
Bonjour,
Manuel Pégourié-Gonnard a écrit :
registres du processeur, pour qui la notion de "boutisme" n'existe pas.
> Entre le deuxième et le troisième paragraphe, l'un vous
> paraît-il plus lisible que l'autre ?
Le deuxième est plus clair.
Il devrait d'ailleurs être écrit :
b=(uint16t)(a & 0xFFFF).
Puis je me permettre un conseil : si gcc est votre compilateur, usez de
l'option -Wall et faites la chasse aux avertissements.
> memcpy(&b, &a, 2);
> printf("Premiers octets\nb = 0x%X\n", b);
>
> memcpy(&b, ((char *) &a) + 2, 2);
> printf("Derniers octets\nb = 0x%X\n", b);
Je suis curieux de savoir pourquoi vous cherchez à faire ces opérations :
elles sont très inefficaces en terme de temps d'éxécution (accéder à une
memoire est généralement plus long que manipuler des registres).
Cordialement
Dominique.
Manuel Pégourié-Gonnard a écrit :
> Ai-je raison de croire que les
> trois premiers paragraphes (jusqu'au commentaire « maintenant on dépend
> du boutisme »)
> donnent un résultat indépendant du boutisme de la
> plateforme ?
Oui, parce que les opérations de decalage ou de masquage ont lieu dans les
> trois premiers paragraphes (jusqu'au commentaire « maintenant on dépend
> du boutisme »)
> donnent un résultat indépendant du boutisme de la
> plateforme ?
registres du processeur, pour qui la notion de "boutisme" n'existe pas.
> Entre le deuxième et le troisième paragraphe, l'un vous
> paraît-il plus lisible que l'autre ?
Il devrait d'ailleurs être écrit :
b=(uint16t)(a & 0xFFFF).
Puis je me permettre un conseil : si gcc est votre compilateur, usez de
l'option -Wall et faites la chasse aux avertissements.
> memcpy(&b, &a, 2);
> printf("Premiers octets\nb = 0x%X\n", b);
>
> memcpy(&b, ((char *) &a) + 2, 2);
> printf("Derniers octets\nb = 0x%X\n", b);
elles sont très inefficaces en terme de temps d'éxécution (accéder à une
memoire est généralement plus long que manipuler des registres).
Cordialement
Dominique.
Marc Espie
Dec 3, 2012, 7:16:23 AM12/3/12
to
In article <k9hnr8$jaf$1...@thue.elzevir.fr>,
>
>Consid�rons le programme suivant. Ai-je raison de croire que les
>trois premiers paragraphes (jusqu'au commentaire � maintenant on d�pend
>du boutisme��) donnent un r�sultat ind�pendant du boutisme de la
>plateforme ? Entre le deuxi�me et le troisi�me paragraphe, l'un vous
>para�t-il plus lisible que l'autre ?
pas portable ? 7.18.1.1: les types uintN_t sont optionels, et ne sont
fournis par l'implementation que si celle-ci supporte des entiers de
taille adequate. Les types GARANTIS sont les uint_leastN_t et uint_fastN_t
(pour n = 8, 16, 32, 64).
Mais bon, tu peux regarder si UINT16_MAX existe, par exemple.
> /* 1. On veut r�cup�rer les 2 octets de poids fort de a dans b */
> * � partir de maintenant les r�sultats d�pendent du boutisme
de l'endianess de ta plateforme: tu supposes que tes char font exactement
8 bits, ce qui se verifie avec CHAR_BIT == 8.
> return 0;
>}
>
Enfin, quand je dis, ca marchera...
tes printf sont buggues. Ils masquent une promotion, et c'est pas totalement
sur que 0x%X va t'afficher exactement ce que tu voudras (typiquement, ca
va foirer sur une plateforme 16 bits).
La bonne facon sera:
#include <inttypes.h>
printf("whatever\nb = %" PRIX16 "\n", b);
Manuel P�gouri�-Gonnard <m...@elzevir.fr> wrote:
>Bonjour,
>
>Bon, c'est un point que je crois avoir compris, mais j'aimerais juste
>une confirmation (ou infirmation... et/ou pr�cision) de votre part.
>Bonjour,
>
>Bon, c'est un point que je crois avoir compris, mais j'aimerais juste
>
>Consid�rons le programme suivant. Ai-je raison de croire que les
>trois premiers paragraphes (jusqu'au commentaire � maintenant on d�pend
>du boutisme��) donnent un r�sultat ind�pendant du boutisme de la
>plateforme ? Entre le deuxi�me et le troisi�me paragraphe, l'un vous
>para�t-il plus lisible que l'autre ?
>
>Merci,
>Manuel.
>
>
>#include <stdio.h>
>#include <stdint.h>
>#include <string.h>
>
>int main(void)
>{
> const uint32_t a = 0xA4A3A2A1;
> uint16_t b;
Puisqu'on est en mode pinaillage, tu es au courant que ce code n'est
>Merci,
>Manuel.
>
>
>#include <stdio.h>
>#include <stdint.h>
>#include <string.h>
>
>int main(void)
>{
> const uint32_t a = 0xA4A3A2A1;
> uint16_t b;
pas portable ? 7.18.1.1: les types uintN_t sont optionels, et ne sont
fournis par l'implementation que si celle-ci supporte des entiers de
taille adequate. Les types GARANTIS sont les uint_leastN_t et uint_fastN_t
(pour n = 8, 16, 32, 64).
Mais bon, tu peux regarder si UINT16_MAX existe, par exemple.
> /* 1. On veut r�cup�rer les 2 octets de poids fort de a dans b */
> b = a >> 16;
> printf("Poids fort\nb = 0x%X\n", b);
>
> /* 2. Maintenant les deux octets de poids faible */
> b = a & 0xFFFF;
> printf("Poids faible\nb = 0x%X\n", b);
>
> /* 3. Pareil, �crit autrement */
> printf("Poids fort\nb = 0x%X\n", b);
>
> /* 2. Maintenant les deux octets de poids faible */
> b = a & 0xFFFF;
> printf("Poids faible\nb = 0x%X\n", b);
>
> b = a;
> printf("Poids faible 2\nb = 0x%X\n", b);
> /*
Avec la reserve ci-dessus, ca marchera.
> printf("Poids faible 2\nb = 0x%X\n", b);
> /*
> * � partir de maintenant les r�sultats d�pendent du boutisme
> */
> memcpy(&b, &a, 2);
> printf("Premiers octets\nb = 0x%X\n", b);
> memcpy(&b, ((char *) &a) + 2, 2);
> printf("Derniers octets\nb = 0x%X\n", b);
>
La-encore, les deux memcpy sont stricto-sensu non portables, independamment
> memcpy(&b, &a, 2);
> printf("Premiers octets\nb = 0x%X\n", b);
> memcpy(&b, ((char *) &a) + 2, 2);
> printf("Derniers octets\nb = 0x%X\n", b);
>
de l'endianess de ta plateforme: tu supposes que tes char font exactement
8 bits, ce qui se verifie avec CHAR_BIT == 8.
> return 0;
>}
>
Enfin, quand je dis, ca marchera...
tes printf sont buggues. Ils masquent une promotion, et c'est pas totalement
sur que 0x%X va t'afficher exactement ce que tu voudras (typiquement, ca
va foirer sur une plateforme 16 bits).
La bonne facon sera:
#include <inttypes.h>
printf("whatever\nb = %" PRIX16 "\n", b);
Manuel Pégourié-Gonnard
Dec 3, 2012, 2:38:19 PM12/3/12
to
Bonsoir,
et merci à tous pour vos réponses.
Dominique MICOLLET scripsit :
>> Entre le deuxième et le troisième paragraphe, l'un vous
>> paraît-il plus lisible que l'autre ?
>
> Le deuxième est plus clair.
Il me semblait aussi.
> Il devrait d'ailleurs être écrit :
> b=(uint16t)(a & 0xFFFF).
>
> Puis je me permettre un conseil : si gcc est votre compilateur, usez de
> l'option -Wall et faites la chasse aux avertissements.
>
Hum, j'ai utilisé gcc -std=c99 -Wall -pedantic et il n'a rien trouvé à
redire. (J'utilise systématiquement -Wall et je ne laisse jamais traîner
un avertissement.)
>> memcpy(&b, &a, 2);
>> printf("Premiers octets\nb = 0x%X\n", b);
>>
>> memcpy(&b, ((char *) &a) + 2, 2);
>> printf("Derniers octets\nb = 0x%X\n", b);
>
>
> Je suis curieux de savoir pourquoi vous cherchez à faire ces opérations :
> elles sont très inefficaces en terme de temps d'éxécution (accéder à une
> memoire est généralement plus long que manipuler des registres).
>
Il s'agit, dans des entiers multi-précision, de déplacer des blocs de 32
bits dans le but de réduire rapidement modulo un pseudo-Mersenne. Mais
je ne cherche pas particulièrement à utiliser memcpy(), là c'était
plutôt pour contraster avec les paragraphes précédents.
et merci à tous pour vos réponses.
Dominique MICOLLET scripsit :
>> Entre le deuxième et le troisième paragraphe, l'un vous
>> paraît-il plus lisible que l'autre ?
>
> Le deuxième est plus clair.
> Il devrait d'ailleurs être écrit :
> b=(uint16t)(a & 0xFFFF).
>
> Puis je me permettre un conseil : si gcc est votre compilateur, usez de
> l'option -Wall et faites la chasse aux avertissements.
>
redire. (J'utilise systématiquement -Wall et je ne laisse jamais traîner
un avertissement.)
>> memcpy(&b, &a, 2);
>> printf("Premiers octets\nb = 0x%X\n", b);
>>
>> memcpy(&b, ((char *) &a) + 2, 2);
>> printf("Derniers octets\nb = 0x%X\n", b);
>
>
> Je suis curieux de savoir pourquoi vous cherchez à faire ces opérations :
> elles sont très inefficaces en terme de temps d'éxécution (accéder à une
> memoire est généralement plus long que manipuler des registres).
>
bits dans le but de réduire rapidement modulo un pseudo-Mersenne. Mais
je ne cherche pas particulièrement à utiliser memcpy(), là c'était
plutôt pour contraster avec les paragraphes précédents.
Manuel Pégourié-Gonnard
Dec 3, 2012, 2:50:50 PM12/3/12
to
Marc Espie scripsit :
> In article <k9hnr8$jaf$1...@thue.elzevir.fr>,
> tu es au courant que ce code n'est
> pas portable ? 7.18.1.1: les types uintN_t sont optionels, et ne sont
> fournis par l'implementation que si celle-ci supporte des entiers de
> taille adequate. Les types GARANTIS sont les uint_leastN_t et uint_fastN_t
> (pour n = 8, 16, 32, 64).
>
Ah non, j'avoue que ça m'avait échappé. Et je me demandais justement
comment faisaient les plate-formes qui ont CHAR_BIT > 8 pour uint8_t, je
crois que ta remarque répond à ma question.
> Mais bon, tu peux regarder si UINT16_MAX existe, par exemple.
>
Oui, en pratique dans le projet en question il ya déjà ce genre de
tests, donc je suis tranquille.
> La-encore, les deux memcpy sont stricto-sensu non portables, independamment
> de l'endianess de ta plateforme: tu supposes que tes char font exactement
> 8 bits, ce qui se verifie avec CHAR_BIT == 8.
>
Oui.
> tes printf sont buggues. Ils masquent une promotion,
Tu veux dire que b sera promu en unsigned int ?
> et c'est pas totalement
> sur que 0x%X va t'afficher exactement ce que tu voudras (typiquement, ca
> va foirer sur une plateforme 16 bits).
>
Hum, là j'ai peur de pas comprendre pourquoi par contre.
> La bonne facon sera:
>
> #include <inttypes.h>
>
> printf("whatever\nb = %" PRIX16 "\n", b);
Ok, vu.
> In article <k9hnr8$jaf$1...@thue.elzevir.fr>,
> Manuel Pégourié-Gonnard <m...@elzevir.fr> wrote:
>> const uint32_t a = 0xA4A3A2A1;
>> uint16_t b;
>
> Puisqu'on est en mode pinaillage,
Je ne posterais pas ici si je n'aimais pas le pinaillage :)
>> const uint32_t a = 0xA4A3A2A1;
>> uint16_t b;
>
> Puisqu'on est en mode pinaillage,
> tu es au courant que ce code n'est
> pas portable ? 7.18.1.1: les types uintN_t sont optionels, et ne sont
> fournis par l'implementation que si celle-ci supporte des entiers de
> taille adequate. Les types GARANTIS sont les uint_leastN_t et uint_fastN_t
> (pour n = 8, 16, 32, 64).
>
comment faisaient les plate-formes qui ont CHAR_BIT > 8 pour uint8_t, je
crois que ta remarque répond à ma question.
> Mais bon, tu peux regarder si UINT16_MAX existe, par exemple.
>
tests, donc je suis tranquille.
> La-encore, les deux memcpy sont stricto-sensu non portables, independamment
> de l'endianess de ta plateforme: tu supposes que tes char font exactement
> 8 bits, ce qui se verifie avec CHAR_BIT == 8.
>
> tes printf sont buggues. Ils masquent une promotion,
> et c'est pas totalement
> sur que 0x%X va t'afficher exactement ce que tu voudras (typiquement, ca
> va foirer sur une plateforme 16 bits).
>
> La bonne facon sera:
>
> #include <inttypes.h>
>
> printf("whatever\nb = %" PRIX16 "\n", b);
Dominique MICOLLET
Dec 4, 2012, 3:18:08 AM12/4/12
to
Bonjour,
Manuel Pégourié-Gonnard a écrit :
Manuel Pégourié-Gonnard a écrit :
> Hum, j'ai utilisé gcc -std=c99 -Wall -pedantic et il n'a rien trouvé à
> redire. (J'utilise systématiquement -Wall et je ne laisse jamais traîner
> un avertissement.)
Votre remarque m'a fait peur. J'ai fait quelques essais, et il semble que
> redire. (J'utilise systématiquement -Wall et je ne laisse jamais traîner
> un avertissement.)
"all" ne signifie plus "tout" en anglais. Le transtypage automatique
dangereux est signalé par l'option -Wconversion.
> Il s'agit, dans des entiers multi-précision, de déplacer des blocs de 32
> bits dans le but de réduire rapidement modulo un pseudo-Mersenne. Mais
> je ne cherche pas particulièrement à utiliser memcpy(), là c'était
> plutôt pour contraster avec les paragraphes précédents.
>
Toutefois lorsqu'on parle d'entier multiprécision, la granularité du codage
ne devrait-elle pas être l'octet ?
Je conçois qu'on puisse vouloir utiliser 32 bits pour se conformer à
l'architecture du processeur : mais il va y avoir des soucis avec les
processeurs 64 bits, sauf si la bibliothèque multiprécision a prévu cette
situation.
Cordialement.
Dominique.
Jean-Marc Bourguet
Dec 4, 2012, 4:17:59 AM12/4/12
to
Dominique MICOLLET <Dominique...@u-bourgogne.fr> writes:
> Bonjour,
>
> Manuel Pégourié-Gonnard a écrit :
>> Hum, j'ai utilisé gcc -std=c99 -Wall -pedantic et il n'a rien trouvé à
>> redire. (J'utilise systématiquement -Wall et je ne laisse jamais traîner
>> un avertissement.)
>
>
> Votre remarque m'a fait peur. J'ai fait quelques essais, et il semble que
> "all" ne signifie plus "tout" en anglais. Le transtypage automatique
> dangereux est signalé par l'option -Wconversion.
Le all n'a jamais signifié tout dans -Wall, ca a toujours ete un
> Bonjour,
>
> Manuel Pégourié-Gonnard a écrit :
>> Hum, j'ai utilisé gcc -std=c99 -Wall -pedantic et il n'a rien trouvé à
>> redire. (J'utilise systématiquement -Wall et je ne laisse jamais traîner
>> un avertissement.)
>
>
> Votre remarque m'a fait peur. J'ai fait quelques essais, et il semble que
> "all" ne signifie plus "tout" en anglais. Le transtypage automatique
> dangereux est signalé par l'option -Wconversion.
sous-ensemble des warnings, dans la doc de 2.95 -- la plus vieille
facilement accessible -- "This enables all the warnings about
constructions that some users consider questionable, and that are easy
to avoid (or modify to prevent the warning), even in conjunction with
macros."
Lucas Levrel
Dec 4, 2012, 5:17:10 AM12/4/12
to
Le 4 décembre 2012, Jean-Marc Bourguet a écrit :
> Dominique MICOLLET <Dominique...@u-bourgogne.fr> writes:
>
>> Manuel Pégourié-Gonnard a écrit :
>>> Hum, j'ai utilisé gcc -std=c99 -Wall -pedantic et il n'a rien trouvé à
>>> redire. (J'utilise systématiquement -Wall et je ne laisse jamais traîner
>>> un avertissement.)
>>
>> Votre remarque m'a fait peur. J'ai fait quelques essais, et il semble que
>> "all" ne signifie plus "tout" en anglais. Le transtypage automatique
>> dangereux est signalé par l'option -Wconversion.
>
> Le all n'a jamais signifié tout dans -Wall, ca a toujours ete un
> sous-ensemble des warnings
Et même -Wextra ne suffit pas à tous les activer. Apparemment il n'y a pas
d'option pour dire « vraiment tout ».
--
LL
> Dominique MICOLLET <Dominique...@u-bourgogne.fr> writes:
>
>> Manuel Pégourié-Gonnard a écrit :
>>> Hum, j'ai utilisé gcc -std=c99 -Wall -pedantic et il n'a rien trouvé à
>>> redire. (J'utilise systématiquement -Wall et je ne laisse jamais traîner
>>> un avertissement.)
>>
>> Votre remarque m'a fait peur. J'ai fait quelques essais, et il semble que
>> "all" ne signifie plus "tout" en anglais. Le transtypage automatique
>> dangereux est signalé par l'option -Wconversion.
>
> Le all n'a jamais signifié tout dans -Wall, ca a toujours ete un
> sous-ensemble des warnings
d'option pour dire « vraiment tout ».
--
LL
Marc Espie
Dec 4, 2012, 11:10:01 AM12/4/12
to
In article <alpine.LNX.2.00.1...@coulomb.univ-paris12.fr>,
Apres, on ne veut pas "vraiment tout", vu que gcc est capable de se
gauffrer et sortir des warnings sans raison, et qu'en meme temps, il y a
pas mal de choses qu'il ne verra pas cote portabilite...
gauffrer et sortir des warnings sans raison, et qu'en meme temps, il y a
pas mal de choses qu'il ne verra pas cote portabilite...
Manuel Pégourié-Gonnard
Dec 4, 2012, 1:26:50 PM12/4/12
to
Dominique MICOLLET scripsit :
> Manuel Pégourié-Gonnard a écrit :
>> Hum, j'ai utilisé gcc -std=c99 -Wall -pedantic et il n'a rien trouvé à
>> redire. (J'utilise systématiquement -Wall et je ne laisse jamais traîner
>> un avertissement.)
>
> Votre remarque m'a fait peur. J'ai fait quelques essais, et il semble que
> "all" ne signifie plus "tout" en anglais. Le transtypage automatique
> dangereux est signalé par l'option -Wconversion.
>
Pour compléter les autres remarques qui ont été faites, dans ma version,
-Wconversion n'est pas inclus dans -Wextra non plus.
>> Il s'agit, dans des entiers multi-précision, de déplacer des blocs de 32
>> bits dans le but de réduire rapidement modulo un pseudo-Mersenne. Mais
>> je ne cherche pas particulièrement à utiliser memcpy(), là c'était
>> plutôt pour contraster avec les paragraphes précédents.
>>
> Là, dès qu'on cause mathématiques, je suis un peu perdu :-) (et j'ai honte).
> Toutefois lorsqu'on parle d'entier multiprécision, la granularité du codage
> ne devrait-elle pas être l'octet ?
> Je conçois qu'on puisse vouloir utiliser 32 bits pour se conformer à
> l'architecture du processeur : mais il va y avoir des soucis avec les
> processeurs 64 bits, sauf si la bibliothèque multiprécision a prévu cette
> situation.
>
Là, les 32 bits sont imposés par la structure du nombre quasi-de
Mersenne. Imaginons par exemple que je veuille réduire un nombre
rapidement modulo 2^224 - 2^96 + 1 : la façon de faire la plus rapide
passe par l'écriture dudit nombre en base 2^32, c'est-à-dire par le fait
de le voir comme une suite de blocs de 32 bits. Et effectivement, c'est
moins sympathique sur les archis 64 bits, mais il faut faire avec.
> Manuel Pégourié-Gonnard a écrit :
>> Hum, j'ai utilisé gcc -std=c99 -Wall -pedantic et il n'a rien trouvé à
>> redire. (J'utilise systématiquement -Wall et je ne laisse jamais traîner
>> un avertissement.)
>
> Votre remarque m'a fait peur. J'ai fait quelques essais, et il semble que
> "all" ne signifie plus "tout" en anglais. Le transtypage automatique
> dangereux est signalé par l'option -Wconversion.
>
-Wconversion n'est pas inclus dans -Wextra non plus.
>> Il s'agit, dans des entiers multi-précision, de déplacer des blocs de 32
>> bits dans le but de réduire rapidement modulo un pseudo-Mersenne. Mais
>> je ne cherche pas particulièrement à utiliser memcpy(), là c'était
>> plutôt pour contraster avec les paragraphes précédents.
>>
> Là, dès qu'on cause mathématiques, je suis un peu perdu :-) (et j'ai honte).
> Toutefois lorsqu'on parle d'entier multiprécision, la granularité du codage
> ne devrait-elle pas être l'octet ?
> Je conçois qu'on puisse vouloir utiliser 32 bits pour se conformer à
> l'architecture du processeur : mais il va y avoir des soucis avec les
> processeurs 64 bits, sauf si la bibliothèque multiprécision a prévu cette
> situation.
>
Mersenne. Imaginons par exemple que je veuille réduire un nombre
rapidement modulo 2^224 - 2^96 + 1 : la façon de faire la plus rapide
passe par l'écriture dudit nombre en base 2^32, c'est-à-dire par le fait
de le voir comme une suite de blocs de 32 bits. Et effectivement, c'est
moins sympathique sur les archis 64 bits, mais il faut faire avec.
Marc
Dec 4, 2012, 3:59:38 PM12/4/12
to
les utilisateurs risqueraient de mal l'utiliser et de faire perdre des
heures à tout le monde avec leurs râleries que tel warning ne leur plaît
pas (ils n'avaient qu'à ne pas l'activer !). Certains warnings sont des
questions de style, et il est normal d'avoir un warning qui dit de
réécrire A en B et si on le fait un autre warning dira de le réécrire en
A. -Wall et -Wextra fournissent des sous-ensembles raisonnables pour
gens qui n'ont pas envie de se farcir la liste de tous les -W* pour
faire leur marché. Si -Wconversion n'est pas inclus dedans pour une
release donnée (ça a pu changer plusieurs fois), c'est parce qu'il n'est
pas très au point (trop de faux positifs), mais il reviendra dedans
quand quelqu'un se sera motivé pour l'améliorer (j'invite d'ailleurs les
participants à cette conversation...).
Marc Espie
Dec 5, 2012, 12:24:50 AM12/5/12
to
In article <k9lo7q$lsq$1...@news-rocq.inria.fr>,
dont il a envie. Rien de tres surprenant pour gcc donc.
Apres, le fonctionnement des warnings dans gcc est un vrai gros bordel.
On ne peut qu'esperer que clang, etant parti de zero plus recemment, ne
fera pas les memes conneries.
Marc <marc....@gmail.com> wrote:
>Lucas Levrel wrote:
>
>> Le 4 décembre 2012, Jean-Marc Bourguet a écrit :
>>
>>> Le all n'a jamais signifié tout dans -Wall, ca a toujours ete un
>>> sous-ensemble des warnings
>>
>> Et même -Wextra ne suffit pas à tous les activer. Apparemment il n'y a pas
>> d'option pour dire « vraiment tout ».
>
>clang a un -Weverything. gcc a toujours refusé de le créer, parce que
>les utilisateurs risqueraient de mal l'utiliser et de faire perdre des
>heures à tout le monde avec leurs râleries que tel warning ne leur plaît
>pas (ils n'avaient qu'à ne pas l'activer !).
Etat d'esprit un peu arrogant, genre on sait mieux que l'utilisateur ce
>Lucas Levrel wrote:
>
>> Le 4 décembre 2012, Jean-Marc Bourguet a écrit :
>>
>>> Le all n'a jamais signifié tout dans -Wall, ca a toujours ete un
>>> sous-ensemble des warnings
>>
>> Et même -Wextra ne suffit pas à tous les activer. Apparemment il n'y a pas
>> d'option pour dire « vraiment tout ».
>
>clang a un -Weverything. gcc a toujours refusé de le créer, parce que
>les utilisateurs risqueraient de mal l'utiliser et de faire perdre des
>heures à tout le monde avec leurs râleries que tel warning ne leur plaît
>pas (ils n'avaient qu'à ne pas l'activer !).
dont il a envie. Rien de tres surprenant pour gcc donc.
Apres, le fonctionnement des warnings dans gcc est un vrai gros bordel.
On ne peut qu'esperer que clang, etant parti de zero plus recemment, ne
fera pas les memes conneries.
Dominique MICOLLET
Dec 5, 2012, 2:53:08 AM12/5/12
to
Bonjour,
Marc Espie a écrit :
- n'ont pas lu la totalité de la documentation dudit gcc. Donc les choix par
défaut sont peut-être un moindre mal, s'ils sont fondés sur l'expérience.
Promis, un de ces jours, je lirai toute la partie "warning" de la doc de
gcc.
Cordialement
Dominique.
Marc Espie a écrit :
> Etat d'esprit un peu arrogant, genre on sait mieux que l'utilisateur ce
> dont il a envie. Rien de tres surprenant pour gcc donc.
Ben, faut dire aussi que certains utilisateurs de gcc - moi par exemple :-)
> dont il a envie. Rien de tres surprenant pour gcc donc.
- n'ont pas lu la totalité de la documentation dudit gcc. Donc les choix par
défaut sont peut-être un moindre mal, s'ils sont fondés sur l'expérience.
Promis, un de ces jours, je lirai toute la partie "warning" de la doc de
gcc.
Cordialement
Dominique.
Dominique MICOLLET
Dec 5, 2012, 2:57:45 AM12/5/12
to
Bonjour,
Manuel Pégourié-Gonnard a écrit :
Manuel Pégourié-Gonnard a écrit :
> Là, les 32 bits sont imposés par la structure du nombre quasi-de
> Mersenne. Imaginons par exemple que je veuille réduire un nombre
> rapidement modulo 2^224 - 2^96 + 1 : la façon de faire la plus rapide
> passe par l'écriture dudit nombre en base 2^32, c'est-à-dire par le fait
> de le voir comme une suite de blocs de 32 bits. Et effectivement, c'est
> moins sympathique sur les archis 64 bits, mais il faut faire avec.
>
Je suis complètement largué, et je n'ai pas honte :-).
> Mersenne. Imaginons par exemple que je veuille réduire un nombre
> rapidement modulo 2^224 - 2^96 + 1 : la façon de faire la plus rapide
> passe par l'écriture dudit nombre en base 2^32, c'est-à-dire par le fait
> de le voir comme une suite de blocs de 32 bits. Et effectivement, c'est
> moins sympathique sur les archis 64 bits, mais il faut faire avec.
>
Bien que ce soit hors propos dans ce forum, pourriez-vous me proposer une
lecture sur ce sujet qui puisse satisfaire ma curiosité (je sais ce qu'est
un modulo, je crois savoir ce qu'est un nombre de Mersenne, et je ne sais
pas ce que représente l'opération "réduire").
Cordialement
Dominique.
Francois Lafont
Dec 5, 2012, 3:47:29 AM12/5/12
to
Le 05/12/2012 08:57, Dominique MICOLLET a écrit :
> Je suis complètement largué, et je n'ai pas honte :-).
Faut pas.
> Je suis complètement largué, et je n'ai pas honte :-).
> Bien que ce soit hors propos dans ce forum, pourriez-vous me proposer une
> lecture sur ce sujet qui puisse satisfaire ma curiosité (je sais ce qu'est
> un modulo, je crois savoir ce qu'est un nombre de Mersenne, et je ne sais
> pas ce que représente l'opération "réduire").
appartenant à {0; 1; ...; n-1} tel que A = r (mod n). Autrement dit,
c'est trouver le reste r de la division euclidienne de A par n.
Enfin Manuel rectifiera si je dis une bêtise mais je ne crois pas.
--
François Lafont
Manuel Pégourié-Gonnard
Dec 5, 2012, 4:45:36 AM12/5/12
to
Francois Lafont scripsit :
> Le 05/12/2012 08:57, Dominique MICOLLET a écrit :
>
>> Je suis complètement largué, et je n'ai pas honte :-).
>
> Faut pas.
>
Absolument.
>> Bien que ce soit hors propos dans ce forum, pourriez-vous me proposer une
>> lecture sur ce sujet qui puisse satisfaire ma curiosité (je sais ce qu'est
>> un modulo, je crois savoir ce qu'est un nombre de Mersenne, et je ne sais
>> pas ce que représente l'opération "réduire").
>
> Réduire un entier A modulo n, selon moi, c'est trouver l'unique entier r
> appartenant à {0; 1; ...; n-1} tel que A = r (mod n). Autrement dit,
> c'est trouver le reste r de la division euclidienne de A par n.
>
Précisément. Donc l'opération "réduire a modulo n", si a et n sont des
entiers non signés, c'est a = a % n en C (vague tentative de retour en
charte).
Bon, prenons l'exemple de n = 2^64 - 1, qu'on peut appeler un nombre
(non premier) de Mersenne, et considérons un entier multiprécision qu'on
veut réduire modulo n, on suppose qu'il est strictement inférieur à
2^128. On peut donc l'écrire a = a1 * 2^64 + a0 où a1 et a0 sont
strictement inférieurs à 2^64 (donc, sur une machine 64 bits, des
entiers, sur une machine 32 bits, des tableaux de 2 entiers, etc.).
On peut calculer a mod n rapidement (en tout cas plus rapidement qu'un
algo générique) en remarquant que
2^64 = 1 (mod n), donc a = a1 + a0 (mod n)
On calcule donc a1 + a0, et comme ça vaut au plus 2n - 2, il ne reste
plus qu'à éventuellement soutraire une fois n pour arriver à a mod n.
Les premiers de Mersenne, c'est des nombres premiers de la forme
2^p - 1. Comme il n'y en a pas tant que ça, on utilise aussi des nombres
premiers de pseudo-Mersenne (ou quasi-Mersenne, ou Mersenne généralisé),
qui sont des sommes signées d'un petit nombre de puissances de 2, avec
exposants en général multiples de 32 (voire de 64) par exemple
2^224 - 2^96 + 1, pour pourvoir réduire rapidement modulo ces premiers,
dans des applications cryptographiques. Voir par exemple l'annexe D.2 de
http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf pour des
nombres de (pseudo-)Mersenne couramment utilisés en crypto elliptique.
(Désolé pour le HS, si vous étes curieux et souhaitez plus de détails,
on peut continuer sur fr.sci.math ou en privé.)
> Le 05/12/2012 08:57, Dominique MICOLLET a écrit :
>
>> Je suis complètement largué, et je n'ai pas honte :-).
>
> Faut pas.
>
>> Bien que ce soit hors propos dans ce forum, pourriez-vous me proposer une
>> lecture sur ce sujet qui puisse satisfaire ma curiosité (je sais ce qu'est
>> un modulo, je crois savoir ce qu'est un nombre de Mersenne, et je ne sais
>> pas ce que représente l'opération "réduire").
>
> Réduire un entier A modulo n, selon moi, c'est trouver l'unique entier r
> appartenant à {0; 1; ...; n-1} tel que A = r (mod n). Autrement dit,
> c'est trouver le reste r de la division euclidienne de A par n.
>
entiers non signés, c'est a = a % n en C (vague tentative de retour en
charte).
Bon, prenons l'exemple de n = 2^64 - 1, qu'on peut appeler un nombre
(non premier) de Mersenne, et considérons un entier multiprécision qu'on
veut réduire modulo n, on suppose qu'il est strictement inférieur à
2^128. On peut donc l'écrire a = a1 * 2^64 + a0 où a1 et a0 sont
strictement inférieurs à 2^64 (donc, sur une machine 64 bits, des
entiers, sur une machine 32 bits, des tableaux de 2 entiers, etc.).
On peut calculer a mod n rapidement (en tout cas plus rapidement qu'un
algo générique) en remarquant que
2^64 = 1 (mod n), donc a = a1 + a0 (mod n)
On calcule donc a1 + a0, et comme ça vaut au plus 2n - 2, il ne reste
plus qu'à éventuellement soutraire une fois n pour arriver à a mod n.
Les premiers de Mersenne, c'est des nombres premiers de la forme
2^p - 1. Comme il n'y en a pas tant que ça, on utilise aussi des nombres
premiers de pseudo-Mersenne (ou quasi-Mersenne, ou Mersenne généralisé),
qui sont des sommes signées d'un petit nombre de puissances de 2, avec
exposants en général multiples de 32 (voire de 64) par exemple
2^224 - 2^96 + 1, pour pourvoir réduire rapidement modulo ces premiers,
dans des applications cryptographiques. Voir par exemple l'annexe D.2 de
http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf pour des
nombres de (pseudo-)Mersenne couramment utilisés en crypto elliptique.
(Désolé pour le HS, si vous étes curieux et souhaitez plus de détails,
on peut continuer sur fr.sci.math ou en privé.)
Antoine Leca
Dec 5, 2012, 5:30:39 AM12/5/12
to
Manuel Pégourié-Gonnard écrivit :
> Marc Espie scripsit :
comme unsigned, ce qu'attend le %X, ce sera OK. Sur n'importe quelle
autre machine, il y aura promotion en signed int, et officiellement ce
n'est pas ce qu'attend %X.
Antoine
> Marc Espie scripsit :
>> tes printf sont buggues. Ils masquent une promotion,
>
> Tu veux dire que b sera promu en unsigned int ?
Non, c'est le contraire. Sur une machine 16 bits, uint16_t va être passé
>
> Tu veux dire que b sera promu en unsigned int ?
comme unsigned, ce qu'attend le %X, ce sera OK. Sur n'importe quelle
autre machine, il y aura promotion en signed int, et officiellement ce
n'est pas ce qu'attend %X.
Antoine
Antoine Leca
Dec 5, 2012, 5:40:15 AM12/5/12
to
Dominique MICOLLET écrivit :
> Manuel Pégourié-Gonnard a écrit :
> mais il va y avoir des soucis avec les processeurs 64 bits,
En dehors d'une possible perte de performances par rapport à une version
tout en 64 bits (pour exploiter encore plus le processeur, mais qui
coûte en temps humain), en supposant que le processeur 64 bits
implémente le support suffisant des opérations en 32 bits (ce qui est le
cas en pratique), je ne vois pas pourquoi il y aurait des soucis ?
Antoine
> Manuel Pégourié-Gonnard a écrit :
>> Il s'agit, dans des entiers multi-précision, de déplacer des blocs de 32
>
>
> Toutefois lorsqu'on parle d'entier multiprécision, la granularité du codage
> ne devrait-elle pas être l'octet ?
> Je conçois qu'on puisse vouloir utiliser 32 bits pour se conformer à
> l'architecture du processeur :
Oui, et surtout pour améliorer substantiellement les performances
> ne devrait-elle pas être l'octet ?
> Je conçois qu'on puisse vouloir utiliser 32 bits pour se conformer à
> l'architecture du processeur :
> mais il va y avoir des soucis avec les processeurs 64 bits,
tout en 64 bits (pour exploiter encore plus le processeur, mais qui
coûte en temps humain), en supposant que le processeur 64 bits
implémente le support suffisant des opérations en 32 bits (ce qui est le
cas en pratique), je ne vois pas pourquoi il y aurait des soucis ?
Antoine
Marc
Dec 8, 2012, 12:03:44 PM12/8/12
to
Marc Espie wrote:
> In article <k9lo7q$lsq$1...@news-rocq.inria.fr>,
> Marc <marc....@gmail.com> wrote:
>>clang a un -Weverything. gcc a toujours refusé de le créer, parce que
>>les utilisateurs risqueraient de mal l'utiliser et de faire perdre des
>>heures à tout le monde avec leurs râleries que tel warning ne leur plaît
>>pas (ils n'avaient qu'à ne pas l'activer !).
>
> Etat d'esprit un peu arrogant, genre on sait mieux que l'utilisateur ce
> dont il a envie. Rien de tres surprenant pour gcc donc.
En même temps, à ma connaissance, ils n'ont pas refusé un patch
> In article <k9lo7q$lsq$1...@news-rocq.inria.fr>,
> Marc <marc....@gmail.com> wrote:
>>clang a un -Weverything. gcc a toujours refusé de le créer, parce que
>>les utilisateurs risqueraient de mal l'utiliser et de faire perdre des
>>heures à tout le monde avec leurs râleries que tel warning ne leur plaît
>>pas (ils n'avaient qu'à ne pas l'activer !).
>
> Etat d'esprit un peu arrogant, genre on sait mieux que l'utilisateur ce
> dont il a envie. Rien de tres surprenant pour gcc donc.
implémentant -Weverything, ils ont juste refusé de l'écrire. Aussi,
certains développeurs de clang trouvent pénibles les utilisateurs qui
insistent pour râler dès qu'on ajoute un warning, qui se retrouve
automatiquement dans -Weverything, donc ce n'était pas de la parano
de la part de gcc. Donc ne pas oublier l'arrogance des utilisateurs,
pour faire pendant.
> Apres, le fonctionnement des warnings dans gcc est un vrai gros bordel.
> On ne peut qu'esperer que clang, etant parti de zero plus recemment, ne
> fera pas les memes conneries.
même que les warnings de gcc ont progressé ces dernières années.
Un mini-patch (à peine testé et sans doute largement améliorable) pour
avoir -Weverything dans gcc-4.8 (aller dans le sous-répertoire gcc/
avant de l'appliquer) :
Index: common.opt
===================================================================
--- common.opt (revision 194319)
+++ common.opt (working copy)
@@ -689,20 +689,24 @@ Common Var(warn_unused_variable) Warning
Warn when a variable is unused
Wcoverage-mismatch
Common Var(warn_coverage_mismatch) Init(1) Warning
Warn in case profiles in -fprofile-use do not match
Wvector-operation-performance
Common Var(warn_vector_operation_performance) Warning
Warn when a vector operation is compiled outside the SIMD
+Weverything
+Common Var(warn_everything) Warning
+Warn for no reason at all
+
Xassembler
Driver Separate
Xlinker
Driver Separate
Xpreprocessor
Driver Separate
Z
Index: optc-gen.awk
===================================================================
--- optc-gen.awk (revision 194319)
+++ optc-gen.awk (working copy)
@@ -25,21 +25,22 @@
# This program uses functions from opt-functions.awk and code from
# opt-read.awk.
#
# Usage: awk -f opt-functions.awk -f opt-read.awk -f optc-gen.awk \
# [-v header_name=header.h] < inputfile > options.c
# Dump that array of options into a C file.
END {
# Record first EnabledBy and LangEnabledBy uses.
-n_enabledby = 0;
+enabledby[0] = "Weverything";
+n_enabledby = 1;
for (i = 0; i < n_langs; i++) {
n_enabledby_lang[i] = 0;
}
for (i = 0; i < n_opts; i++) {
enabledby_arg = opt_args("EnabledBy", flags[i]);
if (enabledby_arg != "") {
n_enabledby_names = split(enabledby_arg, enabledby_names, " && ");
if (n_enabledby_names > 2) {
print "#error EnabledBy (Wfoo && Wbar && Wbaz) not currently supported"
}
@@ -72,20 +73,25 @@ for (i = 0; i < n_opts; i++) {
}
enabledby_arg = opt_args("LangEnabledBy", flags[i]);
if (enabledby_arg != "") {
enabledby_langs = nth_arg(0, enabledby_arg);
enabledby_name = nth_arg(1, enabledby_arg);
enabledby_posarg = nth_arg(2, enabledby_arg);
enabledby_negarg = nth_arg(3, enabledby_arg);
lang_enabled_by(enabledby_langs, enabledby_name, enabledby_posarg, enabledby_negarg);
}
+
+ if (flag_set_p("Warning", flags[i]) && flag_set_p("Var", flags[i])) {
+ enables["Weverything"] = enables["Weverything"] opts[i] ";";
+ enablesif["Weverything"] = enablesif["Weverything"] "" ";";
+ }
}
print "/* This file is auto-generated by optc-gen.awk. */"
print ""
n_headers = split(header_name, headers, " ")
for (i = 1; i <= n_headers; i++)
print "#include " quote headers[i] quote
print "#include " quote "opts.h" quote
print "#include " quote "intl.h" quote
0 new messages