Re: IDL issue - struct return vs. cap return

"Jonathan S. Shapiro" <[email protected]>
Newsgroups gmane.os.hurd.l4
Message-ID <[email protected]>
On Tue, 2007-07-10 at 17:24 +0200, Neal H. Walfield wrote:
> > 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).
> > 
> > How is this different from returning a struct?  There is a general
> > rule of thumb not to return large structs from function calls.
> > Instead, the convention is for either the function allocates memory or
> > the caller to pass a pointer to a block of allocated memory.
> 
> You appear to me to have implied that return by value is somehow
> normal and that return by reference is not.  My observation was that
> structs are often returned by reference, not by value.

You are mistaken.

It is certainly true that *users* often write procedures in such a way
that structures are returned by reference. However, from the compiler
perspective the declared return type in this case is always "struct *",
which is a *scalar* that is returned *by value*.

All parameter and return value passing in C is by value. It is possible
for users to construct by-reference conventions on top of this, but the
compiler has no knowledge of this.

> I claimed that
> if you want to generally return structs by value, then there are
> scenarios where you also need to modify the compiler--just like when
> returning capabilities by value.

Well, you're going to have to give an example on the struct thing,
because from the C compiler perspective structs are passed and returned
by value, and have been for almost 30 years now.

I'll respond on the capability thing separately, since I think the
issues are diverged.

shap
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.