Re: IDL issue - struct return vs. cap return

[Jonathan S. Shapiro]

On Tue, 2007-07-10 at 12:34 +0200, Neal H. Walfield wrote:

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

Just because you want this behavior doesn't meant that your program
actually does that.


I will respond to your example in greater detail in my next message.

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

No. You argued that compilers do not implement this. I have consistently
stated that they *do* implement it.

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

Hmm. Yes. I had not considered the possibility that the receiver might
have to free capability slots explicitly. This seems very difficult to
do correctly without GC, since the locations are likely to become widely
referenced. From a management perspective, in the absence of GC, it
seems to me that the stub is sitting in the wrong place to make good
decisions about allocation strategy.

However, I agree that it is a possible design.

shap