xsubpp: fix C23 incompatibility in XSINTERFACE_* macros (another attempt)

[xenu]

This is a proof of concept, not sure if this is the right direction.

[xenu]

Argh, I tested this on the wrong checkout, the code was broken.

It should work now, but there's another problem. The INTERFACE handler now declares the XSFUNCTION variable, and that handler is being called after the declarations are outputted. This means we're now potentially mixing declarations and code, which requires C99.

Perl itself has been requiring C99 for a while, but ExtUtils::ParseXS is dual-life, so I'm not sure if it's fine.

[xenu]

Also, the failing dist tests made me realize that this modifies XSUB.h, which is part of Perl, not ExtUtils-ParseXS, which means 1) It won't help older perls 2) ExtUtils-ParseXS would have to be modified to handle both old and new APIs

I don't really like this solution.

[bulk88]

Also, the failing dist tests made me realize that this modifies XSUB.h, which is part of Perl, not ExtUtils-ParseXS, which means 1) It won't help older perls 2) ExtUtils-ParseXS would have to be modified to handle both old and new APIs

I don't really like this solution.

Yeah, P5P can usually monkey patch EU::PXS from their side when EU::PXS isn't on its best behavior, but better strategy as you said is editing EU::PXS.pm directly, either as blead CUSTOMIZED or submitting a formal PR to its poorly-responsive owner/maintainer on CPAN. Last part has been solved since EU::PXS on CPAN is now owned by a highly responsive P5P commit bit person, or now owned by P5P as a group. Remember to check GrepCPAN if these/any macros written by p5p/.git are getting unofficial usage on CPAN.

EU::PXS.pm for a long time has mentioned in its source code comments, that it and its polyfill macros, are not a replacement/successor for unmaintained ppport.h. And it says EU::PXS.pm's polyfill macro identifiers are NOT!!!! NOT!!!! for use by CPAN XS authors and it is not, and will not become a next-generation PPPort.pm and is not an old perl interp service pack delivery mechanism. The implied meaning is, for CPAN XS authors to write their own polyfill macros/static funcs under a CPAN XS mod's/author's personal C identifiers. Of course FOSS copy pasting is always allowed in Perl 5 ecosystem, aslong as tokens/identifiers are changed and the XS author assumes src code responsibility.

IME blead CUSTOMIZED.dat is yak shaving hopeless without a commit bit and backroom negotiate with the pumpking to do a no-warning push to blead, since your RT ticket will not survive the vigilante mob that shows up and says any use of CUSTOMIZED.dat is always illegal. Post-PSC maybe things have changed, but I've had patches on P5P RT derailed too many times with that line, for a CPAN module has multiple bug tickets open, multiple ignored patch tickets open, and the last release is 9+ months ago or 3 years ago, or more, and its PAUSE maintainer has disappeared from the perl community.

[xenu]

As I said, I don't like this solution, and as discussed in #23192, we'll probably rework how INTERFACE works instead.

I'm abandoning this PR.