On Thu, Feb 19, 2026 at 05:17:11PM +0100, Patrice Dumas wrote: > Maybe strndup is not defined/redefined by Perl at all, then. In that > case, maybe a solution could be to use our own Perl-compatible strndup > implementation, which is the perl_only_strndup function. I think that > the use of strndup in C code built against Perl headers is quite new, it > is possible that we never had code like that before.
It should be easy to avoid using strndup in favour of more standard functions in the code that includes the Perl headers. We use our own function non_perl_strndup in numerous places in this file; would we not just use that in this one place where strndup occurs intead? That should silence the warning that Eli reported. At this stage, I'm actually slightly concerned about adding new include directives to files and worry it could cause breakage due to the wrong definitions being used, files being included in the wrong order, or whatever. I don't want to do another pretest as it has already been tested enough and we are hardly making any changes now, and it's a burden on interested users who want to help test the pretests. I notice that convert/call_conversion_perl.c does not include any system include files either and yet it uses fprintf and size_t, at least. Yet there have been no reports of errors. Evidently the correct header files are being included indirectly. I suggest that we can fix these files so they include the right headers immediately after the release.
