I think I see how typemaps work (bug, skip to end)

... xsubpp -typemap "...lib\ExtUtils\typemap" -typemap "...inline-c-mytypemap-null\mytypemap.txt"

https://metacpan.org/pod/xsubpp I see

typemap typemap Indicates that a user-supplied typemap should take precedence over + the default typemaps. This option may be used multiple times, with t +he last typemap having the highest precedence.

But it seems by using  unmapped     T_PTR you're getting the old T_PTR, not the new one, you can't redefine T_PTR, which makes sense

Actually it would seem that default typemap is clobbering your typemap definitions

#!/usr/bin/perl -- use strict; use warnings; use Path::Tiny qw/ path /; use Inline C => Config => BUILD_NOISY => 1, CLEAN_AFTER_BUILD => 0, typemaps => path( __FILE__ )->realpath->parent->path('mytypema +p.txt'), NAME => 'markong', FORCE_BUILD => 1, ## debuggery ;;;;;;;;;;;;; use Inline 'C' => <<'CODE'; typedef unsigned char * unmapped; unmapped foo(unmapped name) { if(name) printf("True\n"); else printf("False\n"); return(NULL); } unsigned char * bar() { return (foo(NULL)); } CODE use Devel::Peek qw/ Dump /; foo(undef); bar(); exit( 0 ); __END__

...
Finished Build Compile Stage

INPUT Too_PTR= at inline-c-mytypemap-null-11139712.pl line 46.
Use of uninitialized value in subroutine entry at inline-c-mytypemap-null-11139712.pl line 46.
False
OUTPUT Too_PTR= at inline-c-mytypemap-null-11139712.pl line 46.
False

## cannot redefine T_PTR INPUT/OUTPUT # unmapped T_PTR unmapped Too_PTR brokenmapped T_PTR # cannot redefine typemap for "unsigned char*" unsigned char * Foo_PTR INPUT T_PTR $var = BROKEN_INT2PTR($type,SvIV($arg)) Too_PTR STMT_START { Perl_warn(aTHX_ \"INPUT Too_PTR=%s\", $arg); $var = INT2PTR($type,SvIV($arg)); } STMT_END ; Foo_PTR STMT_START { Perl_warn(aTHX_ \"INPUT Foo_PTR=%s\", $arg); $var = INT2PTR($type,SvIV($arg)); } STMT_END ; OUTPUT Too_PTR STMT_START { Perl_warn(aTHX_ \"OUTPUT Too_PTR=%s\", $arg); sv_setiv($arg, PTR2IV($var)); } STMT_END ; Foo_PTR STMT_START { Perl_warn(aTHX_ \"OUTPUT Foo_PTR=%s\", $arg); sv_setiv($arg, PTR2IV($var)); } STMT_END ; T_PTR sv_setiv($arg, BROKEN_PTR2IV($var));

Digging down T_PTR is clobbered even if you don't specify the default typemap (see output of program, BROKEN_ gets replaced )

#!/usr/bin/perl -- use strict; use warnings; use ExtUtils::ParseXS::Utilities qw/ process_typemaps /; use Data::Dump qw/ dd /; dd( process_typemaps( './mytypemap.txt', ) ); __END__

So it makes sense or its documentation bug or behavior bug ... I dunno , I haven't used a keyboard in 6 months


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