[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IDL issue - struct return vs. cap return

From: Jonathan S. Shapiro
Subject: Re: IDL issue - struct return vs. cap return
Date: Mon, 09 Jul 2007 20:40:50 -0400

On Mon, 2007-07-09 at 23:24 +0200, Neal H. Walfield wrote:

> Are you sure?  This change changes the semantics of the return.  gcc,
> for instance, does not do this.  Consider:
>   #include <string.h>
>   #include <stdio.h>
>   struct foo
>   {
>     char *p;
>     char s[100000];
>   };
>   struct foo bar (void)
>   {
>     struct foo foo;
>     foo.p = foo.s;
>     return foo;
>   }
>   int
>   main ()
>   {
>     struct foo foo;
>     foo.p = foo.s;
>     printf ("before: %x\n", foo.p);
>     foo = bar ();
>     printf ("after: %x\n", foo.p);
>   }
>   $ ./foo
>   before: 7339c5c8
>   after: 7336b848

Your example does not yield any change in semantics if the compiler
implements the call correctly. The requirement is that there must be a
copyout. Ordinarily the inner structure foo can be unified with the
passed foo reference, but in your example the inner structure foo is
aliased and this optimization is precluded.

In any case, as long as a copyout occurs, it doesn't matter whether it
occurs via the return parameter or via an extra hidden parameter. In
either case the compiler logically makes and destroys a temporary. The
difference is that when the return value is passed as a pointer
parameter it is sometimes possible to eliminate the temporary and the

> I don't completely buy the legacy argument.  When the struct is
> returned, the pointer needs to be updated, however, the compiler
> doesn't know that memcpy isn't enough.

Memcpy damned well better be enough, since that is all that the normal
struct return does.

Legacy struct return always operated by allocating temporary space on
the stack, passing a pointer to that (either implicitly by offset from
SP or explicitly) and then using a memcpy-based copyout. The copyout can
be avoided exactly if the FROM copy is non-aliased. It doesn't matter
whether the temporary exists on the stack or not, because that *can't*
be aliased by either side.

Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC

reply via email to

[Prev in Thread] Current Thread [Next in Thread]