Re^2: Silencing warnings inside C/XS (no no)

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.

- tye

Comment on Re^2: Silencing warnings inside C/XS (no no)

Replies are listed 'Best First'.
Re^3: Silencing warnings inside C/XS (no no) by Anonymous Monk on Oct 08, 2012 at 15:59 UTC
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]	[reply] [d/l] [select]
Re^4: Silencing warnings inside C/XS (wrapper) by tye (Sage) on Oct 08, 2012 at 16:44 UTC
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	[reply] [d/l]