main() linkage

[Doug Gwyn]

In article <7755 at cdis-1.uucp> tanner at cdis-1.uucp (Dr. T. Andrews) writes:
>In article <11665 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>) Your citing of "established practice" is merely citing of existing
>) ERRONEOUS programming practice,
>It is interesting to hear that the practice of declaring as "void"
>a function which does not return a value is erroneous.

It might be, if you'd quit trying to be sarcastic and listen to
the explanations.

Function interfaces have TWO sides:  caller and callee.  BOTH sides
need to agree on the way to link to one another.  In the case of
main(), the caller is automatically supplied as part of the run-time
environment, and the caller expects main() to have the "shape" of a
function that takes two arguments of type int and char** respectively
and that returns an integer value, which the caller expects to pass
back to the invocation environment as a form of success/failure
indication.

If the caller were written in C, it might look like this:

	/* ... set up arguments for main() here ... */
	exit( main( argc, argv ) );

>) Again, I explained the EXISTING, OPERATIONAL issues that make such
>) practice erroneous,
>No, you merely stated that you disapproved of the practice.  This
>differs from saying what the problems might be, and why this practice
>didn't receive blessing from X3J11.

I most certainly did explain the problem, as did numerous others.
Perhaps you missed the posting(s).

>I note that "main" has been granted special treatment in its
>arguments: you may have "main(void)" as an alternative to the
>usual arguments.  The lack of treatment for the case where
>the program exits via exit() is therefore especially deserving
>of attention.

X3.159 fully supports exit(status) as well as return status; from
within the body of main().  They are (almost) fully equivalent.

I disagreed with the decision to require int main(void) to work.
However, it is required.  On the other hand, void main(/*anything*/)
was not required to work, and like int main(void) in pre-X3.159 C
whether or not it HAPPENS to work depends on specific details of
each implementation.  This has always been true for C, despite
false expectations of some people to the contrary.

>) Too bad you didn't pay attention to the explanations and instead
>) merely kept making silly noises.
>It is, rather, too bad that you did not see fit to post anything
>other than puffery and smoke on the issue.  I had foolishly expected
>better of you.
>Yes, other people have posted hypothetical but not unreasonable
>examples where it would be more difficult to handle such cases.
>In no case is it impossible to handle a void "main" which doesn't
>return.

The compiler could support any number of extensions.  Why should
it support this particular misusage?  Just because int main(void)
was made a special supported kludge does not mean that an additional
misdeclaration should be supported.  Rather the contrary -- if your
local compiler silently accepts such abuse of the type system, you'll
come to think of it as guaranteed to work portably and eventually
somebody will end up paying the price for your mistake.

I've had to maintain far too much code where just this kind of
function linkage declaration/definition abuse had occurred, and
it was a royal pain to fix when the code was ported to an environment
that didn't look much like a VAX architecture.