Re: optimisation vs securite

In article <20080508232434$05bf@prunille.vinc17.org>,
Vincent Lefevre  <vincent+news@vinc17.org> wrote:

>En fait, je ne vois pas le problème dont parle Marc concernant la mise
>à 0 de la mémoire: il suffit de mettre le code dans une fonction avec
>le pointeur passé à cette fonction, et de compiler cette fonction
>séparément du reste: le compilateur ne peut pas deviner ce que va faire
>le reste du programme et ne pourra donc pas optimiser (i.e. il sera
>forcé de mettre à 0 la mémoire comme voulu).

Effectivement, tu passes completement a cote du vrai probleme.

Dans le temps, gcc n'optimisait pas le memset en question.

Qui te dit que bientot, il n'optimisera pas ce qui se passe entre
unites de compilation ? certains compilos le font bien...

Et la mise a zero de la memoire n'est toujours pas comportement observable
(et volatile n'est pas une solution). Et je n'ai toujours pas de solution
dont je suis sur qu'elle continuera a marcher avec la version suivante
de gcc.

Si tu preferes: chaque nouvelle version de gcc apporte son nouveau lot
de surprises qui cassent des comportements limites. Dans certains cas,
les comportements limites sont vraiment du code crade, et n'ont pas ma
sympathie. Dans d'autres cas, un peu plus pathologiques, ca n'est pas
le cas. Ca entraine des modifications de semantique surprenante, et 
ca casse du code reel, pour lequel il n'y a pas vraiment de solution
portable qui marche... et ca pose probleme pour upgrader le compilo.

Enfin bon, dans le cas de gcc, vu comment les versions recentes se
trainent par rapport aux anciennes, ca pose d'enormes problemes pour
tout ce qui n'est pas i386/amd64...