Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: return vs exit()
Message-ID: <6929@brl-smoke.ARPA>
Date: 6 Jan 88 01:45:36 GMT
References: <10875@brl-adm.ARPA> <176@fxgrp.UUCP> <1286@laidbak.UUCP> <1293@laidbak.UUCP> <10033@shemp.UCLA.EDU> <454@viper.Lynx.MN.Org>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 64

In article <454@viper.Lynx.MN.Org> john@viper.UUCP (John Stanley) writes:
>  This is a long standing illusion.  For practical reasons, many
>implementors of the C language have had to make a concession to how
>people have been told (by K&R no less) to write a main() function.

Excuse me, but I don't believe K&R discusses whether or not main()
is even considered to return a value, much less what should happen
to it.  (Remember that K&R C did not distinguish between int-valued
functions and void-valued functions; "void" was not even in the
language.)

>There are two ways for a call to main() to be written:
>    1)  /* used in most of the crt0.c code that I've seen */
>	main(argc, argv);
>	exit(0);

Not ANSI-conforming.

>    2)  /* what Alex would expect */
>	exit(main(argv, argc));

This is what the UNIX crt0 (run-time startup module that calls main())
has done since I can remember, certainly for very many years.
(Well, actually not too long ago it started passing also an envp argument
to main, but that's not relevant to the discussion.)

>I'm sure you'll all agree that a random return value isn't desireable?

Yes, and we've just about stamped out the vestigial remnants of that in
the UNIX system utilities.  For many years, several utilities did in fact
return garbage status to the execution environment (wait() status) because
they were written in old K&R style rather than reporting proper status.

>situation, poor style isn't really relevant...they exist and part 
>of the objective for the ANS standard is to not break existing code...  

Sorry, but using the main() return value as an implicit exit() parameter
is also widespread existing practice, and many of us have relied on it
for many years.

Code that fails to indicate its termination status is simply broken in
that regard, and for an implementation to take it upon itself to report
such code as "always successful" is presumptuous.

>(Examples of this style are in K&R and must be considered part of the
>baseline definition of how many people have been writing main() 
>functions for years.)

You could also say that about the UNIX C implementation(s), which even
predate K&R.

>If the ANS standard does not deal with this problem, it
>should do so before being released.  This dicotomy has existed for
>years and is exactly the kind of thing the committee needs to solve
>once and for all...

Yes, it's been taken care of -- adopting the UNIX approach rather than
the "invent a status for the sloppy SOB" approach.

>  Regardless of which way the ANS standard is written, if you use exit
>to return a value out of your program, it will work.

This is good advice for those who have to deal with portability to a
wide variety of pre-ANSI C, non-UNIX environments, poor souls.