salut
Je me demande quel est l'interet d'appeler la fonction exit() plutot que
return.
Par exemple, si j'ai le programme suivant:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
(void) printf("salut\n") ;
return EXIT_SUCCESS ;
}
et celui-ci:
int main(void)
{
(void) printf("salut\n") ;
exit(EXIT_SUCCESS) ;
}
Qu'est-ce que ca change? Je comprend pas tres bien...si quelqu'un peut
m'eclairer. :)
did
--
Toutes des ingrates...
http://www.netbsd.org/fr
http://www.isty-info.uvsq.fr/~rumeau/fclc/
Que si un assert echoue, tu ne sais pas pourquoi et que les structures
echoue? C'est à dire?
La condition testee est fausse (donc le programme s'arrete).
de donnees internes dont dependent les fonctions enregistrees avec atexit peuvent etre corrompues,...
Possible, mais qu'est-ce qu'assert() a à voir là dedans?
assert detecte souvent qu'on se retrouve avec un etat incoherant. Si tu appelles exit, tu executes des fonctions qui peuvent avoir leurs donnees dans un etat incoherant alors qu'elles n'ont pas ete ecrites pour gerer ce cas. Ca peut poser des problemes.
Le meilleur recours en cas d'incoherence dans la majorite des cas (*), c'est l'arret immediat -- eventuellement en loggant le probleme -- sans essayer de remettre de l'ordre ce qui peut faire plus de mal que de bien (cad que le bien qu'on peut faire est minime et le mal tres eleve bien que la proba du bien soit superieure a la proba du mal, l'esperance est negative).
Mince, j'ai chopé un noeud au cerveau...
C'est rare qu'appeler exit pour arreter le programme lors d'un assert pose des problemes, mais quand il en pose les problemes sont importants. Ne pas appeler exit a generalement peu de problemes.
Mais tu es apparemment dans un environnement ou l'OS ne recupere pas toutes les ressources d'un process qui se termine brutalement, c'est *le cas* ou c'est raisonnable de faire plus comme je l'avais ecrit:
La seule chose admissible c'est de rendre des ressources au systeme quand il ne peut pas les recuperer tout seul et on ne peut pas compter sur ce qui est enregistre par atexit pour se limiter a ca. [...]
(*) dans l'embarque on peut parfois mieux faire -- passer au systeme de secours ou redemarrer tout le systeme sont les premieres possibilites qui viennent a l'esprit --, je n'exclus pas des cas ou exit soit adapte mais en faire une polique generale...
Pas d'assert() en embarqué chez moi.
Ah bon, la derniere fois que j'ai fait de l'embarque non seulement nous avions des assert qui faisait ce qu'il fallait (systeme de secours dans notre cas) mais nous avions une tache de fond qui passait son temps a verifier des checksums sur des zones de memoire et le bon fonctionnement du microprocesseur (du genre if (1+1 != 2) { shutdown(); })
Uniquement en debug sur le PC. Je rappelle qu'assert() est un dispositif d'aide au debuggage, et non un mecanisme de sauvegarde (watchdog, trap etc.).
Pourquoi est-ce qu'assert devrait etre limite au debug? Naturellement le comportement est un peu different, mais le test generalement reste tant qu'on n'a pas montre qu'il etait trop couteux.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Emmanuel Delahaye <emdelYOURBRA@noos.fr> writes:
Que si un assert echoue, tu ne sais pas pourquoi et que les structures
echoue? C'est à dire?
La condition testee est fausse (donc le programme s'arrete).
de donnees internes dont dependent les fonctions enregistrees avec
atexit peuvent etre corrompues,...
Possible, mais qu'est-ce qu'assert() a à voir là dedans?
assert detecte souvent qu'on se retrouve avec un etat incoherant. Si
tu appelles exit, tu executes des fonctions qui peuvent avoir leurs
donnees dans un etat incoherant alors qu'elles n'ont pas ete ecrites
pour gerer ce cas. Ca peut poser des problemes.
Le meilleur recours en cas d'incoherence dans la majorite des cas (*),
c'est l'arret immediat -- eventuellement en loggant le probleme --
sans essayer de remettre de l'ordre ce qui peut faire plus de mal que
de bien (cad que le bien qu'on peut faire est minime et le mal tres
eleve bien que la proba du bien soit superieure a la proba du mal,
l'esperance est negative).
Mince, j'ai chopé un noeud au cerveau...
C'est rare qu'appeler exit pour arreter le programme lors d'un assert
pose des problemes, mais quand il en pose les problemes sont
importants. Ne pas appeler exit a generalement peu de problemes.
Mais tu es apparemment dans un environnement ou l'OS ne
recupere pas toutes les ressources d'un process qui se termine
brutalement, c'est *le cas* ou c'est raisonnable de faire plus comme
je l'avais ecrit:
La seule chose admissible c'est de rendre
des ressources au systeme quand il ne peut pas les recuperer tout seul
et on ne peut pas compter sur ce qui est enregistre par atexit pour se
limiter a ca.
[...]
(*) dans l'embarque on peut parfois mieux faire -- passer au systeme
de secours ou redemarrer tout le systeme sont les premieres
possibilites qui viennent a l'esprit --, je n'exclus pas des cas ou
exit soit adapte mais en faire une polique generale...
Pas d'assert() en embarqué chez moi.
Ah bon, la derniere fois que j'ai fait de l'embarque non seulement
nous avions des assert qui faisait ce qu'il fallait (systeme de
secours dans notre cas) mais nous avions une tache de fond qui passait
son temps a verifier des checksums sur des zones de memoire et le bon
fonctionnement du microprocesseur (du genre if (1+1 != 2) {
shutdown(); })
Uniquement en debug sur le PC. Je rappelle qu'assert() est un
dispositif d'aide au debuggage, et non un mecanisme de sauvegarde
(watchdog, trap etc.).
Pourquoi est-ce qu'assert devrait etre limite au debug? Naturellement
le comportement est un peu different, mais le test generalement reste
tant qu'on n'a pas montre qu'il etait trop couteux.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Que si un assert echoue, tu ne sais pas pourquoi et que les structures
echoue? C'est à dire?
La condition testee est fausse (donc le programme s'arrete).
de donnees internes dont dependent les fonctions enregistrees avec atexit peuvent etre corrompues,...
Possible, mais qu'est-ce qu'assert() a à voir là dedans?
assert detecte souvent qu'on se retrouve avec un etat incoherant. Si tu appelles exit, tu executes des fonctions qui peuvent avoir leurs donnees dans un etat incoherant alors qu'elles n'ont pas ete ecrites pour gerer ce cas. Ca peut poser des problemes.
Le meilleur recours en cas d'incoherence dans la majorite des cas (*), c'est l'arret immediat -- eventuellement en loggant le probleme -- sans essayer de remettre de l'ordre ce qui peut faire plus de mal que de bien (cad que le bien qu'on peut faire est minime et le mal tres eleve bien que la proba du bien soit superieure a la proba du mal, l'esperance est negative).
Mince, j'ai chopé un noeud au cerveau...
C'est rare qu'appeler exit pour arreter le programme lors d'un assert pose des problemes, mais quand il en pose les problemes sont importants. Ne pas appeler exit a generalement peu de problemes.
Mais tu es apparemment dans un environnement ou l'OS ne recupere pas toutes les ressources d'un process qui se termine brutalement, c'est *le cas* ou c'est raisonnable de faire plus comme je l'avais ecrit:
La seule chose admissible c'est de rendre des ressources au systeme quand il ne peut pas les recuperer tout seul et on ne peut pas compter sur ce qui est enregistre par atexit pour se limiter a ca. [...]
(*) dans l'embarque on peut parfois mieux faire -- passer au systeme de secours ou redemarrer tout le systeme sont les premieres possibilites qui viennent a l'esprit --, je n'exclus pas des cas ou exit soit adapte mais en faire une polique generale...
Pas d'assert() en embarqué chez moi.
Ah bon, la derniere fois que j'ai fait de l'embarque non seulement nous avions des assert qui faisait ce qu'il fallait (systeme de secours dans notre cas) mais nous avions une tache de fond qui passait son temps a verifier des checksums sur des zones de memoire et le bon fonctionnement du microprocesseur (du genre if (1+1 != 2) { shutdown(); })
Uniquement en debug sur le PC. Je rappelle qu'assert() est un dispositif d'aide au debuggage, et non un mecanisme de sauvegarde (watchdog, trap etc.).
Pourquoi est-ce qu'assert devrait etre limite au debug? Naturellement le comportement est un peu different, mais le test generalement reste tant qu'on n'a pas montre qu'il etait trop couteux.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre
Dans l'article <bfhb9e$4q3$, Manu écrit:
C'est plus compact mais je trouve le (void)0 relativement peu "lisible".
/* commentaire éventuel sur la signification de ce qui suit */ #define RIEN ((void)0)
et ensuite tu utilises RIEN dans ton code...
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <bfhb9e$4q3$1@news-reader1.wanadoo.fr>,
Manu <news_NOSPAM@guzu.net> écrit:
C'est plus compact mais je trouve le (void)0 relativement peu "lisible".
/* commentaire éventuel sur la signification de ce qui suit */
#define RIEN ((void)0)
et ensuite tu utilises RIEN dans ton code...
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
/* dans main() */ #ifdef DEBOGUANT signal(SIGABORT, el_meu_abort); #endif
/* ... */
void el_meu_abort(int) {
/* ... */ exit(EXIT_FAILURE); }
Astucieux! Je vais y reflechir.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Emmanuel Delahaye
In 'fr.comp.lang.c', Jean-Marc Bourguet wrote:
assert detecte souvent qu'on se retrouve avec un etat incoherant. Si tu appelles exit, tu executes des fonctions qui peuvent avoir leurs donnees dans un etat incoherant alors qu'elles n'ont pas ete ecrites pour gerer ce cas. Ca peut poser des problemes.
C'est possible...
(*) dans l'embarque on peut parfois mieux faire -- passer au systeme de secours ou redemarrer tout le systeme sont les premieres possibilites qui viennent a l'esprit --, je n'exclus pas des cas ou exit soit adapte mais en faire une polique generale...
Pas d'assert() en embarqué chez moi.
Ah bon, la derniere fois que j'ai fait de l'embarque non seulement nous avions des assert qui faisait ce qu'il fallait (systeme de secours dans notre cas)
Dans les systèmes embarqués que j'utilise, la "sortie" (abort(), exit()) n'a aucun sens. C'est pour ça que les assert() ne sont pas compilés (mode NDEBUG). Pour la nième fois, assert() est un outil de debug, pas d'exploitation.
En fait, en cas d'erreur irrécupérable, on masque le IT, on se met dans une boucle sans fin 'for(;;);', et on laisse faire la nature : la tâche de fond n'étant plus effectuée, le watchdog n'est plus activé et un reset hard est déclenché au bout d'un moment par un mécanisme extérieur. Tout le système redémmarre comme lors d'une mise sous tension.
Uniquement en debug sur le PC. Je rappelle qu'assert() est un dispositif d'aide au debuggage, et non un mecanisme de sauvegarde (watchdog, trap etc.).
Pourquoi est-ce qu'assert devrait etre limite au debug?
Parce qu'il a été conçu pour ça.
Naturellement le comportement est un peu different, mais le test generalement reste tant qu'on n'a pas montre qu'il etait trop couteux.
Tu n'as pas l'air de comprendre le rôle de la macro globale NDEBUG... En production, les assert() ne sont pas compilés du tout. Rien, aucun code, aucun test. C'est si dur à comprendre?
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Jean-Marc Bourguet <jm@bourguet.org> wrote:
assert detecte souvent qu'on se retrouve avec un etat incoherant. Si
tu appelles exit, tu executes des fonctions qui peuvent avoir leurs
donnees dans un etat incoherant alors qu'elles n'ont pas ete ecrites
pour gerer ce cas. Ca peut poser des problemes.
C'est possible...
(*) dans l'embarque on peut parfois mieux faire -- passer au systeme
de secours ou redemarrer tout le systeme sont les premieres
possibilites qui viennent a l'esprit --, je n'exclus pas des cas ou
exit soit adapte mais en faire une polique generale...
Pas d'assert() en embarqué chez moi.
Ah bon, la derniere fois que j'ai fait de l'embarque non seulement
nous avions des assert qui faisait ce qu'il fallait (systeme de
secours dans notre cas)
Dans les systèmes embarqués que j'utilise, la "sortie" (abort(), exit()) n'a
aucun sens. C'est pour ça que les assert() ne sont pas compilés (mode
NDEBUG). Pour la nième fois, assert() est un outil de debug, pas
d'exploitation.
En fait, en cas d'erreur irrécupérable, on masque le IT, on se met dans une
boucle sans fin 'for(;;);', et on laisse faire la nature : la tâche de fond
n'étant plus effectuée, le watchdog n'est plus activé et un reset hard est
déclenché au bout d'un moment par un mécanisme extérieur. Tout le système
redémmarre comme lors d'une mise sous tension.
Uniquement en debug sur le PC. Je rappelle qu'assert() est un
dispositif d'aide au debuggage, et non un mecanisme de sauvegarde
(watchdog, trap etc.).
Pourquoi est-ce qu'assert devrait etre limite au debug?
Parce qu'il a été conçu pour ça.
Naturellement
le comportement est un peu different, mais le test generalement reste
tant qu'on n'a pas montre qu'il etait trop couteux.
Tu n'as pas l'air de comprendre le rôle de la macro globale NDEBUG... En
production, les assert() ne sont pas compilés du tout. Rien, aucun code,
aucun test. C'est si dur à comprendre?
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
assert detecte souvent qu'on se retrouve avec un etat incoherant. Si tu appelles exit, tu executes des fonctions qui peuvent avoir leurs donnees dans un etat incoherant alors qu'elles n'ont pas ete ecrites pour gerer ce cas. Ca peut poser des problemes.
C'est possible...
(*) dans l'embarque on peut parfois mieux faire -- passer au systeme de secours ou redemarrer tout le systeme sont les premieres possibilites qui viennent a l'esprit --, je n'exclus pas des cas ou exit soit adapte mais en faire une polique generale...
Pas d'assert() en embarqué chez moi.
Ah bon, la derniere fois que j'ai fait de l'embarque non seulement nous avions des assert qui faisait ce qu'il fallait (systeme de secours dans notre cas)
Dans les systèmes embarqués que j'utilise, la "sortie" (abort(), exit()) n'a aucun sens. C'est pour ça que les assert() ne sont pas compilés (mode NDEBUG). Pour la nième fois, assert() est un outil de debug, pas d'exploitation.
En fait, en cas d'erreur irrécupérable, on masque le IT, on se met dans une boucle sans fin 'for(;;);', et on laisse faire la nature : la tâche de fond n'étant plus effectuée, le watchdog n'est plus activé et un reset hard est déclenché au bout d'un moment par un mécanisme extérieur. Tout le système redémmarre comme lors d'une mise sous tension.
Uniquement en debug sur le PC. Je rappelle qu'assert() est un dispositif d'aide au debuggage, et non un mecanisme de sauvegarde (watchdog, trap etc.).
Pourquoi est-ce qu'assert devrait etre limite au debug?
Parce qu'il a été conçu pour ça.
Naturellement le comportement est un peu different, mais le test generalement reste tant qu'on n'a pas montre qu'il etait trop couteux.
Tu n'as pas l'air de comprendre le rôle de la macro globale NDEBUG... En production, les assert() ne sont pas compilés du tout. Rien, aucun code, aucun test. C'est si dur à comprendre?
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Antoine Leca
EpSyLOn écrivit:
In 'fr.comp.lang.c', "Antoine Leca" wrote:
/* dans main() */ #ifdef DEBOGUANT signal(SIGABORT, el_meu_abort); #endif
/* ... */
void el_meu_abort(int) {
/* ... */ exit(EXIT_FAILURE); }
La question est : est-il possible de faire tout ce que l'on veut (écriture sur flux par exemple) dans un gestionnaire de signal ?
La question n'était absolument pas celle-là. Cela étant, puisque tu la poses...
D'abord, on ne peut jamais « faire tout ce que l'on veut ».
Si on passe sur la sémantique, dans signal(), il faut distinguer « ce que l'on peut faire de manière toujours portable » (autrement dit dans un programme strictement conforme), et qui est passablement réduit, au point que certains opinent que l'on ne peut rien faire du tout (la norme dit, positionner une variable de type sig_atomic_t);
et d'autre part « ce que l'on peut faire de manière intelligente ». Dans ce cas, on sait que l'on va, tôt ou tard et plutôt tôt que tard, sortir de l'exécution, en fermant les fichiers. Une bonne option est donc de vider les tampons, ce qui de fait implique des écritures sur les flux. Bien sûr, cela dépend après de la structure de ton programme, et en particulier de l'endroit où sont précisement les assert() (si c'est à l'interieur d'une routine qui réalise effectivement les E/S, cela va probablement mal marcher...) : c'est pour cela que cela n'est pas "complètement portable".
Antoine
EpSyLOn écrivit:
In 'fr.comp.lang.c', "Antoine Leca" <root@localhost.gov> wrote:
/* dans main() */
#ifdef DEBOGUANT
signal(SIGABORT, el_meu_abort);
#endif
/* ... */
void el_meu_abort(int) {
/* ... */
exit(EXIT_FAILURE);
}
La question est : est-il possible de faire tout ce que l'on veut
(écriture sur flux par exemple) dans un gestionnaire de signal ?
La question n'était absolument pas celle-là.
Cela étant, puisque tu la poses...
D'abord, on ne peut jamais « faire tout ce que l'on veut ».
Si on passe sur la sémantique, dans signal(), il faut distinguer
« ce que l'on peut faire de manière toujours portable »
(autrement dit dans un programme strictement conforme),
et qui est passablement réduit, au point que certains opinent
que l'on ne peut rien faire du tout (la norme dit, positionner une
variable de type sig_atomic_t);
et d'autre part « ce que l'on peut faire de manière intelligente ».
Dans ce cas, on sait que l'on va, tôt ou tard et plutôt tôt que
tard, sortir de l'exécution, en fermant les fichiers. Une bonne
option est donc de vider les tampons, ce qui de fait implique
des écritures sur les flux.
Bien sûr, cela dépend après de la structure de ton programme,
et en particulier de l'endroit où sont précisement les assert()
(si c'est à l'interieur d'une routine qui réalise effectivement
les E/S, cela va probablement mal marcher...) : c'est pour
cela que cela n'est pas "complètement portable".
/* dans main() */ #ifdef DEBOGUANT signal(SIGABORT, el_meu_abort); #endif
/* ... */
void el_meu_abort(int) {
/* ... */ exit(EXIT_FAILURE); }
La question est : est-il possible de faire tout ce que l'on veut (écriture sur flux par exemple) dans un gestionnaire de signal ?
La question n'était absolument pas celle-là. Cela étant, puisque tu la poses...
D'abord, on ne peut jamais « faire tout ce que l'on veut ».
Si on passe sur la sémantique, dans signal(), il faut distinguer « ce que l'on peut faire de manière toujours portable » (autrement dit dans un programme strictement conforme), et qui est passablement réduit, au point que certains opinent que l'on ne peut rien faire du tout (la norme dit, positionner une variable de type sig_atomic_t);
et d'autre part « ce que l'on peut faire de manière intelligente ». Dans ce cas, on sait que l'on va, tôt ou tard et plutôt tôt que tard, sortir de l'exécution, en fermant les fichiers. Une bonne option est donc de vider les tampons, ce qui de fait implique des écritures sur les flux. Bien sûr, cela dépend après de la structure de ton programme, et en particulier de l'endroit où sont précisement les assert() (si c'est à l'interieur d'une routine qui réalise effectivement les E/S, cela va probablement mal marcher...) : c'est pour cela que cela n'est pas "complètement portable".
