Re: optimisation vs securite

In article <20080513234026$0c35@prunille.vinc17.org>,
Vincent Lefevre  <vincent+news@vinc17.org> wrote:
>Dans l'article <g0c3ms$ufd$1@biggoron.nerim.net>,
>  Marc Espie <espie@lain.home> écrit:
>
>> In article <20080513110728$5484@prunille.vinc17.org>,
>> Vincent Lefevre  <vincent+news@vinc17.org> wrote:
>> >Mais de toute façon, là, on sort complètement de la norme C, et le
>> >programmeur doit un minimum se baser sur la doc de son compilateur
>> >quand celui-ci outrepasse ce qu'il est censé faire (qui est de
>> >compiler une unité en un fichier objet), et plus généralement de
>> >son environnement (OS, etc.); 
>
>> C'est bien ce que je reproche a gcc, de s'arreter *avant* ce niveau
>> de detail, et de se retrancher derriere la norme pour changer des
>> comportements qui ont une importance pratique.
>
>Il en a tout à fait le droit; il ne peut pas deviner ce que tu veux
>comme optimisation. Et si tu ne veux aucune optimisation qui puisse
>changer le comportement vis-à-vis de l'extérieur (en quelque sorte,
>une généralisation du volatile), les performances seront énormément
>dégradées.

Dialogue de sourds...

Mais *TOUS* les cryptographes ont rale sur la suppression de ce truc,
ont dit que volatile n'etait clairement pas une solution, ont *demande*
un truc aux gens qui pondent gcc, avec juste comme resultat des discussions
de `language lawyer' sur `ah ouais, mais la, ca ca s'interprete pas comme
ca, et la norme ne permet rien'... ce qui n'est pas exactement ce qui
etait voulu comme resultat, hein.

Pour ce qui est de -fwrap, c'est un peu different.

La, le plus gros reproche qu'on peut faire a gcc, c'est que le systeme
de base est devenu beaucoup trop complexe, que personne ne sait vraiment
quelles optimisations servent a autre chose que bouffer du temps de compile, 
et surtout que l'enorme majorite des combinaisons d'options de compilation 
sont peu testees, et fortement bugguees...