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

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]

Comment on Re^3: Silencing warnings inside C/XS (no no) Select or Download Code

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]