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 );

[download]
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

In reply to Re^8: Inline::C and NULL pointers by syphilis
in thread Inline::C and NULL pointers by markong

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.