Path: utzoo!utgpu!watmath!att!occrsh!uokmax!apple!gem.mps.ohio-state.edu!samsung!cs.utexas.edu!uunet!munnari.oz.au!csc!bdm659
From: bdm659@csc.anu.oz
Newsgroups: comp.lang.c
Subject: Re: void main()  (second proof of non-portability)
Message-ID: <1018.25642ba8@csc.anu.oz>
Date: 17 Nov 89 16:02:48 GMT
References: <2387@stl.stc.co.uk> <744@lakart.UUCP> <0175@sheol.UUCP> <11592@smoke.BRL.MIL> <7733@cdis-1.uucp> <1015.2563d6e0@csc.anu.oz>
Organization: Computer Services, Australian National University
Lines: 30


 In article <7733@cdis-1.uucp>, tanner@cdis-1.uucp (Dr. T. Andrews) writes:
> [[The question is: why is it wrong to declare main() as void, instead of
> int, even though he program is terminated by calling exit() explicitely?]]
>
> I should like to hear details of a case where the code will not
> work.  It seems ridiculous to declare un-portable the results of a
> void-vs-int return linkage which is never made, and I should like
> to hear of an implementation where this actually fails.
>
> If no real-world example is available, I should be almost as
> satisfied with a conjectural example (clearly marked as conjecture).

I've thought of an even simpler hypothetical implementation for which
declaring main() as void fails to work.  This one may even exist (anyone?).

Suppose the implementation of calling a function goes like this:
* push the arguments onto the stack
* move the stack pointer some more to make some room for the function to
  return its value in
* branch to the function
The called function gets its arguments by indexing off the stack pointer.

Now, if the calling function has the wrong idea about what the type of the
function being called is, the called function will not find its arguments
correctly.  Thus, if you declare main() as void, you can't expect to be
able to use argv and argc.  It makes no difference whether you are leaving
main() by doing return() or exit().

Brendan McKay.  bdm@anucsd.oz.au  or  bdm659@csc1.anu.oz.au