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