develooper Front page | perl.perl5.porters | Postings from October 2016

Re: Nullable XS types

Thread Previous
bulk 88
October 23, 2016 20:34
Re: Nullable XS types
Message ID: wrote:
> Currently I have to do somewhat awkward steps to make a type that XS is
> happy to let turn perl-level undef into C-level NULL on input:
> This is somewhat awkward as, in this typemap file, I've had to decide
> what entire types are always nullable, or which ones never are. I can't
> make a decision on a per-function basis what will happen.
> I would like to be able to decide this at the level of individual
> functions. Does anyone have any suggestions?
> Ideeeeally what I'd love is to be able to simply type:
>   void
>   somefunc(self,rect)
>     SV *self
>     Tickit::Rect? rect
> or some other suitable abuse of notation, to say "Hey, XS, allow a
> perl-level undef to come in here, and that means the C-level value
> should be NULL". Perhaps similar for OUTPUT types
>   Tickit::Rect?
>   anotherfunc(self)
>     SV *self
> to mean that if I set RETVAL = NULL then that means it should return an
> undef to perl.
> Short of that somewhat-pipedream, is there anything practical I can do
> now, with existing technology, to make this a little less awkward?

I once created a type called "NSV *" with a C typedef to "SV *" when I 
wanted some xsubpp template processing of the SV * (input validation), 
but the C API I am wrapping takes SV *s, not basic C types. The C code 
++s refcnt and stores the SV *s in a 3rd party C lib for a while, 
eventually the SV*s come back to XS land, and to PP land and are --ed at 
that time.

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About