I really do think it would be better if our user-supplied typemap took precedence over ExtUtils/typemap.

Turns out it does ... but only if it's named "typemap" and is in the current working directory. (Calling it something else is alone insufficient - on my Windows 7 system, at least.)
It then turns out that there's no need for the typedeffing either.

This is a much simpler way of ensuring that undef is passed as a NULL:
1) Have a file named exactly "typemap" in the cwd that contains the following single line (ending in a newline): 
unsigned char *     T_PTR

[download]
2) The following demo script then passes 'undef' as a NULL to the C function foo(): 
use strict;
use warnings;

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("True\n");
  else printf("False\n");
  return(NULL);
}

EOC

foo(undef);

__END__
Outputs:
Use of uninitialized value in subroutine entry at try2.pl line 20.
False

[download]
I don't know why naming the typemap to something other than "typemap" should be inadequate - even stranger that it then could be made to work if unsigned char* was typedeffed to something else.
Unless I can find some documentation that explains that weirdness, then I can only think that it's an Inline::C bug.
I'll investigate that this issue and try to come up with a patch that fixes it if it's indeed a bug.

Note that the file named "typemap" gets found automatically if it's located in the CWD. There's no need to engage the "TYPEMAPS" configuration option.

UPDATE: It seems that a file named "typemap" will also be found and used automatically if it's in the .. or the lib/ExtUtils directory.
If it's not called "typemap" && it's not in lib/ExtUtils or . or .. directories, then its location will be passed on to xsubpp (which will acknowledge that it has been informed of the file's existence) if and only if the file's location is specified in the 'TYPEMAPS' Config entry.
But then xsubpp just silently ignores it completely unless it maps a type not covered by the files named "typemap" that were automatically found. (Hence my "nullmap.txt" from a previous post was able to be used.)
As Bill Burroughs once said, "this is *insane* ... this *is* insane ... *this* is insane".
Where should issues/PRs for EU::ParseXS be filed ? .

Cheers,
Rob

In reply to Re^6: Inline::C and NULL pointers ( override default xsubpp ExtUtils::ParseXS::Utilities::process_typemaps ) 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.