Discussion :

[xoco]

Bonjour a tous,

Je lis souvent que le standart en C est d'ecrire int main(), est ce le standart ANSI?
Je me pose la question, car dans le livre de reference "le langage C - 2eme edition", ecrit par Ritchie, l'auteur utilise main() sans type de retour.

Comment expliquer a mes eleves que le createur du langage qui utilise la norme ANSI l'ecrit mal, mais qu'il faut que main retourne un entier???

Merci d'avance ( C'est mon 2eme cours de C a l'universite

[Jean-Marc.Bourguet]

L'absence d'un type de retour fait que celui-ci est implicitement int. Le fait de ne pas le noter est sorti des usages au début des années 90, et si j'ai bonne mémoire C99 en interdit la pratique.

[Bktero]

Je regarde dans la norme C11 (mais c'est la même chose en C99) : http://www.open-std.org/jtc1/sc22/wg...docs/n1570.pdf

5.1.2.2.1 Program startup
1 The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:
int main(void) { /* ... */ }or with two parameters (referred to here as argc and argv, though any names may be
used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }or equivalent;10) or in some other implementation-defined manner.

La norme actuelle est de mettre un retour de type int.
Dur dur de trouver une norme C89 sur le net (quoique ceci ressemble à un draft valable : http://nepsweb.co.uk/langstand/isoC/gordon/ansi-c89u.txt), mais visiblement c'était déjà pareil.

Un retour void est communément accepté, c'est vrai ; je n'ai pas mon K&R sous la main mais c'est possible que ce soit void qui soit utilisé.

Je vois la réponse de JMB qui a posté en même temps que moi, effectivement l'explication du retour implicitement de type int est une bonne réponse ^^

EDIT : minGW émet un warning si le retour en de type void dans tous les cas (-ansi, -std=c99, -Wmain, -pedantic ou pas)

[gangsoleil]

Bonjour,

Comme explique, il y a deux prototypes acceptables pour main : int main (void) et int main (int argc, char ** argv).

Comment expliquer a mes eleves que le createur du langage qui utilise la norme ANSI l'ecrit mal, mais qu'il faut que main retourne un entier???

De quand date la seconde edition exactement ? Avant que le standard ne sorte en 1989 (enfin 1990) ? La preface parle de 1983 pour les debuts de la standardisation, mais sans plus de precision.

[Neckara]

5.1.2.2.1 Program startup
1 The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:
int main(void) { /* ... */ }or with two parameters (referred to here as argc and argv, though any names may be
used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }or equivalent;10) or in some other implementation-defined manner.

La norme ne dit-elle rien pour void main(void) ?
On l'utilisait quand on faisant de la programmation sur des MCS251 et il me semble que ce prototype de main est encore assez utilisé dans l'embarqué.

Ce doit d'ailleurs être pour cela que mingw n'envoie qu'un warning et accepte tout de même de compiler?

[Bktero]

Qui a dit que ton compilateur pour MCS251 était ISO C ? ^^

Je prends l'exemple de C18, compilateur pour PIC18 : la documentation donne la liste des différences avec la norme C. Le retour de main( ) peut en être un. Il s'explique assez bien en embarqué car la valeur de retour de main( ) n'a pas d'utilité puisque personne ne la récupère (dans le cas où pas d'OS). Si un OS est présent, alors le code retour d'un programme peut intéresser d'autres programmes et là, le retour du main( ) est important.

Dans l'extrait que j'ai cité, on peut lire :

; or in some other implementation-defined manner.

Je ne sais pas si ça veut donc dire "ou une 3e solution dépendante de l'architecture". Le point-virgule précédant cette proposition que me fait dire que 3e solution est possible.

Un peu plus loin dans n1256, on lit :

5.1.2.2.3 Program termination
1 If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument;10) reaching the } that terminates the main function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.

Ce qui sous-entend qu'on pourrait avoir autre chose que int en retour de main(). Non ?

[ternel]

Puisque la valeur renvoyé à l'hote est "unspecified", je ne vois pas l'intérêt de retourner quelque chose... Sauf à avoir un compilateur et un environnement qui coopèrent pour...

[matafan]

Puisque la valeur renvoyé à l'hote est "unspecified", je ne vois pas l'intérêt de retourner quelque chose... Sauf à avoir un compilateur et un environnement qui coopèrent pour...

Elle n'est pas spécifiée par la norme du C. Ce qui ne veut pas dire qu'elle n'est pas spécifiée par la plateforme.

POSIX spécifie que 0 veut dire succès et qu'une autre valeur veut dire échec.

[gangsoleil]

Ce qui sous-entend qu'on pourrait avoir autre chose que int en retour de main(). Non ?

