Bonjour les codeurz...

En me promenant dans le grand ouèbe mondial, je suis tombé sur
cet article: http://lwn.net/Articles/278137/ qui évoque des
problèmes de potentiels buffer-overflow quand Gcc (et d'autres)
optimisent un peu trop sur certaines condition/tests.

Certains commentaires sont assez bons :)

tTh.

Thierry B. a écrit :

De toute manière, c'est le test + l'extérieur> qui est potentiellement dangereux.

C'est le cas classique dans beaucoup (trop) de "parseurs" d'objets
structurés (fichiers GIF, PNG, documents divers, etc.) qui ont souvent
une structure du genre:

Dans l'article <48f8f5-cvo.ln1@prout.stex>,
Thierry B. écrit:

Je ne pense pas que "This behavior is allowed by the C standard,
which states that, in a correct program, pointer addition will not
yield a pointer value outside of the same object." soit correct,
surtout que cette phrase ne précise pas de quel objet il s'agit.
Par exemple, je pense que le programme suivant est correct bien
que l'on sorte de l'objet v.b, puisqu'on est aussi dans l'objet v,
qui peut être assimilé à un tableau de caractères:

#include

int main (void)
{
struct { char a[8], b[8]; } v;
char *p;

In article <48f8f5-cvo.ln1@prout.stex>,
Thierry B. wrote:

Ca fait un moment que le zele des constructeurs de compilateurs a faire
des trucs qui vont le plus vite possible aux benchmarks posent quelques
problemes aux programmes reels.

Le chiendent, c'est que certains tests et certaines instructions, rajoutees
pour securiser du code, ne font pas forcement partie des `defined behavior'.

C, initialement, c'est cense etre un assembleur portable. Ca veut entre
autres dire qu'il y a des bouts qui sont censes etre dependants de
l'architecture. Lorsque GCC cesse de fournir des constructions supplementaires
propres pour traiter ces cas en plus, ou ne possede pas une representation
fiable de l'archi en question, ca commence a merder.

--{ Vincent Lefevre a plopé ceci: }--

C'est un peu capillotracté, ton raisonnement...

Je n'aime pas trop cette décrémentation. Un bon compilo/lint
arriverait-il à la détecter ?

Dans l'article ,
Thierry B. écrit:

Pourtant les fonctions du style memcpy font ce genre de chose.

Dans l'article biggoron.nerim.net>,
Marc Espie écrit:

Il n'y a pas que les benchmarks, il y a aussi des programmes réels.
Même si certaines optimisations peuvent sembler inutiles pour certains
programmes, elles peuvent être importantes pour d'autres.

Dans la mesure où un programme se base sur un undefined behavior,
il ne peut y avoir aucune sécurité. Un compilateur peut toujours
décrire comment ça se comporte ou avoir des options du style -fwrap,
mais alors ce n'est plus portable.

Note: j'ai déjà vu du code supposer que toutes les variables (y compris
automatiques) étaient initialisées à 0. Ça risque de poser des problèmes
de performance si GCC doit supposer cela.

Vincent Lefevre, le 08/05/2008 a écrit :

[...]

Dans une implémentation raisonnable de volatile [cui cui] que peut-on
attendre de:

#include
#include

int main(void)
{
int a, b, c, test; /* non volatile data*/
(volatile void)test;
(volatile void)(a = 0);
(volatile void)(b = 5);
(volatile void)(c = 10);
(volatile void)(a = b + c);
printf("%%d\n", a);
return EXIT_SUCCESS;
}

In article ,
Pierre Maurette wrote:

Sauf que, historiquement, le C est d'abord un assembleur portable.
C'est bien de mettre des regles dans la norme, mais lorsque le compilateur
devient trop agressif, le code C historique ne marche plus.

Et vous pourrez toujours dire `oui, mais c'est pas propre', il y a des
coins du systeme ou c'est un sacre casse-tete a corriger...

Dans l'article ,
Pierre Maurette écrit:

(volatile void), ça a un sens? J'aurais plutôt écrit:

(void) (volatile int) test;

Et là j'aurais écrit:

* (volatile int *) &a = 0;

et ainsi de suite.

Maintenant, concernant le code suivant: