Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^9: Inline::C and NULL pointers

by markong (Pilgrim)
on Dec 23, 2021 at 15:00 UTC ( [id://11139862]=note: print w/replies, xml ) Need Help??


in reply to Re^8: Inline::C and NULL pointers
in thread Inline::C and NULL pointers

I certainly agree that NULL pointers are a common feature of C libraries ... I'm not convinced that the need to pass NULL pointers from perl to C functions is all that common.

There are many discussions about what is the right approach and there seems to be not an established consensus from what I read around. But!
Considering the nature of the tool is to glue to a different language interface, ( i.e. a collection of functions), then any source type you map into C/C++ will be used in the majority of cases as a function argument.

Consider also that NULL as argument is not just a poor C programming practice because often you need a "special" value to signal conditions, sometimes is even required(!) e.g.: strtok(3)/snprintf(3)/gettimeofday(2).

As SWIG already does, undef ==> NULL feels completely natural and I personally consider the lack in Inline as a bug. I've already solved by using SWIG as usual, maybe some Inline::C users could take from here and consider opening a related enhancement request.

Replies are listed 'Best First'.
Re^10: Inline::C and NULL pointers
by syphilis (Archbishop) on Dec 24, 2021 at 01:28 UTC
    maybe some Inline::C users could take from here and consider opening a related enhancement request

    This is the bit I don't quite get.
    Precisely what, IYO, should that "enhancement request" be seeking ?
    At the moment, all I've got is that "undef, when passed from perl to unsigned char * C argument, should be NULL". (That problem, at least, is solved.)
    What if we're passing something other than "undef" ? Should that be T_PV or T_PTR ? ... or something else ?

    What happens when the C function unsigned char * foo() returns a NULL to perl ? Should that come back as undef ?
    With T_PV it returns undef; with T_PTR it returns the IV zero. But this behaviour can be manipulated to whatever we want in ExtUtils/typemap (or user-provided typemap).

    Just give me a clear spec, I'll write a patch to ExtUtils/typemap that enacts that spec,and, if it passes review here, I'll see if I can get perl porters to accept it.
    That's where the change would best be made.

    If the proposed change is unacceptable to them, then we can look at making the change in Inline::C by use of a customized typemap. (No guarantees that it will be accepted there, either ... we'll just have to wait and see.)
    But I first need to see a clear spec of the requirement, telling me exactly what needs to be changed.

    Cheers,
    Rob

    UPDATE: If the only thing we want to do is to ensure that "undef" is passed as NULL to a char * (either signed or unsigned) then I think we need to change the "INPUT" setting in ExtUtils/typemap for T_PV from:
    $var = ($type)SvPV_nolen($arg)
    to
    if (SvOK($arg)) $var = ($type)SvPV_nolen($arg); else $var = INT2PTR($type,SvIV($arg))
    We can also achieve the same effect by creating a file named "typemap" that contains:
    INPUT T_PV if (SvOK($arg)) $var = ($type)SvPV_nolen($arg); else $var = INT2PTR($type,SvIV($arg))
    That file needs to be placed in a location where it will automatically be recognized as a typemap.

    For example, place that typemap file in the same directory as this little Inline:C script:
    use strict; use warnings; use Devel::Peek; use Inline C => Config => BUILD_NOISY => 1, # verbose build FORCE_BUILD => 1, # re-build whenever the script is run CLEAN_AFTER_BUILD => 0, # don't clean up the build directory ; use Inline C =><<'EOC'; unsigned char * foo(unsigned char *name) { if(name) printf("name is: %s\n", name); else printf("NULL input (undef) was detected\n"); return(name); } EOC my $x = foo(undef); Dump($x); my $y = foo("hello world"); Dump($y); my $z = foo(''); Dump $z;
    Then cd to that directory, run the script and tell me if it's doing something undesirable.

    Of course unsigned char* is not the only thing that maps to T_PV - char*, const char*, caddr_t, wchar_t* and Time_t* all map to T_PV, and will therefore all be affected by that typemap.
    But, if need be, we could always create a new and distinct type for those that need to use this revised setting.

    To run that script with the settings specified by ExtUtils/typemap, just rename "typemap" to something else, and it will be ignored.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11139862]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (6)
As of 2024-04-23 21:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found