int main(void)
{
/* inclusion interdite dans le corps d'une fonction externe */
#include <string.h>
printf("%u\n", strlen("toto"));
return 0;
}
Compilé de la manière suivante
$ gcc -Wall -Wextra -std=c99 -pedantic erreurO2.c
aucun avertissement ni erreur n'est affiché par le compilateur et l'exécution se
déroule sans erreur visible.
Compilé avec une simple option d'optimisation :
$ gcc -O2 erreurOpt.c
cela permet de détecter une succession d'erreurs dont voici le début de la liste :
In file included from /usr/include/string.h:423,
from erreurO2.c:6:
/usr/include/bits/string2.h: Dans la fonction «main» :
/usr/include/bits/string2.h:972: erreur: nested function «__strcspn_c1» declared
«extern»
/usr/include/bits/string2.h:983: erreur: nested function «__strcspn_c2» declared
«extern»
Je ne sais pas si mon exemple est reproductible sous d'autres compilateur et/ou
d'autres plateformes.
Mais, existe-t-il une "recommandation" qui suggèrerait de compiler
systématiquement ses sources avec une option assez élevée d'optimisation afin de
diminuer la possibilité d'avoir un comportement indéterminé (et non dans le but
d'améliorer le temps d'exécution) ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
espie
In article <4999412f$0$15770$, candide wrote:
Mais, existe-t-il une "recommandation" qui suggèrerait de compiler systématiquement ses sources avec une option assez élevée d'optimisation afin de diminuer la possibilité d'avoir un comportement indéterminé (et non dans le but d'améliorer le temps d'exécution) ?
Oui, c'est un comportement connu de gcc: il fait plus d'analyse quand on compile en -O quelque chose.
En des temps recules, la recommendation etait meme de compiler systematiquement avec -O2, parce que c'etait la seule option de generation de code qui etait vraiment bien testee...
Lorsque j'enseigne le C, je recommande systematiquement -O2 -g -W -Wall
(pas fan de -stdÉ9 -pedantic), et j'explique le pourquoi du -O2.
In article <4999412f$0$15770$426a74cc@news.free.fr>,
candide <candide@free.invalid> wrote:
Mais, existe-t-il une "recommandation" qui suggèrerait de compiler
systématiquement ses sources avec une option assez élevée d'optimisation afin de
diminuer la possibilité d'avoir un comportement indéterminé (et non dans le but
d'améliorer le temps d'exécution) ?
Oui, c'est un comportement connu de gcc: il fait plus d'analyse quand on
compile en -O quelque chose.
En des temps recules, la recommendation etait meme de compiler systematiquement
avec -O2, parce que c'etait la seule option de generation de code qui etait
vraiment bien testee...
Lorsque j'enseigne le C, je recommande systematiquement
-O2 -g -W -Wall
(pas fan de -stdÉ9 -pedantic), et j'explique le pourquoi du -O2.
Mais, existe-t-il une "recommandation" qui suggèrerait de compiler systématiquement ses sources avec une option assez élevée d'optimisation afin de diminuer la possibilité d'avoir un comportement indéterminé (et non dans le but d'améliorer le temps d'exécution) ?
Oui, c'est un comportement connu de gcc: il fait plus d'analyse quand on compile en -O quelque chose.
En des temps recules, la recommendation etait meme de compiler systematiquement avec -O2, parce que c'etait la seule option de generation de code qui etait vraiment bien testee...
Lorsque j'enseigne le C, je recommande systematiquement -O2 -g -W -Wall
(pas fan de -stdÉ9 -pedantic), et j'explique le pourquoi du -O2.
candide
Marc Espie a écrit :
Lorsque j'enseigne le C, je recommande systematiquement -O2 -g -W -Wall
Ben oui, evidemment. Si tu veux debugguer ton code, tu es bien oblige d'avoir le -g, et je ne vois pas l'interet de debugguer autre chose que le code qui va te servir. Il y a tout un ensemble de problemes debiles qui ne vont pas se poser avec -O0 (typiquement, gcc a une facheuse tendance a initialiser les variables locales a 0. ;( ). Quelques petites choses a savoir: - la presence ou l'absence de -g n'est pas censee modifier le code genere. S'il y a une difference, c'est un gros bug (c'etait ecrit noir sur blanc dans le cahier des charges de gcc...) - gdb se depetre raisonnablement bien de code compile avec -O2. Il faut juste parfois se rendre compte qu'on n'avance plus forcement ligne a ligne, et que les valeurs de variable sont parfois modifiees "apres coup". - sur tout systeme moderne, on peut virer les infos de debug si elles prennent trop de place sur disque, et ca donne la meme chose que si on avait compile avec -O2 seul (la-encore, si ca n'est pas le cas, c'est un gros bug). - sur tout systeme moderne, les infos de debut ne sont chargees QUE dans le debuggueur, et donc ne changent rien a l'efficacite du code lors d'une execution normale...
In article <49997a7f$0$3303$426a74cc@news.free.fr>,
candide <candide@free.invalid> wrote:
Marc Espie a écrit :
Lorsque j'enseigne le C, je recommande systematiquement
-O2 -g -W -Wall
Ben oui, evidemment. Si tu veux debugguer ton code, tu es bien oblige d'avoir
le -g, et je ne vois pas l'interet de debugguer autre chose que le code qui
va te servir. Il y a tout un ensemble de problemes debiles qui ne vont pas
se poser avec -O0 (typiquement, gcc a une facheuse tendance a initialiser
les variables locales a 0. ;( ). Quelques petites choses a savoir:
- la presence ou l'absence de -g n'est pas censee modifier le code genere.
S'il y a une difference, c'est un gros bug (c'etait ecrit noir sur blanc
dans le cahier des charges de gcc...)
- gdb se depetre raisonnablement bien de code compile avec -O2. Il faut juste
parfois se rendre compte qu'on n'avance plus forcement ligne a ligne, et que
les valeurs de variable sont parfois modifiees "apres coup".
- sur tout systeme moderne, on peut virer les infos de debug si elles prennent
trop de place sur disque, et ca donne la meme chose que si on avait compile
avec -O2 seul (la-encore, si ca n'est pas le cas, c'est un gros bug).
- sur tout systeme moderne, les infos de debut ne sont chargees QUE dans le
debuggueur, et donc ne changent rien a l'efficacite du code lors d'une
execution normale...
Ben oui, evidemment. Si tu veux debugguer ton code, tu es bien oblige d'avoir le -g, et je ne vois pas l'interet de debugguer autre chose que le code qui va te servir. Il y a tout un ensemble de problemes debiles qui ne vont pas se poser avec -O0 (typiquement, gcc a une facheuse tendance a initialiser les variables locales a 0. ;( ). Quelques petites choses a savoir: - la presence ou l'absence de -g n'est pas censee modifier le code genere. S'il y a une difference, c'est un gros bug (c'etait ecrit noir sur blanc dans le cahier des charges de gcc...) - gdb se depetre raisonnablement bien de code compile avec -O2. Il faut juste parfois se rendre compte qu'on n'avance plus forcement ligne a ligne, et que les valeurs de variable sont parfois modifiees "apres coup". - sur tout systeme moderne, on peut virer les infos de debug si elles prennent trop de place sur disque, et ca donne la meme chose que si on avait compile avec -O2 seul (la-encore, si ca n'est pas le cas, c'est un gros bug). - sur tout systeme moderne, les infos de debut ne sont chargees QUE dans le debuggueur, et donc ne changent rien a l'efficacite du code lors d'une execution normale...
Xavier Roche
Marc Espie a écrit :
- sur tout systeme moderne, on peut virer les infos de debug si elles prennent trop de place sur disque, et ca donne la meme chose que si on avait compile avec -O2 seul
[gcc] On peut également les séparer en deux morceaux en jouant avec objcopy (objcopy --only-keep-debug et ses amis) et ainsi, dans un gros projet, livrer les fichiers de debuggage "à côté".
Et sous Visual c++, on a les .pdb, de manière analogue.
Marc Espie a écrit :
- sur tout systeme moderne, on peut virer les infos de debug si elles prennent
trop de place sur disque, et ca donne la meme chose que si on avait compile
avec -O2 seul
[gcc] On peut également les séparer en deux morceaux en jouant avec
objcopy (objcopy --only-keep-debug et ses amis) et ainsi, dans un gros
projet, livrer les fichiers de debuggage "à côté".
Et sous Visual c++, on a les .pdb, de manière analogue.
- sur tout systeme moderne, on peut virer les infos de debug si elles prennent trop de place sur disque, et ca donne la meme chose que si on avait compile avec -O2 seul
[gcc] On peut également les séparer en deux morceaux en jouant avec objcopy (objcopy --only-keep-debug et ses amis) et ainsi, dans un gros projet, livrer les fichiers de debuggage "à côté".
Et sous Visual c++, on a les .pdb, de manière analogue.
jacob navia
candide wrote:
Bonjour
J'ai écris la facétie suivante :
/* erreurOpt.c */ #include <stdio.h>
int main(void) { /* inclusion interdite dans le corps d'une fonction externe */ #include <string.h>
printf("%un", strlen("toto"));
return 0; }
Compilé de la manière suivante
$ gcc -Wall -Wextra -stdÉ9 -pedantic erreurO2.c
aucun avertissement ni erreur n'est affiché par le compilateur et l'exécution se déroule sans erreur visible.
Compilé avec une simple option d'optimisation :
$ gcc -O2 erreurOpt.c
cela permet de détecter une succession d'erreurs dont voici le début de la liste :
In file included from /usr/include/string.h:423, from erreurO2.c:6: /usr/include/bits/string2.h: Dans la fonction «main» : /usr/include/bits/string2.h:972: erreur: nested function «__strcspn_c1» declared «extern» /usr/include/bits/string2.h:983: erreur: nested function «__strcspn_c2» declared «extern»
Je ne sais pas si mon exemple est reproductible sous d'autres compilateur et/ou d'autres plateformes.
Mais, existe-t-il une "recommandation" qui suggèrerait de compiler systématiquement ses sources avec une option assez élevée d'optimisation afin de diminuer la possibilité d'avoir un comportement indéterminé (et non dans le but d'améliorer le temps d'exécution) ?
strcspn est inline,
Si l'optimisation est ON alors t'as une fonction dans une autre (nested function).
Sans optimisation l'inline est ignoré, et tout marche bien.
candide wrote:
Bonjour
J'ai écris la facétie suivante :
/* erreurOpt.c */
#include <stdio.h>
int main(void)
{
/* inclusion interdite dans le corps d'une fonction externe */
#include <string.h>
printf("%un", strlen("toto"));
return 0;
}
Compilé de la manière suivante
$ gcc -Wall -Wextra -stdÉ9 -pedantic erreurO2.c
aucun avertissement ni erreur n'est affiché par le compilateur et l'exécution se
déroule sans erreur visible.
Compilé avec une simple option d'optimisation :
$ gcc -O2 erreurOpt.c
cela permet de détecter une succession d'erreurs dont voici le début de la liste :
In file included from /usr/include/string.h:423,
from erreurO2.c:6:
/usr/include/bits/string2.h: Dans la fonction «main» :
/usr/include/bits/string2.h:972: erreur: nested function «__strcspn_c1» declared
«extern»
/usr/include/bits/string2.h:983: erreur: nested function «__strcspn_c2» declared
«extern»
Je ne sais pas si mon exemple est reproductible sous d'autres compilateur et/ou
d'autres plateformes.
Mais, existe-t-il une "recommandation" qui suggèrerait de compiler
systématiquement ses sources avec une option assez élevée d'optimisation afin de
diminuer la possibilité d'avoir un comportement indéterminé (et non dans le but
d'améliorer le temps d'exécution) ?
strcspn est inline,
Si l'optimisation est ON alors t'as une fonction dans une autre (nested
function).
Sans optimisation l'inline est ignoré, et tout marche bien.
int main(void) { /* inclusion interdite dans le corps d'une fonction externe */ #include <string.h>
printf("%un", strlen("toto"));
return 0; }
Compilé de la manière suivante
$ gcc -Wall -Wextra -stdÉ9 -pedantic erreurO2.c
aucun avertissement ni erreur n'est affiché par le compilateur et l'exécution se déroule sans erreur visible.
Compilé avec une simple option d'optimisation :
$ gcc -O2 erreurOpt.c
cela permet de détecter une succession d'erreurs dont voici le début de la liste :
In file included from /usr/include/string.h:423, from erreurO2.c:6: /usr/include/bits/string2.h: Dans la fonction «main» : /usr/include/bits/string2.h:972: erreur: nested function «__strcspn_c1» declared «extern» /usr/include/bits/string2.h:983: erreur: nested function «__strcspn_c2» declared «extern»
Je ne sais pas si mon exemple est reproductible sous d'autres compilateur et/ou d'autres plateformes.
Mais, existe-t-il une "recommandation" qui suggèrerait de compiler systématiquement ses sources avec une option assez élevée d'optimisation afin de diminuer la possibilité d'avoir un comportement indéterminé (et non dans le but d'améliorer le temps d'exécution) ?
strcspn est inline,
Si l'optimisation est ON alors t'as une fonction dans une autre (nested function).
Sans optimisation l'inline est ignoré, et tout marche bien.
