Jan Dubois wrote:
> [Any reason you removed the CC to the perl-xs list?]
Oops, no, that was accidental. Adding it back, and quoting your reply below for
the benefit of the public.
>>>> I don't see a way to avoid this if you use PPCODE sections to return more
>>>> than
>>>> one value.
>>> Yes, so use CODE sections with multiple OUTPUT variables. You can still
>>> explicitly adjust the stackpointer an XSRETURN_EMPTY in an error branch
>>> if you don't want to return your output variables on error. The OUTPUT
>>> handling is only executed when you fall off the end of your XS code.
>> Interesting. I didn't know that OUTPUT could handle multiple return values.
>
> Actually, I think I was wrong: you cannot have multiple return values with the
> OUTPUT section, you can only designate additional values using parameters that
> have been passed in with this.
>
> But at least in newer versions of xsubpp you can use the OUTLIST modifier
> on arguments to add the to the output list (check perlxs.pod in newer Perl
> versions).
Yeah, but I've seen strange bugs with OUTLIST. I don't remember the details,
but I think the bugs only occurred when ExtUtils::ParseXS' xsubpp was in use.
The symptom was a spurious "Modification of a read-only value attempted"
warning.
>> What if there is a variable number of return values? Imagine, for example, a
>> function foo(int*, char**) that I would wrap as follows:
>>
>> void
>> foo (int *n_return_values, double **return_values)
>> PREINIT:
>> int n_return_values = 0, i;
>> double *return_values = NULL;
>> PPCODE:
>> foo (&n_return_values, &return_values);
>> EXTEND (SP, n_return_values);
>> for (i = 0; i < n_return_values; i++) {
>> PUSHs (sv_2mortal (newSVnv (return_values[i])));
>> }
>>
>> Is there a way to let typemaps do the work in this case?
>
> I don't see a way to get this working using typemaps, sorry.
Over in the gtk2-perl camp, we're hoping to mostly automate the creation of
bindings with gobject-introspection anyway, so no bid deal. :-)
-Torsten
