|
in reply to Re^3: Inline::C and NULL pointers
in thread Inline::C and NULL pointers
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 |
Re^5: Inline::C and NULL pointers
by etj (Deacon) on Dec 20, 2021 at 01:22 UTC
|
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]
[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]
[d/l]
[select] |
Re^5: Inline::C and NULL pointers
by NERDVANA (Deacon) on Dec 20, 2021 at 02:50 UTC
|
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] |
|
|
.... 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]
[d/l] |
|
|
> 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.
In addition to that, it also deals with the compiling and linking stage automagically for you, particular when using a Alien::* module that provides an Inline method. And if your Alien need calls for it, it may provide a set of AUTO_INCLUDEs for you. Alien::OpenMP does this for you, e.g.
See Inline::C::Cookbook for more info (scroll down to discussion).
| [reply]
[d/l] |
|
|
Well ... Inline::C is, in the final analysis, nothing other than XS.
Of course it sits on top of XS, but so does any other tool that has to reach out to C/C++ (and for this matter any other language e.g.: Java's JNI). SWIG is a case in point which does that for a plethora of languages: but it's not just XS, or JNI, or Python's C extensions: it's all those things packaged in a coherent way with extensive documentation attached; which is really all I want when I am doing Perl, because if I am doing Perl I want to stay away from XS/C as much as possible.
The same thing with a compiler tool-chain: sits on top of many tools and low level languages, but it's not just assembly or machine code.
So, we are talking about two different levels of abstraction: tools like Inline::C which conveniently hide the low level details and sits in the middle, should hopefully provide support for the most common use cases and provide extension points for the uncommon cases.
If we agree that NULL pointers are a common feature of the C libraries, than I would expect transparent support for those by default.
I'm pretty surprised that this never came up before given the widespread use of NULLs in C code...or maybe people just gave up (see next point).
... Inline::C already does that by providing us with the TYPEMAPS configuration option ... we can fix that using our own custom typemap.
Right, it could even be just a matter of a new module which install an extra typemap definition borrowed from the SWIG's one...if only that was doable in a reasonable manner: as your extensive analysis has showed in different part of the thread, it seems the original author was drunk when wrote the logic behind the whole "local typemap" option :P.
There are at least two bugs resulting in weird interactions when one tries to extend the very simple Perl default typemap to "override" something:
probably people instead used SWIG to handle NULL pointers.
| [reply] |
|
|
|
|
|
|
| |
|
|
|
|
