I doubt that would make it have any impact. "no warnings ..." impacts lexical scope which is likely restricted to the call_pv() call. But even if call_pv() doesn't define (and destroy) a new lexical scope, I still doubt it would have any impact. "no warnings ..." works by tagging the Perl op-codes that are generated. XS code isn't running Perl op-codes, especially not ones compiled after the call to call_pv().

My main advice is to stop messing with Perl data structures in XS code. This is just one of the problems that result from such. The others tend to be worse.

My main advice is to stop messing with Perl data structures in XS code.

Sure, if you want to do it for all your functions you could probably use

no warnings 'uninitialized';
XSLoader::load();
[download]

Problem with that, its all-or-nothing, if you want to isolate a single sub , you have to set $^WARNING_BITS, because the alternative is this wrapper crap

sub notFun {
    no warnings 'uninitialized';
    goto &_notFunXS;
}
[download]

Problem with that, its all-or-nothing, if you want to isolate a single sub , you have to set $^WARNING_BITS, because the alternative is this wrapper crap

sub notFun {
    no warnings 'uninitialized';
    goto &_notFunXS;
}
[download]

I'm not sure how a wrapper takes the "fun" out things for you. But providing a Perl wrapper for an XS function often makes using the module more fun than having to deal with the relatively brittle interfaces that get created when code is written in XS.

So I'd encourage using a wrapper, but one that not just disables one annoying warning, but one that pulls the data out of Perl-friendly structures and puts it into C-friendly structures so that your XS code can just deal with the data easily and can avoid the convoluted and complex issues of Perl reference counts and potential "magic".

So the wrapper can deal with the problem of undef using a language that makes that easy (Perl).

- tye