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 | [reply] [Watch: Dir/Any] |
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?
| [reply] [Watch: Dir/Any] [d/l] |
(e.g. on CPAN, it's 3.35 from Jul 2017; in Perl it's 3.44)
Yes, I've seen your latest post to #16916. Good luck with that.
A few days ago, on the porters list, someone volunteered to address that very issue.
In the past, I've experienced similar frustration in the other direction - ie trying to get perl updated to the latest version on CPAN.
These dual-life modules are a wonderful idea ... until they're not.
Have you tried putting a new T_PTR definition in your own typemap?
I don't see any point in that wrt the issue of getting undef passed from perl into C space as a NULL.
The issue is that unsigned char* is presently being typemapped to T_PV in lib/ExtUtils/typemap.
AFAIK, there's no need to alter the current T_PTR definition; it's just a matter of getting the unsigned char * typemapped to T_PTR. (And that's precisely what happens in my little custom typemap that Inline::C finds.
I did first try editing ExtUtils/typemap so that unsigned char* is typed to T_PTR, and that had the desired effect of passing undef as NULL, and without any need for a custom typemap.
But I don't think it's a good idea to be modifying CORE files.
Cheers, Rob
| [reply] [Watch: Dir/Any] [d/l] [select] |
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.
| [reply] [Watch: Dir/Any] |
.... the purpose of Inline::C is to be a more friendly integration between the languages than XS
Well ... Inline::C is, in the final analysis, nothing other than XS. The "friendly" aspect of it is that it automatically does all of the work for you - it automatically creates the entire XS distro (Makefile.PL, XS file, pm file), compiles it, installs it, then executes the script.
I don't think I've ever expected more friendliness than that - but that's not really a benchmark that should be set by me.
I think it's reasonable to ask Inline::C to do a little more work than perl's default typemap.
I think Inline::C already does that by providing us with the TYPEMAPS configuration option - so that, if the default typemap doesn't do what we want, then we can fix that using our own custom typemap.
I guess there's always room for improvement, but Inline::C should also avoid attempts at reading minds.
It's also currently being actively maintained - so feature requests, bug fixes, patches would all be considered.
Cheers, Rob
| [reply] [Watch: Dir/Any] [d/l] |