Re: IDL issue - struct return vs. cap return

[Neal H. Walfield]

At Mon, 09 Jul 2007 20:40:50 -0400,
Jonathan S. Shapiro wrote:
> 
> On Mon, 2007-07-09 at 23:24 +0200, Neal H. Walfield wrote:
> > 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.

The desired behavior is that the pointer continue to point to data
within the block of memory.  Because the address stored in the
structure is absolute and not relative to the start of the struct,
memcpy is not enough.

You said:

At Mon, 09 Jul 2007 15:14:25 -0400, Jonathan S. Shapiro wrote:
> The convention you describe is actually unnecessary, because good
> compilers already implement it automatically. 

But, as we have both argued, compilers do not implement this
convention automatically: there is a semantic gap.  This is the same
problem that you identified at the start:

At Sun, 08 Jul 2007 00:03:10 -0400, Jonathan S. Shapiro wrote:
> If we choose to adopt the "return the return value" convention, it is
> still necessary to handle capability returns specially in C, because the
> caller must say where the incoming capability is to be stored (we cannot
> get compiler help for this from an unmodified compiler).

Thus, there are three possible solutions for each of the two cases:
the compiler is taught how to copy capabilities/structs, the caller
passes a location in which the function should store the
capability/struct, or the function allocates a struct/slot using
something ala malloc and returns a reference to it that the caller may
have to eventually free.

Neal