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

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.