Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Valeur renvoyee par main

13 réponses
Avatar
Greydavayar
Bonsoir,

j'ai appris le C avec la notion suivante : la fonction main doit
TOUJOURS retourner 0 sinon, c'est qu'une erreur s'est produite.

Or, je n'ai vu aucun passage dans la norme qui impose que la valeur
retournee soit 0.

Et recemment, j'ai discute avec un eleve d'EPITECH qui lui retournait
systematiquement 1..


Nous avons tous les deux appris avec des methodes differentes, chacune
d'entre elles affirme qu'il FAUT retourner une valeur en particulier
et impose cette valeur.. Pourquoi?

Je suppose que la gestion d'erreurs n'est pas la meme selon les OS et
que ca joue donc sur la valeur de retour, mais existe t'il une loi
"universelle", existe t'il une "bonne pratique", pourquoi les cours
imposent-ils une valeur en particulier??

Merci d'avance

10 réponses

1 2
Avatar
Antoine Leca
Greydavayar écrivit :
j'ai appris le C avec la notion suivante : la fonction main doit
TOUJOURS retourner 0 sinon, c'est qu'une erreur s'est produite.

Or, je n'ai vu aucun passage dans la norme qui impose que la valeur
retournee soit 0.



Ce n'est pas imposé, c'est une convention, comme d'habitude tu peux en
choisir une autre.

Cela étant, c'est clairement dit dans la norme, quoique ce ne soit pas
direct :
- cela ne s'applique que pour les applications « hébergées »
- la valeur retournée par main est passé à exit
- exit(0) dénote le succès, à charge à l'environnement (le compilateur)
de magouiller si nécessaire pour l'information transmise soit «succès»!


Et recemment, j'ai discute avec un eleve d'EPITECH qui lui retournait
systematiquement 1..



Une autre convention, dont j'ajouterai qu'elle est moins répandue.


Nous avons tous les deux appris avec des methodes differentes, chacune
d'entre elles affirme qu'il FAUT retourner une valeur en particulier
et impose cette valeur.. Pourquoi?



