On Tue, Jul 29, 2014 at 3:14 AM, Nick Wellnhofer <[email protected]> wrote:
> There is also a minor inconsistency in the functions that map a method's
> return type for XSUBs and callbacks. In CFCPerlTypeMap_to_perl which is used
> for XSUBs we have this piece of code:
>
> else if (CFCType_is_composite(type)) {
> if (strcmp(type_str, "void*") == 0) {
> // Assume that void* is a reference SV -- either a hashref or an
> // arrayref.
> result = CFCUtil_sprintf("newRV_inc((SV*)%s)", cf_var);
> }
> }
>
> The code in CFCPerlMethod_callback_def doesn't support 'void*' return types.
> Assuming that void pointers are a reference SV looks a bit fragile to me.
> Are there any places where we rely on this behavior?
Your analysis is dead on.
That snippet is an artifact of a dreadful hack I thought I had eliminated a
while ago. Once upon a time, the autogenerated XS binding for
LUCY_Doc_Get_Fields depended on that hack, but we now supply a hand-rolled XS
binding so it's no longer an issue.
However, it turns out that disabling that block prevents autogenerated XS
bindings from being created for the following methods, visible by diffing the
autogenerated files Clownfish.xs and Lucy.xs before and after.
CFISH_Obj_To_Host
CFISH_Class_To_Host
CFISH_Err_To_Host
CFISH_LFReg_To_Host
LUCY_Doc_To_Host
LUCY_MemPool_Grab
LUCY_SortCache_Get_Ords
Calling either MemPool#grab or SortCache#get_ords from Perl is going to
explode when the autogenerated XS binding calls newRV_inc() on their return
values -- illustrating why we need to give this hack the heave-ho.
However, we'll need to figure out what to do about To_Host() first.
Marvin Humphrey
