Quel est l'intérêt d'utiliser cela à la place d'un exit(0); ?
C'est juste l'opposé.
Est-ce que cela change quelque chose d'important lors de la compilation du programme ?
Cela n'a rien à voir avec la compilation.
Est-ce mieux de l'utiliser alors en lieu et place de return(0) ?
return n'est pas une fonction, donc pas de parenthèse.
return 0 est identique à exit(0) uniquement dans le main et à condition que le code de retour du main soit d'un type compatible avec int.
La fonction exit peut avoir 3 valeurs dont le résultat est spécifiée dans la norme C. Les extensions à d'autres plages de valeurs sont du ressort d'autres normes, type Posix.
#include <stdlib.h> void exit(int status);
If the value of status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned. If the value of status is EXIT_FAILURE, an implementation-defined form of the status unsuccessful termination is returned. Otherwise the status returned is implementation-defined.
-- Éric Lévénez FAQ de fclc : <http://www.levenez.com/lang/c/faq/>
Le 11/07/11 22:03, David Remacle a écrit :
exit(EXIT_FAILURE);
Quel est l'intérêt d'utiliser cela à la place d'un exit(0); ?
C'est juste l'opposé.
Est-ce que cela change quelque chose d'important lors de la compilation
du programme ?
Cela n'a rien à voir avec la compilation.
Est-ce mieux de l'utiliser alors en lieu et place de return(0) ?
return n'est pas une fonction, donc pas de parenthèse.
return 0 est identique à exit(0) uniquement dans le main et à condition
que le code de retour du main soit d'un type compatible avec int.
La fonction exit peut avoir 3 valeurs dont le résultat est spécifiée
dans la norme C. Les extensions à d'autres plages de valeurs sont du
ressort d'autres normes, type Posix.
#include <stdlib.h>
void exit(int status);
If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful termination is
returned. If the value of status is EXIT_FAILURE, an
implementation-defined form of the status unsuccessful termination is
returned. Otherwise the status returned is implementation-defined.
--
Éric Lévénez
FAQ de fclc : <http://www.levenez.com/lang/c/faq/>
Quel est l'intérêt d'utiliser cela à la place d'un exit(0); ?
C'est juste l'opposé.
Est-ce que cela change quelque chose d'important lors de la compilation du programme ?
Cela n'a rien à voir avec la compilation.
Est-ce mieux de l'utiliser alors en lieu et place de return(0) ?
return n'est pas une fonction, donc pas de parenthèse.
return 0 est identique à exit(0) uniquement dans le main et à condition que le code de retour du main soit d'un type compatible avec int.
La fonction exit peut avoir 3 valeurs dont le résultat est spécifiée dans la norme C. Les extensions à d'autres plages de valeurs sont du ressort d'autres normes, type Posix.
#include <stdlib.h> void exit(int status);
If the value of status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned. If the value of status is EXIT_FAILURE, an implementation-defined form of the status unsuccessful termination is returned. Otherwise the status returned is implementation-defined.
-- Éric Lévénez FAQ de fclc : <http://www.levenez.com/lang/c/faq/>
david.remacle
Éric Lévénez wrote:
Le 11/07/11 22:03, David Remacle a écrit :
> exit(EXIT_FAILURE); > > Quel est l'intérêt d'utiliser cela à la place d'un exit(0); ?
C'est juste l'opposé.
> Est-ce que cela change quelque chose d'important lors de la compilation > du programme ?
Cela n'a rien à voir avec la compilation.
> Est-ce mieux de l'utiliser alors en lieu et place de return(0) ?
return n'est pas une fonction, donc pas de parenthèse.
return 0 est identique à exit(0) uniquement dans le main et à condition que le code de retour du main soit d'un type compatible avec int.
La fonction exit peut avoir 3 valeurs dont le résultat est spécifiée dans la norme C. Les extensions à d'autres plages de valeurs sont du ressort d'autres normes, type Posix.
#include <stdlib.h> void exit(int status);
If the value of status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned. If the value of status is EXIT_FAILURE, an implementation-defined form of the status unsuccessful termination is returned. Otherwise the status returned is implementation-defined.
Merci Eric, Une fois de plus tu prends du temps à me répondre et j'apprécie.
Éric Lévénez <usenet@levenez.com> wrote:
Le 11/07/11 22:03, David Remacle a écrit :
> exit(EXIT_FAILURE);
>
> Quel est l'intérêt d'utiliser cela à la place d'un exit(0); ?
C'est juste l'opposé.
> Est-ce que cela change quelque chose d'important lors de la compilation
> du programme ?
Cela n'a rien à voir avec la compilation.
> Est-ce mieux de l'utiliser alors en lieu et place de return(0) ?
return n'est pas une fonction, donc pas de parenthèse.
return 0 est identique à exit(0) uniquement dans le main et à condition
que le code de retour du main soit d'un type compatible avec int.
La fonction exit peut avoir 3 valeurs dont le résultat est spécifiée
dans la norme C. Les extensions à d'autres plages de valeurs sont du
ressort d'autres normes, type Posix.
#include <stdlib.h>
void exit(int status);
If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful termination is
returned. If the value of status is EXIT_FAILURE, an
implementation-defined form of the status unsuccessful termination is
returned. Otherwise the status returned is implementation-defined.
Merci Eric, Une fois de plus tu prends du temps à me répondre et
j'apprécie.
> exit(EXIT_FAILURE); > > Quel est l'intérêt d'utiliser cela à la place d'un exit(0); ?
C'est juste l'opposé.
> Est-ce que cela change quelque chose d'important lors de la compilation > du programme ?
Cela n'a rien à voir avec la compilation.
> Est-ce mieux de l'utiliser alors en lieu et place de return(0) ?
return n'est pas une fonction, donc pas de parenthèse.
return 0 est identique à exit(0) uniquement dans le main et à condition que le code de retour du main soit d'un type compatible avec int.
La fonction exit peut avoir 3 valeurs dont le résultat est spécifiée dans la norme C. Les extensions à d'autres plages de valeurs sont du ressort d'autres normes, type Posix.
#include <stdlib.h> void exit(int status);
If the value of status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned. If the value of status is EXIT_FAILURE, an implementation-defined form of the status unsuccessful termination is returned. Otherwise the status returned is implementation-defined.
Merci Eric, Une fois de plus tu prends du temps à me répondre et j'apprécie.
daniel
On 11/07/2011 22:03, David Remacle wrote:
Bonjour/bonsoir,
J'ai ouvert un pdf sur les sockets windows et linux (c'est juste pour l'avoir lorsque j'aurai a jouer avec les sockets).
bonjour, si ce pdf est disponible sur le net, est-ce que vous pourriez en donner l'URL, ce sujet m'intèresse bigrement, merci
On 11/07/2011 22:03, David Remacle wrote:
Bonjour/bonsoir,
J'ai ouvert un pdf sur les sockets windows et linux (c'est juste pour
l'avoir lorsque j'aurai a jouer avec les sockets).
bonjour,
si ce pdf est disponible sur le net, est-ce que vous pourriez en donner
l'URL, ce sujet m'intèresse bigrement,
merci
Je n'ai survolé que la partie GNU/Linux (et pas la partie Windows), mais pour une fois, je trouve cela plutôt bien fait (au niveau socket), même si limité aux sockets IPv4.
Il aurait été intéressant d'utiliser une fonction comme getaddrinfo à la place du vieillissant gethostbyname pour avoir un code beaucoup plus générique et traiter IPv4 et IPv6. Et conséquence, je suis sûr qu'en utilisant un compilateur récent on a des warnings (comme beaucoup de projets open source C qui supposent trop de choses au niveau du contenu des structures manipulées par les fonctions sockets). Il y a 3 mois, même Linux (le noyau) compilait avec warning sur certaines de ces structures, c'est dire...
-- Éric Lévénez FAQ de fclc : <http://www.levenez.com/lang/c/faq/>
Je n'ai survolé que la partie GNU/Linux (et pas la partie Windows), mais
pour une fois, je trouve cela plutôt bien fait (au niveau socket), même
si limité aux sockets IPv4.
Il aurait été intéressant d'utiliser une fonction comme getaddrinfo à la
place du vieillissant gethostbyname pour avoir un code beaucoup plus
générique et traiter IPv4 et IPv6. Et conséquence, je suis sûr qu'en
utilisant un compilateur récent on a des warnings (comme beaucoup de
projets open source C qui supposent trop de choses au niveau du contenu
des structures manipulées par les fonctions sockets). Il y a 3 mois,
même Linux (le noyau) compilait avec warning sur certaines de ces
structures, c'est dire...
--
Éric Lévénez
FAQ de fclc : <http://www.levenez.com/lang/c/faq/>
Je n'ai survolé que la partie GNU/Linux (et pas la partie Windows), mais pour une fois, je trouve cela plutôt bien fait (au niveau socket), même si limité aux sockets IPv4.
Il aurait été intéressant d'utiliser une fonction comme getaddrinfo à la place du vieillissant gethostbyname pour avoir un code beaucoup plus générique et traiter IPv4 et IPv6. Et conséquence, je suis sûr qu'en utilisant un compilateur récent on a des warnings (comme beaucoup de projets open source C qui supposent trop de choses au niveau du contenu des structures manipulées par les fonctions sockets). Il y a 3 mois, même Linux (le noyau) compilait avec warning sur certaines de ces structures, c'est dire...
-- Éric Lévénez FAQ de fclc : <http://www.levenez.com/lang/c/faq/>
espie
In article <4e2483e9$0$26707$, Éric Lévénez wrote:
Je n'ai survolé que la partie GNU/Linux (et pas la partie Windows), mais pour une fois, je trouve cela plutôt bien fait (au niveau socket), même si limité aux sockets IPv4.
Il aurait été intéressant d'utiliser une fonction comme getaddrinfo à la place du vieillissant gethostbyname pour avoir un code beaucoup plus générique et traiter IPv4 et IPv6. Et conséquence, je suis sûr qu'en utilisant un compilateur récent on a des warnings (comme beaucoup de projets open source C qui supposent trop de choses au niveau du contenu des structures manipulées par les fonctions sockets). Il y a 3 mois, même Linux (le noyau) compilait avec warning sur certaines de ces structures, c'est dire...
C'est aussi un peu dommage que ca ne parle pas (ou alors j'ai rate) de la possibilite d'utiliser read/write sur les socket TCP.
Je n'ai rien vu concernant shutdown() egalement, ni setsockopt(), pourtant bien utile pour debugguer des serveurs...
ni l'existence de telnet, la aussi bien utile pour debugguer tout protocole texte.
je n'ai pas non plus vu la moindre explication concernant l'utilisation de htons...
Bref, perfectible, mais moins mauvais que d'autres...
In article <4e2483e9$0$26707$426a74cc@news.free.fr>,
Éric Lévénez <usenet@levenez.com> wrote:
Je n'ai survolé que la partie GNU/Linux (et pas la partie Windows), mais
pour une fois, je trouve cela plutôt bien fait (au niveau socket), même
si limité aux sockets IPv4.
Il aurait été intéressant d'utiliser une fonction comme getaddrinfo à la
place du vieillissant gethostbyname pour avoir un code beaucoup plus
générique et traiter IPv4 et IPv6. Et conséquence, je suis sûr qu'en
utilisant un compilateur récent on a des warnings (comme beaucoup de
projets open source C qui supposent trop de choses au niveau du contenu
des structures manipulées par les fonctions sockets). Il y a 3 mois,
même Linux (le noyau) compilait avec warning sur certaines de ces
structures, c'est dire...
C'est aussi un peu dommage que ca ne parle pas (ou alors j'ai rate)
de la possibilite d'utiliser read/write sur les socket TCP.
Je n'ai rien vu concernant shutdown() egalement, ni setsockopt(), pourtant
bien utile pour debugguer des serveurs...
ni l'existence de telnet, la aussi bien utile pour debugguer tout protocole
texte.
je n'ai pas non plus vu la moindre explication concernant l'utilisation
de htons...
Bref, perfectible, mais moins mauvais que d'autres...
Je n'ai survolé que la partie GNU/Linux (et pas la partie Windows), mais pour une fois, je trouve cela plutôt bien fait (au niveau socket), même si limité aux sockets IPv4.
Il aurait été intéressant d'utiliser une fonction comme getaddrinfo à la place du vieillissant gethostbyname pour avoir un code beaucoup plus générique et traiter IPv4 et IPv6. Et conséquence, je suis sûr qu'en utilisant un compilateur récent on a des warnings (comme beaucoup de projets open source C qui supposent trop de choses au niveau du contenu des structures manipulées par les fonctions sockets). Il y a 3 mois, même Linux (le noyau) compilait avec warning sur certaines de ces structures, c'est dire...
C'est aussi un peu dommage que ca ne parle pas (ou alors j'ai rate) de la possibilite d'utiliser read/write sur les socket TCP.
Je n'ai rien vu concernant shutdown() egalement, ni setsockopt(), pourtant bien utile pour debugguer des serveurs...
ni l'existence de telnet, la aussi bien utile pour debugguer tout protocole texte.
je n'ai pas non plus vu la moindre explication concernant l'utilisation de htons...
Bref, perfectible, mais moins mauvais que d'autres...
Jean-Marc Bourguet
(Marc Espie) writes:
C'est aussi un peu dommage que ca ne parle pas (ou alors j'ai rate) de la possibilite d'utiliser read/write sur les socket TCP.
Ne serait-ce pas parce que Windows ne le permet pas et que le texte reste autant que possible dans ce qui est commun? (C'est peut-etre vrai aussi pour le reste d'ailleurs, mais ma connaissance de Windows est extrement limitee).
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
espie@lain.home (Marc Espie) writes:
C'est aussi un peu dommage que ca ne parle pas (ou alors j'ai rate)
de la possibilite d'utiliser read/write sur les socket TCP.
Ne serait-ce pas parce que Windows ne le permet pas et que le texte
reste autant que possible dans ce qui est commun? (C'est peut-etre vrai
aussi pour le reste d'ailleurs, mais ma connaissance de Windows est
extrement limitee).
A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
C'est aussi un peu dommage que ca ne parle pas (ou alors j'ai rate) de la possibilite d'utiliser read/write sur les socket TCP.
Ne serait-ce pas parce que Windows ne le permet pas et que le texte reste autant que possible dans ce qui est commun? (C'est peut-etre vrai aussi pour le reste d'ailleurs, mais ma connaissance de Windows est extrement limitee).
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
C'est aussi un peu dommage que ca ne parle pas (ou alors j'ai rate) de la possibilite d'utiliser read/write sur les socket TCP.
Ne serait-ce pas parce que Windows ne le permet pas et que le texte reste autant que possible dans ce qui est commun? (C'est peut-etre vrai aussi pour le reste d'ailleurs, mais ma connaissance de Windows est extrement limitee).
Heureusement que Cygwin est là et il permet d'utiliser read/write.
Peut-être. Mais il ne faut pas titiller trop Cygwin. Selon les versions, on peut avoir des résultats absolument bizarres (je pense à kill() ou pthread_kill() qui peuvent se comporter de manière tout à fait originale). En particulier, j'ai des programmes qui fonctionnaient parfaitement avec Cygwin 1.5 qui ne fonctionnent plus avec le 1.7 pour une histoire de signaux traités à la va comme je te pousse. Et je susi sûr pour avoir démonté les softs en question que le problème est dans cygwin et non dans mes codes.
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
C'est aussi un peu dommage que ca ne parle pas (ou alors j'ai rate)
de la possibilite d'utiliser read/write sur les socket TCP.
Ne serait-ce pas parce que Windows ne le permet pas et que le texte
reste autant que possible dans ce qui est commun? (C'est peut-etre vrai
aussi pour le reste d'ailleurs, mais ma connaissance de Windows est
extrement limitee).
Heureusement que Cygwin est là et il permet d'utiliser read/write.
Peut-être. Mais il ne faut pas titiller trop Cygwin. Selon les
versions, on peut avoir des résultats absolument bizarres (je pense à
kill() ou pthread_kill() qui peuvent se comporter de manière tout à
fait originale). En particulier, j'ai des programmes qui
fonctionnaient parfaitement avec Cygwin 1.5 qui ne fonctionnent plus
avec le 1.7 pour une histoire de signaux traités à la va comme je te
pousse. Et je susi sûr pour avoir démonté les softs en question que
le problème est dans cygwin et non dans mes codes.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
C'est aussi un peu dommage que ca ne parle pas (ou alors j'ai rate) de la possibilite d'utiliser read/write sur les socket TCP.
Ne serait-ce pas parce que Windows ne le permet pas et que le texte reste autant que possible dans ce qui est commun? (C'est peut-etre vrai aussi pour le reste d'ailleurs, mais ma connaissance de Windows est extrement limitee).
Heureusement que Cygwin est là et il permet d'utiliser read/write.
Peut-être. Mais il ne faut pas titiller trop Cygwin. Selon les versions, on peut avoir des résultats absolument bizarres (je pense à kill() ou pthread_kill() qui peuvent se comporter de manière tout à fait originale). En particulier, j'ai des programmes qui fonctionnaient parfaitement avec Cygwin 1.5 qui ne fonctionnent plus avec le 1.7 pour une histoire de signaux traités à la va comme je te pousse. Et je susi sûr pour avoir démonté les softs en question que le problème est dans cygwin et non dans mes codes.
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Antoine Leca
David Remacle écrivit :
exit(EXIT_FAILURE);
Quel est l'intérêt d'utiliser cela à la place d'un exit(0); ?
Reformulons un peu la question :-) : Quel est l'intérêt d'utiliser exit(EXIT_SUCCESS); au lieu de exit(0);
Réponse : pas grand chose, le résultat final sera le même, le résultat effectif sera le même dans la quasi-totalité des cas (il y a des systèmes pour lesquels exit(0) nécessite des contorsions particulières, et où exit(EXIT_SUCCESS) peut être très marginalement efficace), la raison la plus évidente, c'est d'avoir une interface de programmation plus limpide avec l'alternance (en anglais) EXIT_SUCCESS / EXIT_FAILURE
Pas sûr d'ailleurs que l'objectif soit complètement atteint ;-)
Est-ce mieux de l'utiliser alors en lieu et place de return(0) ?
Perso je trouve que dans main(){}, return 0 est plus clair et plus souvent utilisé. Jugement totalement personnel.
Maintenant, si ton style de programmation (ou les normes de style que l'on te demande de suivre) vont dans le sens d'utiliser 0 pour signifier faux ou perdu! (dans la ligne générale du langage C), utiliser exit(EXIT_SUCCESS) plutôt que return 0 / exit(0) peut être une bonne option pour la lisibilité générale.
Une seule chose : choisit une option et tiens-toi à elle ! Le pire dans ce domaine ce serait d'avoir la moitié du temps des return(0), et l'autre moitié des exit(EXIT_SUCCESS) : un programmeur qui viendra derrière va peut-être se poser des questions existentielles sur la signification de la différence orthographique...
Antoine
David Remacle écrivit :
exit(EXIT_FAILURE);
Quel est l'intérêt d'utiliser cela à la place d'un exit(0); ?
Reformulons un peu la question :-) : Quel est l'intérêt d'utiliser
exit(EXIT_SUCCESS);
au lieu de
exit(0);
Réponse : pas grand chose, le résultat final sera le même, le résultat
effectif sera le même dans la quasi-totalité des cas (il y a des
systèmes pour lesquels exit(0) nécessite des contorsions particulières,
et où exit(EXIT_SUCCESS) peut être très marginalement efficace), la
raison la plus évidente, c'est d'avoir une interface de programmation
plus limpide avec l'alternance (en anglais) EXIT_SUCCESS / EXIT_FAILURE
Pas sûr d'ailleurs que l'objectif soit complètement atteint ;-)
Est-ce mieux de l'utiliser alors en lieu et place de return(0) ?
Perso je trouve que dans main(){}, return 0 est plus clair et plus
souvent utilisé. Jugement totalement personnel.
Maintenant, si ton style de programmation (ou les normes de style que
l'on te demande de suivre) vont dans le sens d'utiliser 0 pour signifier
faux ou perdu! (dans la ligne générale du langage C), utiliser
exit(EXIT_SUCCESS) plutôt que return 0 / exit(0) peut être une bonne
option pour la lisibilité générale.
Une seule chose : choisit une option et tiens-toi à elle ! Le pire dans
ce domaine ce serait d'avoir la moitié du temps des return(0), et
l'autre moitié des exit(EXIT_SUCCESS) : un programmeur qui viendra
derrière va peut-être se poser des questions existentielles sur la
signification de la différence orthographique...
Quel est l'intérêt d'utiliser cela à la place d'un exit(0); ?
Reformulons un peu la question :-) : Quel est l'intérêt d'utiliser exit(EXIT_SUCCESS); au lieu de exit(0);
Réponse : pas grand chose, le résultat final sera le même, le résultat effectif sera le même dans la quasi-totalité des cas (il y a des systèmes pour lesquels exit(0) nécessite des contorsions particulières, et où exit(EXIT_SUCCESS) peut être très marginalement efficace), la raison la plus évidente, c'est d'avoir une interface de programmation plus limpide avec l'alternance (en anglais) EXIT_SUCCESS / EXIT_FAILURE
Pas sûr d'ailleurs que l'objectif soit complètement atteint ;-)
Est-ce mieux de l'utiliser alors en lieu et place de return(0) ?
Perso je trouve que dans main(){}, return 0 est plus clair et plus souvent utilisé. Jugement totalement personnel.
Maintenant, si ton style de programmation (ou les normes de style que l'on te demande de suivre) vont dans le sens d'utiliser 0 pour signifier faux ou perdu! (dans la ligne générale du langage C), utiliser exit(EXIT_SUCCESS) plutôt que return 0 / exit(0) peut être une bonne option pour la lisibilité générale.
Une seule chose : choisit une option et tiens-toi à elle ! Le pire dans ce domaine ce serait d'avoir la moitié du temps des return(0), et l'autre moitié des exit(EXIT_SUCCESS) : un programmeur qui viendra derrière va peut-être se poser des questions existentielles sur la signification de la différence orthographique...
