Structure/Union Return Values
JOSH%YKTVMH.BITNET at wiscvm.ARPA
JOSH%YKTVMH.BITNET at wiscvm.ARPA
Fri Feb 7 13:46:37 AEST 1986
> Radical Proposal Time: So like, why not? If we're going to do
> horrible things like pass/return struxures to/from funxions,
> (get this, the Sequent compiler axually passes an extra pointer
> *before* the declared args & does the copy itself!)...
> ...
>
> jim cottrell at nbs
This or something like it seems to be one of the recommended methods for
doing such things. I quote from "The C Language Calling Sequence" by
S.C. Johnson and D.M. Ritchie, Bell Labs, Murray Hill, NJ, September 24,
1981 (there may be a published reference, but I don't have it, sorry),
the section entitled "Functions Returning Structures" (emphasis in the
original):
Functions may return structures and unions. Although objects
of other types usually fit nicely in a designated return register,
these do not; where should the returned value be placed? If the
value is left in the stack space of the *called* procedure, it
becomes unprotected after the return and before it is copied; a
signal, interrupt, or swap at the wrong time would be a disaster.
If the value is left in a static area, it is more protected, but
the procedure is no longer reentrant.
The proper solution is to allocate space for the return value
in the *calling* procedure's stack, and communicate the address of
this space to the *called* procedure; before returning, the value
is copied into this space. The *called* procedure might be able to
find this space by looking at an additional argument or a scratch
register passed by the *calling* procedure or (when the stack is
contiguous) by mutual agreement about the area where the result
should go.
The authors go on to mention that the PDP-11 compiler chose the static
cell approach, sacrificing reentrancy. Which reminds me of a friend
who changed a switch statement in an old "Version 6 Mini-Unix" kernel.
He removed some "unused" arms of the switch statement and found that
the kernel got sick occasionally. Looking at the generated code
revealed that the compiler was generating code that wasn't reentrant/
interruptible for the "improved" version of the switch statement.
I wouldn't want to accuse anyone of such things, but I seem to remember
that there were no comments about this in the code.
Of course, any opinions, expressed or implied are mine and not my
employers...
Josh Knight
IBM T.J. Watson Research Center
josh at yktvmh.BITNET, josh.yktvmh at ibm-sj.arpa
More information about the Comp.lang.c
mailing list