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

Re: Nullable XS types

Thread Previous
From:
bulk 88
Date:
October 23, 2016 20:34
Subject:
Re: Nullable XS types
Message ID:
CY4PR04MB066363CA6A28A48A85007460DFD60@CY4PR04MB0663.namprd04.prod.outlook.com
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.

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About