problèmes de potentiels buffer-overflow quand Gcc (et d'autres)
optimisent un peu trop sur certaines condition/tests.
problèmes de potentiels buffer-overflow quand Gcc (et d'autres)
optimisent un peu trop sur certaines condition/tests.
problèmes de potentiels buffer-overflow quand Gcc (et d'autres)
optimisent un peu trop sur certaines condition/tests.
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.
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.
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.
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.
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.
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.
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 <stdio.h>
int main (void)
{
struct { char a[8], b[8]; } v;
char *p;
p = &v.b[0];
printf ("%pn", (void *) p);
p--;
printf ("%pn", (void *) p);
return 0;
}
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 <stdio.h>
int main (void)
{
struct { char a[8], b[8]; } v;
char *p;
p = &v.b[0];
printf ("%pn", (void *) p);
p--;
printf ("%pn", (void *) p);
return 0;
}
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 <stdio.h>
int main (void)
{
struct { char a[8], b[8]; } v;
char *p;
p = &v.b[0];
printf ("%pn", (void *) p);
p--;
printf ("%pn", (void *) p);
return 0;
}
--{ Vincent Lefevre a plopé ceci: }--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:
C'est un peu capillotracté, ton raisonnement...
--{ Vincent Lefevre a plopé ceci: }--
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:
C'est un peu capillotracté, ton raisonnement...
--{ Vincent Lefevre a plopé ceci: }--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:
C'est un peu capillotracté, ton raisonnement...
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'.
Ou alors, la capacite des gcc recents a faire disparaitre des memset a 0,
s'ils touchent des variables non utilisees ensuite (pratique commune pour
virer des mot de passe en clair avant de poursuivre le programme), sachant
qu'il n'y a PAS de construction raisonnable permettant d'avoir la
semantique voulue (volatile n'en est pas une, puisqu'elle va generalement
plomber le temps de calcul lie au mot de passe en question).
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'.
Ou alors, la capacite des gcc recents a faire disparaitre des memset a 0,
s'ils touchent des variables non utilisees ensuite (pratique commune pour
virer des mot de passe en clair avant de poursuivre le programme), sachant
qu'il n'y a PAS de construction raisonnable permettant d'avoir la
semantique voulue (volatile n'en est pas une, puisqu'elle va generalement
plomber le temps de calcul lie au mot de passe en question).
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'.
Ou alors, la capacite des gcc recents a faire disparaitre des memset a 0,
s'ils touchent des variables non utilisees ensuite (pratique commune pour
virer des mot de passe en clair avant de poursuivre le programme), sachant
qu'il n'y a PAS de construction raisonnable permettant d'avoir la
semantique voulue (volatile n'en est pas une, puisqu'elle va generalement
plomber le temps de calcul lie au mot de passe en question).
Est-ce qu'avec des casts avec volatile seulement dans certains cas,
cela serait une solution acceptable?
Est-ce qu'avec des casts avec volatile seulement dans certains cas,
cela serait une solution acceptable?
Est-ce qu'avec des casts avec volatile seulement dans certains cas,
cela serait une solution acceptable?
En fait le C est portable et justement ne peut être un "assembleur
portable".
En fait le C est portable et justement ne peut être un "assembleur
portable".
En fait le C est portable et justement ne peut être un "assembleur
portable".
int main(void)
{
int a, b, c, test; /* non volatile data*/
(volatile void)test;
(volatile void)(a = 0);
int main(void)
{
int a, b, c, test; /* non volatile data*/
(volatile void)test;
(volatile void)(a = 0);
int main(void)
{
int a, b, c, test; /* non volatile data*/
(volatile void)test;
(volatile void)(a = 0);
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).
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).
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).