On Thu, Feb 19, 2026 at 06:25:25PM +0200, Eli Zaretskii wrote: > > Date: Thu, 19 Feb 2026 17:17:11 +0100 > > From: Patrice Dumas <[email protected]> > > Cc: [email protected], [email protected] > > > > On Thu, Feb 19, 2026 at 05:47:19PM +0200, Eli Zaretskii wrote: > > > > Something that comes to me is that the libc includes are > > > > before the Perl includes, before the comment /* Avoid namespace > > > > conflicts. */ > > > > maybe you added the include later on, and it could matter? > > > > > > No, I added it before that. > > > > 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's your call, I'm not familiar with the code enough to have an > opinion. If you want me to try a patch, I can do that. > > The problem is not a grave one, in any case. The programs and > libraries do build and pass all the tests. A complication warning is > not a problem, and I can fix it by adding an explicit prototype in > that source file. So the solution of this could be deferred to the > next release, if you are okay with that.
Chances are if this code was actually run, there would be the "Free to wrong pool" error (on MS-Windows), depending on where this strndup function is actually coming from. If it's a version defined by gnulib, it would not be compatible with the 'free' function in the file as this is Perl's version of 'free'.
