use strict;
use warnings;

use Inline C => Config =>
  BUILD_NOISY => 1,
;

use Inline C =><<'EOC';

unsigned char * foo(unsigned char * name) {
  if(name) printf("True\n");
  else printf("False\n");
  return(NULL);
}

unsigned char * bar() {
  return (foo(NULL));
}

EOC

foo(undef);
bar();

__END__
Outputs:
True
False
[download]

 
# plagiarised from default perl typemap

unmapped     T_PTR

INPUT

T_PTR
    $var = INT2PTR($type,SvIV($arg))

OUTPUT
T_PTR
    sv_setiv($arg, PTR2IV($var));
[download]

use strict;
use warnings;

use Inline C => Config =>
  TYPEMAPS    => "nullmap.txt",
  BUILD_NOISY => 1,
;

use Inline C =><<'EOC';

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

EOC

foo(undef);
bar();

__END__
Outputs:
False
False
[download]

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

Read more... (4 kB)

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

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

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

Thanks for digging that up.
I really do think it would be better if our user-supplied typemap took precedence over ExtUtils/typemap. (This is something that should probably be investigated further.)

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.

My T_PTR is the same as the original T_PTR, as there was nothing wrong with the original.
I just had to change the typing of unsigned char* from T_PV to T_PTR. I could only make that switch for the unmapped type, which was a typedef of unsigned char*.
Seems I won't need that typedef if I can get the two typemaps to load in the reverse order.

I've just checked and found that I didn't need to provide the T_PTR "INPUT" and "OUTPUT" routines in my custom typemap ("nullmap.txt").
That file needs only to consist of:

unmapped     T_PTR
[download]

and the T_PTR "INPUT" and "OUTPUT" routines will be read from ExtUtils/typemap.
Apologies - I did wonder about that at the time, but didn't spend the 10 seconds it takes to find out.
'Twould have been much clearer if I had presented the one-line "nullmap.txt" instead of the multi-line version with its "INPUT" and "OUTPUT" sections.

Cheers,
Rob

FuncA("abc",undef,"xyz"); FuncA("abc",3,"xyz"); FuncA("abc","nmo","xyz
+");
FuncB(1,undef,3); FuncB(1,"some string",3);
[download]

So as my first example post code shows, instead of char* in the C function definition, you need SV*. undef can be passed as an SV value. There is a C function to determine the exact Perl "type" of that SV value (I didn't show that, but there is such a function). My example just showed a simple test for "does this SV structure contain a Perl string or not?". I have seen more complex tests often with complicated || logic. But my first test code shows a simple test for whether the SV contains a valid string within its structure or not and how to deal with the result of that test.

You will have to modify the C function definition to have a pointer to SV (SV*) instead of pointer to character (char*). As my code shows, if that SV doesn't have a valid string, set pointer equal to NULL. If that SV does contain a string, then extract the pointer to that string. When you have a simple char*, this translation is done automatically for you. But undef throws a wrinkle into the works.

I am sure there are some really wild border cases like Perl passing, "123": That is a string but Perl would treat it as an int if used in a math operation.

Yet another thought:
As I think about this, you are copy and pasting this guy's C code into an inline::C Perl section mainly to reduce "start time". You want to call this guy's C code from Perl. But you don't want to modify this guy's code. So instead of calling this guy's code directly, you could write a "wrapper" C function, which you call from Perl. That C wrapper resolves these undef issues and then calls that guy's code. His code is never called with an undef value.

You write:

unsigned char *my_enctypex_msname(unsigned char *name, SV *ret){
   this C code handles undef appropriately and then
   calls the "copy and paste" enctypex_msname(unsigned char *name, cha
+r* ret){}
}
[download]

I'm surprised that undefs wouldn't become NULL; that's the behavior I'd want too.

The way I'm seeing it, the behaviour you want is not happening because of perl's default typemap.
But if that's a bug, it's a Perl bug not an Inline::C bug.
At least Inline::C provides the rope for one to change that behaviour.

Cheers,
Rob

Strictly, it would not be a Perl bug but maybe an ExtUtils::ParseXS shortcoming. That's quite a slow-moving bit of code (e.g. on CPAN, it's 3.35 from Jul 2017; in Perl it's 3.44). Have you tried putting a new T_PTR definition in your own typemap?

Since the purpose of Inline::C is to be a more friendly integration between the languages than XS, I think it's reasonable to ask Inline::C to do a little more work than perl's default typemap.