Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^6: Inline::C and NULL pointers

by syphilis (Archbishop)
on Dec 20, 2021 at 03:53 UTC ( #11139759=note: print w/replies, xml ) Need Help??


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

.... the purpose of Inline::C is to be a more friendly integration between the languages than XS

Well ... Inline::C is, in the final analysis, nothing other than XS. The "friendly" aspect of it is that it automatically does all of the work for you - it automatically creates the entire XS distro (Makefile.PL, XS file, pm file), compiles it, installs it, then executes the script.
I don't think I've ever expected more friendliness than that - but that's not really a benchmark that should be set by me.

I think it's reasonable to ask Inline::C to do a little more work than perl's default typemap.

I think Inline::C already does that by providing us with the TYPEMAPS configuration option - so that, if the default typemap doesn't do what we want, then we can fix that using our own custom typemap.
I guess there's always room for improvement, but Inline::C should also avoid attempts at reading minds.
It's also currently being actively maintained - so feature requests, bug fixes, patches would all be considered.

Cheers,
Rob

Replies are listed 'Best First'.
Re^7: Inline::C and NULL pointers
by perlfan (Vicar) on Dec 20, 2021 at 20:40 UTC
    > Well ... Inline::C is, in the final analysis, nothing other than XS. The "friendly" aspect of it is that it automatically does all of the work for you - it automatically creates the entire XS distro (Makefile.PL, XS file, pm file), compiles it, installs it, then executes the script.

    In addition to that, it also deals with the compiling and linking stage automagically for you, particular when using a Alien::* module that provides an Inline method. And if your Alien need calls for it, it may provide a set of AUTO_INCLUDEs for you. Alien::OpenMP does this for you, e.g. See Inline::C::Cookbook for more info (scroll down to discussion).

Re^7: Inline::C and NULL pointers
by markong (Pilgrim) on Dec 20, 2021 at 23:06 UTC
    Well ... Inline::C is, in the final analysis, nothing other than XS.

    Of course it sits on top of XS, but so does any other tool that has to reach out to C/C++ (and for this matter any other language e.g.: Java's JNI). SWIG is a case in point which does that for a plethora of languages: but it's not just XS, or JNI, or Python's C extensions: it's all those things packaged in a coherent way with extensive documentation attached; which is really all I want when I am doing Perl, because if I am doing Perl I want to stay away from XS/C as much as possible.
    The same thing with a compiler tool-chain: sits on top of many tools and low level languages, but it's not just assembly or machine code.

    So, we are talking about two different levels of abstraction: tools like Inline::C which conveniently hide the low level details and sits in the middle, should hopefully provide support for the most common use cases and provide extension points for the uncommon cases.
    If we agree that NULL pointers are a common feature of the C libraries, than I would expect transparent support for those by default.
    I'm pretty surprised that this never came up before given the widespread use of NULLs in C code...or maybe people just gave up (see next point).

    ... Inline::C already does that by providing us with the TYPEMAPS configuration option ... we can fix that using our own custom typemap.

    Right, it could even be just a matter of a new module which install an extra typemap definition borrowed from the SWIG's one...if only that was doable in a reasonable manner: as your extensive analysis has showed in different part of the thread, it seems the original author was drunk when wrote the logic behind the whole "local typemap" option :P.
    There are at least two bugs resulting in weird interactions when one tries to extend the very simple Perl default typemap to "override" something:
    probably people instead used SWIG to handle NULL pointers.

      If we agree that NULL pointers are a common feature of the C libraries, than I would expect transparent support for those by default.

      That "transparent support" can only be enacted by altering ExtUtils/typemap. The way to address this is to file an Issue with perl5. (Thanks etj for supplying the appropriate link.)
      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.

      it seems the original author was drunk when wrote the logic behind the whole "local typemap" option :P

      It seemed that way partly because of the way that things unfolded as I muddled my way through it. (You'd be excused for thinking that *I* was drunk. I wasn't, but I felt like I was by the end of it.)
      Based on what I know at the moment, I think the succinct way to describe the bug is:

      "User-supplied typemaps other than ./typemap and ../typemap cannot override the type settings specified in ExtUtils/typemap"

      I believe this is an ExtUtils::ParseXS bug that has been around for a long time - I see the same behaviour on perl-5.8.8.
      I would think it's very rare that a user wants to override an ExtUtils/typemap setting, and even rarer that a user would try to do that in a typemap other than ./typemap or ../typemap. So I'm not at all surprised that it has taken a long time to surface.

      I'll file a bug report, and update this thread with a link to it. Might take a day or two. I'll spend some time trying to work out how to fix it first.
      It might simply be that these problematic user typemaps are being prepended (instead of appended) to the list of typemaps. That would be consistent with what we're seeing, though the output I see with verbose (BUILD_NOISY) builds of the Inline::C scripts suggests that they are being appended.

      UPDATE:In ExtUtils::ParseXS::Utilities::process_typemaps() we find the following line of code:
      push @tm, standard_typemap_locations( \@INC );
      Prior to this push() any typemap specified by the user that is not in one of the standard typemap locations is already included in @tm.
      And this push() ensures that ExtUtils/typemap can be found *after* (and will override any conflicts with) that user-specified typemap.
      Changing the push() to an unshift() fixes that problem, enabling the user-specified typemap to take precedence - which is exactly what we want.
      However, I just need to determine what would be broken by that change. Another option is to stay with the push() and simply remove ExtUtils/typemap from the list returned by standard_typemap_locations(\@INC) - which I think might be a better approach if I can ascertain that ExtUtils/typemap is guaranteed to already be in @tm.

      Cheers,
      Rob
        Rob, I am glad that other Monks jumped in on this.

        I agree with this: I'm not convinced that the need to pass NULL pointers from perl to C functions is all that common.

        As I mentioned in previous posts, the OP is confronted with some poorly written C code that he can't change. This NULL pointer idea arises from an I/F that says: "if you give a pointer to memory, I will use that memory for output, assuming without question that you have given me enough memory for my yet to be generated output. If you don't give me such a pointer, I will give you a pointer to my non-thread-safe non-recursion-safe static memory." This is a bullshit I/F. But the OP can't change that.

        NULL as the 2nd param is a weird situation. If there could be one arg and an optional second arg, then normally this would be implemented with a variable number of args - you don't put NULL, for that second arg - it is simply not there at all for the caller. This of course requires different C code than what the OP is dealing with. printf() for example uses a variable number of arguments.

        I did have fun with Inline::C and found it to be "easy to use" for all the "heavy lifting" that is does.

        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.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2022-06-28 18:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My most frequent journeys are powered by:









    Results (92 votes). Check out past polls.

    Notices?