in reply to Re^4: Inline::C and NULL pointers
in thread Inline::C and NULL pointers

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?

Replies are listed 'Best First'.
Re^6: Inline::C and NULL pointers
by syphilis (Archbishop) on Dec 20, 2021 at 03:19 UTC
    (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