Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!charyb!will
From: will@charyb.COM (Will Crowder)
Newsgroups: comp.lang.c
Subject: Re: void main()  (second proof of non-portability)
Message-ID: <314@charyb.COM>
Date: 17 Nov 89 18:54:45 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> <1018.25642ba8@csc.anu.oz>
Reply-To: will@charyb.UUCP (Will Crowder)
Organization: KFW Corporation, Newbury Park, CA
Lines: 21

In article <1018.25642ba8@csc.anu.oz> bdm659@csc.anu.oz writes:

[lots of stuff about void main() unportability having to do with passing
 return values on the stack]

I've used a 6 or so C compilers in 3 very different environments,
(680x0, 80x86, SPARC), and all of them pass return values in registers.

The question I have is this: for every C compiler I've used, it doesn't
matter how many arguments you call a function with.  The return linkage
will still work, because it's the *caller's* job to fix up the stack
after the function returns.  Are there any implementations in which this
is not true?  Can someone point me to a C compiler which does use a vastly
different calling convention?  I'm just curious.  Passing return values
on the stack doesn't seem like a very good performance move, and most
machines have at least one register to pass something in...If the caller
needs the contents of that register saved, it can save it itself before
calling the function...again, stack frame integrity is the caller's
responsibility in C (or at least any sane implementation), no?

Will