Pourquoi quoi ? Pourquoi tous les deux, pourquoi appris, pourquoi
différentes (la réponse est ci-dessus), pourquoi il faut, pourquoi 0 (la
raison c'est le shell de Unix qui considère que 0 = OK), pourquoi 1
(bonne question)


Antoine
Avatar
espie
In article ,
Greydavayar wrote:
Bonsoir,

j'ai appris le C avec la notion suivante : la fonction main doit
TOUJOURS retourner 0 sinon, c'est qu'une erreur s'est produite.

Or, je n'ai vu aucun passage dans la norme qui impose que la valeur
retournee soit 0.

Et recemment, j'ai discute avec un eleve d'EPITECH qui lui retournait
systematiquement 1..



Cet eleve a tort. Il a du reussir a passer a travers les quelques cours qu'ils
ont... en particulier, ils apprennent quand meme entre autres a coder sur Unix,
et il *faut* retourner 0 pour que ca ait un sens pour le shell. 1 signifie
que le programme s'est termine en erreur.


Il a du se melanger les pinceaux entre les booleens et les codes de retour.

Nous avons tous les deux appris avec des methodes differentes, chacune
d'entre elles affirme qu'il FAUT retourner une valeur en particulier
et impose cette valeur.. Pourquoi?



Non, non. La valeur "tout va bien" universelle est bien 0 (des que tu es
dans un hosted environment. En freestanding, de toutes facons, main n'a pas
forcement un sens, et c'est la documentation de ton environnement qui explique
ce qu'il faut faire, la norme te dit juste que ce genre de truc devra etre
documente).

confere 5.1.2.2.3, et 7.20.4.3. Il y est ecrit de facon explicite que le return
en fin de main est equivalent a l'appel de exit, qu'en C99, un main sans return
renvoie 0, et que exit(0) est une des facons (pas forcement la seule) de
faire "succesful termination".

(l'autre facon etant d'include stdlib.h et d'utiliser EXIT_SUCCESS, qui peut
valoir 0 ou une autre valeur equivalente pour l'OS).

Par contre, la seule facon totalement portable de dire "mon programme a echoue",
c'est de renvoyer EXIT_FAILURE.

Le detail des codes de retour est dependant de l'implementation. Tu devras
te referer a une autre norme (par exemple POSIX) pour pouvoir etre plus
precis (et posix te dit que tu as 256 valeurs distinctes, entre 0 et 255, et
qu'apres il se passe... autre chose. En particulier, faire un truc tel que:

...
if (probleme)
erreur++;
...
exit(erreur);

est un bug: ton programme va faire semblant de marcher toutes les 256 erreurs)
Avatar
Greydavayar
On 8 sep, 17:14, Antoine Leca wrote:
Greydavayar écrivit :

> j'ai appris le C avec la notion suivante : la fonction main doit
> TOUJOURS retourner 0 sinon, c'est qu'une erreur s'est produite.

> Or, je n'ai vu aucun passage dans la norme qui impose que la valeur
> retournee soit 0.

Ce n'est pas imposé, c'est une convention, comme d'habitude tu peux en
choisir une autre.

Cela étant, c'est clairement dit dans la norme, quoique ce ne soit pas
direct :
 - cela ne s'applique que pour les applications « hébergées »
 - la valeur retournée par main est passé à exit
 - exit(0) dénote le succès, à charge à l'environnement (le com pilateur)
 de magouiller si nécessaire pour l'information transmise soit «suc cès»!

> Et recemment, j'ai discute avec un eleve d'EPITECH qui lui retournait
> systematiquement 1..

Une autre convention, dont j'ajouterai qu'elle est moins répandue.

> Nous avons tous les deux appris avec des methodes differentes, chacune
> d'entre elles affirme qu'il FAUT retourner une valeur en particulier
> et impose cette valeur.. Pourquoi?

Pourquoi quoi ? Pourquoi tous les deux, pourquoi appris, pourquoi
différentes (la réponse est ci-dessus), pourquoi il faut, pourquoi 0 (la
raison c'est le shell de Unix qui considère que 0 = OK), pourquoi 1
(bonne question)

Antoine



Je te remercie j'y vois plus clair, qu'entends tu par "applications «
hébergées »"?
Avatar
espie
In article ,
Greydavayar wrote:
Je te remercie j'y vois plus clair, qu'entends tu par "applications «
hébergées »"?



Ce que j'appelle "hosted" dans ma reponse (je ne connais pas de traduction
satisfaisante), par opposition a freestanding (embarque, la c'est plus simple).
La norme du C couvre a peu pres tout (sauf VMS C, apparemment), y compris ta
montre. En general, sur une montre, des concepts tels que le demarrage du
programme, ou stdin/stdout, ou malloc, n'ont que peu de sens. La norme se
decoupe ainsi en "le langage a proprement parler" et "l'environnement classique
d'execution". Si ton environnement est "heberge"/hosted, ca veut dire que tu
tournes sur quelque chose qui ressemble assez a un ordinateur classique pour
avoir entrees/sorties, demarrage de programme, allocation memoire... et tout
ceci est alors defini. Sinon, ben tu es dans le domaine de l'embarque, et la
norme te dit juste que la documentation de ton environnement DOIT expliquer
comment tous ces aspects marchent.

(note au passage: un systeme conforme a la norme correspond generalement a
une machine, un compilateur, et un jeu d'options. Par exemple, tu peux
tres bien avoir un compilo sous Windows qui se proclame ANSI, a partir du
moment ou la documentation te dit quelles options utiliser pour etre en C
ANSI, en particulier recuperer un main() de type "ligne de commande" et des
entrees-sortie stdin/stdout qui fonctionnent)
Avatar
Greydavayar
On 8 sep, 17:35, (Marc Espie) wrote:
In article com>,

Greydavayar   wrote:
>Je te remercie j'y vois plus clair, qu'entends tu par "applications «
>hébergées »"?

Ce que j'appelle "hosted" dans ma reponse (je ne connais pas de traductio n
satisfaisante), par opposition a freestanding (embarque, la c'est plus si mple).
La norme du C couvre a peu pres tout (sauf VMS C, apparemment), y compris ta
montre. En general, sur une montre, des concepts tels que le demarrage du
programme, ou stdin/stdout, ou malloc, n'ont que peu de sens. La norme se
decoupe ainsi en "le langage a proprement parler" et "l'environnement cla ssique
d'execution". Si ton environnement est "heberge"/hosted, ca veut dire que tu
tournes sur quelque chose qui ressemble assez a un ordinateur classique p our
avoir entrees/sorties, demarrage de programme, allocation memoire... et t out
ceci est alors defini. Sinon, ben tu es dans le domaine de l'embarque, et la
norme te dit juste que la documentation de ton environnement DOIT expliqu er
comment tous ces aspects marchent.

(note au passage: un systeme conforme a la norme correspond generalement a
une machine, un compilateur, et un jeu d'options. Par exemple, tu peux
tres bien avoir un compilo sous Windows qui se proclame ANSI, a partir du
moment ou la documentation te dit quelles options utiliser pour etre en C
ANSI, en particulier recuperer un main() de type "ligne de commande" et d es
entrees-sortie stdin/stdout qui fonctionnent)



D'accord merci c'est limpide a present
Avatar
Erwan David
(Marc Espie) écrivait :

In article ,
Greydavayar wrote:
Bonsoir,

j'ai appris le C avec la notion suivante : la fonction main doit
TOUJOURS retourner 0 sinon, c'est qu'une erreur s'est produite.

Or, je n'ai vu aucun passage dans la norme qui impose que la valeur
retournee soit 0.

Et recemment, j'ai discute avec un eleve d'EPITECH qui lui retournait
systematiquement 1..



Cet eleve a tort. Il a du reussir a passer a travers les quelques cours qu'ils
ont... en particulier, ils apprennent quand meme entre autres a coder sur Unix,
et il *faut* retourner 0 pour que ca ait un sens pour le shell. 1 signifie
que le programme s'est termine en erreur.




C'est pas plutôt EXIT_SUCCESS et EXIT_FAILURE, à charge pour la
plateforme d'en faire quelque chose d'interrétable par le lanceur ?

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Avatar
-ed-
On 8 sep, 17:48, Greydavayar wrote:
Bonsoir,

j'ai appris le C avec la notion suivante : la fonction main doit
TOUJOURS retourner 0 sinon, c'est qu'une erreur s'est produite.



0 ou EXIT_SUCCESS

Or, je n'ai vu aucun passage dans la norme qui impose que la valeur
retournee soit 0.

Et recemment, j'ai discute avec un eleve d'EPITECH qui lui retournait
systematiquement 1..



Ca, c'est une ânerie. 1 signifie erreur sur la plupart des systèmes.


Nous avons tous les deux appris avec des methodes differentes, chacune
d'entre elles affirme qu'il FAUT retourner une valeur en particulier
et impose cette valeur.. Pourquoi?



Parce que le système attend une valeur précise. Les valeurs portables
(tous systèmes) sont

EXIT_SUCCESS /* OK */
EXIT_FAILURE /* KO */

définies dans <stdlib.h>. La valeur réelle dépend du système.

Avec ces constantes, on est certain de retourner les bonnes valeurs au
système.
Avatar
JKB
Le Thu, 9 Sep 2010 00:25:18 -0700 (PDT),
-ed- écrivait :
On 8 sep, 17:48, Greydavayar wrote:
Bonsoir,

j'ai appris le C avec la notion suivante : la fonction main doit
TOUJOURS retourner 0 sinon, c'est qu'une erreur s'est produite.



0 ou EXIT_SUCCESS



0, c'est parfois casse-gueule, comme une valeur non nulle en cas
d'erreur est aussi casse-gueule. Je viens de me faire avoir par un
script autoconf.

Or, je n'ai vu aucun passage dans la norme qui impose que la valeur
retournee soit 0.

Et recemment, j'ai discute avec un eleve d'EPITECH qui lui retournait
systematiquement 1..



Ca, c'est une ânerie. 1 signifie erreur sur la plupart des systèmes.



D'un autre côté, c'est EPITECH, hein... J'ai eu plusieurs stagiaires
de ce truc-là et je n'en dirais pas plus. C'est tout de même bizarre
que ça ne vous étonne pas plus...

Nous avons tous les deux appris avec des methodes differentes, chacune
d'entre elles affirme qu'il FAUT retourner une valeur en particulier
et impose cette valeur.. Pourquoi?



Parce que le système attend une valeur précise. Les valeurs portables
(tous systèmes) sont

EXIT_SUCCESS /* OK */
EXIT_FAILURE /* KO */

définies dans <stdlib.h>. La valeur réelle dépend du système.

Avec ces constantes, on est certain de retourner les bonnes valeurs au
système.



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
Avatar
Antoine Leca
JKB écrivit :
Le Thu, 9 Sep 2010 00:25:18 -0700 (PDT),
-ed- écrivait :
On 8 sep, 17:48, Greydavayar wrote:
Bonsoir,

j'ai appris le C avec la notion suivante : la fonction main doit
TOUJOURS retourner 0 sinon, c'est qu'une erreur s'est produite.



0 ou EXIT_SUCCESS



0, c'est parfois casse-gueule, comme une valeur non nulle en cas
d'erreur est aussi casse-gueule.



Une implémentation qui n'a pas le même comportement pour 0 et pour
EXIT_SUCCESS n'est pas conforme à la norme C, et n'a pas le comportement
qu'en attendent la plus grande partie des programmeurs.

De plus, si on regarde les trucs non conformes en général, je pense
qu'il y a largement plus de cas où 0 est accepté mais où EXIT_SUCCESS
n'est pas défini (ce qui incite à prendre 0 comme indicateur de
«succès») que de cas d'implémentations volontairement non conformes, où
EXIT_SUCCESS et EXIT_FAILURE sont définis _et_ où ce dernier vaille 0,
ou bien où 0 signifie quelque chose de différent mais qui ressemble plus
à un échec qu'à un succès.

Je suis bien conscient qu'il y eut (a ?) des implémentations où 0
signifient échec et 1 signifie succès, mais je ne pense pas qu'en plus,
elles ont l'outrecuidance (par rapport à la norme) de rajouter
#define EXIT_FAILURE 0
#define EXIT_SUCCESS 1


Je viens de me faire avoir par un script autoconf.



Huh ?
Sur une implémentation Posix, EXIT_SUCCESS est forcément égal à 0.
Et essayer autoconf ailleurs, c'est vraiment avoir une passion pour les
problèmes.


Antoine
Avatar
JKB
Le Thu, 09 Sep 2010 17:18:36 +0200,
Antoine Leca écrivait :
JKB écrivit :

Huh ?
Sur une implémentation Posix, EXIT_SUCCESS est forcément égal à 0.
Et essayer autoconf ailleurs, c'est vraiment avoir une passion pour les
problèmes.



J'ai une déformation de vieux con fortraneux et donc une tendance
nette à utiliser -1 comme valeur vraie. J'ai machinalement collé -1
comme valeur de retour d'un programme utilisé par autoconf et je me
fais copieusement insulter par le script lorsqu'il tourne sous eCS.
Pas testé sous autre chose.

Donc chez moi, ça commence toujours par quelque chose du genre :
# ifndef EXIT_SUCCESS
# define EXIT_SUCCESS 0
# endif
et la même chose pour EXIT_FAILURE histoire d'éviter des concetés où
le shell attend explicitement 1.

Tu vas encore me dire que les specs disent explicitement que
EXIT_FAILURE doit valoir 1. Dans ma jeunesse, la règle était 0 'fin
conforme' et valeur non nulle 'fin anormale' et j'en suis toujours
resté là.

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
1 2