Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!think!ames!uhccux!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: <1022.2565a892@csc.anu.oz>
Date: 18 Nov 89 19:08:02 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> <314@charyb.COM>
Organization: Computer Services, Australian National University
Lines: 29

In article <314@charyb.COM>, will@charyb.COM (Will Crowder) writes:
> 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?

Since functions can return values which are quite large (eg. structures),
some mechanism other than registers must be used sometimes.  The compiler
can use whatever mechanism it pleases so long as it is consistent.  The
method might even depend on the type instead of the size, so you can't even
suppose that a function can be safely declared int in one place and
struct {int i;} in another.

Brendan.