Re: Nullable XS types

leonerd@leonerd.org.uk 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:
>   https://metacpan.org/source/PEVANS/Tickit-0.59/typemap#L9
> 
> 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.

• Nullable XS types by Paul "LeoNerd" Evans
• Re: Nullable XS types by Father Chrysostomos
• Re: Nullable XS types by bulk 88