Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: void main()  (second proof of non-portability)
Message-ID: <11642@smoke.BRL.MIL>
Date: 19 Nov 89 00:46:32 GMT
Article-I.D.: smoke.11642
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>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 44

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

It's not true for C in general, although many implementations are designed
to work that way.  Before the ,... mechanism of X3.159, the fact that it
was highly desirable for printf() to be implementable as an ordinary C
function imposed considerable constraints on the feasibility of various
designs for function linkage implementation.  With the advent of the ,...
notion (distinct interface for variadic functions), more possibilities
now are feasible.

>Can someone point me to a C compiler which does use a vastly
>different calling convention?

Sure.  Try ORCA/C (published by ByteWorks for the Apple IIGS).
There are also many C implementations where the run-time library assists
in restoring context, and often special hardware features can be
exploited to help with this.  In those cases, neither the caller nor
the callee can be said to be responsible for these things.

>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?

First of all, please note that you have a particular notion of the
kind of computer architecture involved.  There are stack-based
architectures and "register working set window" architectures
where the notion of reserving a "general-purpose register" to hold
the return value across a function linkage is inappropriate.  Even
on conventional general-register oriented architectures, if the
returned object is large it won't fit in a register.

"Stack frame integrity" is the responsibility of BOTH the implementor
correctly implementing the C language specification AND the programmer
not stepping beyond the bounds of what the C language specification
promises.  That is why we sometimes say that the C standard defines
a "treaty point" between implementor and programmer.