Un comportement "unspecified", ca veut dire que tu peux avoir des comportements differents selon l'environnement (lib C, compilateur, ...). Un comportement indefini n'est pas forcement le mal en soit, mais c'est un code qui ne doit pas etre utilise ailleurs qu'a l'endroit prevu. En gros, tu ruines toute possibilite de portage ulterieure, et a moins de devoir le faire, il faut eviter a tout prix : rien ne te dit que la prochaine mise a jour de ton environnement ne va pas changer le comportement.

Comme dit precedemment, la norme precise 2 prototypes pour main, les deux retournant int. Tu peux ecrire void main (float a), mais tu n'es pas certain du resultat. Tu peux aussi te tirer dans le pied avec une mitraillette en esperant rater le pied.

[Bktero]

Tu peux aussi te tirer dans le pied avec une mitraillette en esperant rater le pied.

T'inquiètes, je sais très bien ce qui ce cache derrière les "unspecified" et autres "is implementation defined" dans la norme C Je cherche juste à savoir si la norme prévoie un retour autre que int qui expliquerait que le compilateur émette un warning et non une erreur. Dans ce paragraphe 5.1.2.2.3 Program termination, je ne sais pas si le type correspond au type dans le prototype (ex : char* int(void){/*...*/} ) ou à l'"argument" du return (ex : return 0.42;).

Dans un message précédent, je disais :

Dans l'extrait que j'ai cité, on peut lire :
Citation:
; or in some other implementation-defined manner.
Je ne sais pas si ça veut donc dire "ou une 3e solution dépendante de l'architecture". Le point-virgule précédant cette proposition que me fait dire que 3e solution est possible.

Qu'en penses-tu ? A quoi ce réfère cette "autre manière" ?

[Jean-Marc.Bourguet]

La norme ne dit-elle rien pour void main(void) ?
On l'utilisait quand on faisant de la programmation sur des MCS251 et il me semble que ce prototype de main est encore assez utilisé dans l'embarqué

Les contraintes sur main sont dans la partie "hosted", dans l'embarqué je parie qu'on est dans le "free standing" qui n'a pas toute une série de contraintes.

Bonjour,

Comme explique, il y a deux prototypes acceptables pour main : int main (void) et int main (int argc, char ** argv).

De quand date la seconde edition exactement ? Avant que le standard ne sorte en 1989 (enfin 1990) ? La preface parle de 1983 pour les debuts de la standardisation, mais sans plus de precision.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int main()

est aussi valable. Du point de vue définition -- et c'est sur ça que porte la contrainte --, c'est la même chose que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int main(void)

(La deuxième édition date de 88, la norme était déjà quasiment figée à ce moment là).

[xoco]

Merci pour toutes vos reponses,

Ma question portait surtout sur le bouquin de reference de Ritchie, quelle justification puis je donner au fait que son code soit disant ANSI C commencent par :
main(){
}

au lieu de int main() (int main(void)) comme tout le monde dit que ca doit etre?

Sachant que je recommende un bouquin a mes eleves qui ecrit differemment de ce que je leur dis d'ecrire

[Jean-Marc.Bourguet]

C'est un bouquin de 78 mis à jour en 88. L'interdiction de main() date de 99. À l'époque de l'écriture, le choix était stylistique et le style dominant (surtout en 78), c'était sans int.

[Marc Mongenet]

Ma question portait surtout sur le bouquin de reference de Ritchie, quelle justification puis je donner au fait que son code soit disant ANSI C commencent par :
main(){
}

Il s'agit du bouquin des inventeurs du langage, qui l'ont implémenté, documenté, utilisé, plus de 15 ans avant que la norme ANSI n'existe. Sur certains points de vue, ils sont donc au-dessus de la norme (contrairement aux simples mortels que nous sommes).

A part ça, je crois qu'ils ont repris tel quel l'exemple de la première édition de leur livre. Pour les habitués de C, cela montrait quelque-chose de très important concernant la norme ANSI alors toute fraiche: elle ne rendait pas les anciens programmes incompatibles.

En outre, il y a une raison pédagogique qui me semble assez clair au vu de leur exemple complet

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#include <stdio.h>
 
main()
{
    printf("hello, world\n");
}

Avec cette version, les notions de type, de mot clé, et de retour de fonction n'apparaissent pas. Ca permet de réduire la taille des explications à donner. Il y en a déjà bien assez avec l'include, le main, les parenthèses, les accolades, le printf, la chaine de caractères, le point-virgule...

Enfin, le fait de ne pas écrire le int est tout à fait supporté par C89 (voir C89 §3.5.2).

Il faut aussi savoir que le type void n'a pas toujours existé en C. Donc je suppose que de ne rien retourner d'une fonction qui renvoie implicitement un int était une manière de faire respectable.