On Wed, 2004-04-28 at 03:23, Leopold Toetsch wrote:
> > I patched pcf_i_pt33()
>
> missing test?
That's an autogenerated file and my patch was only a local proof of
concept. I'm not sure exactly how the interface should look, so I
haven't written the test yet.
> Well, that's ok for this one. Bu, what if we have:
>
> int foo(int *i, int *j) {}
>
> in I5 in I6
> out I5
>
> We could fake that as:
>
> (i, j, retval) = foo(i, j)
>
> and count each pointer type as retval too. Or something...
That seems the easiest to me. It's clearer, Parrot-wise, to follow with
the calling conventions. I'd rather expose those return conventions
than the C out parameter interface. Yuck.
> Or, we forget about these special cased pointer to int and pass a
> managed struct.
That's cleaner from the C side, but it's enough of a pain to set up
managed structs on the calling side that I'd rather do it only when it's
absolutely necessary.
Provided we pick a convention that makes sense (that is, out parameters
go in I5, I6, ... In, and then the actual returned value goes at the end
of the list in In+1) and stick with it, I like option A a little better.
If that's the case, we need some way of marking parameters as having
important return values in src/call_list.txt and a bit of modification
to save those values in the generated src/nci.c.
-- c
