Re: macOS 15.4 versus strchrnul()

On 01.04.25 17:57, Tom Lane wrote:
> That is, the function exists now in macOS' libc, and so configure's
> does-it-link test for HAVE_STRCHRNUL finds it, but <string.h>
> will not let you use it unless you monkey around with
> 
> export MACOSX_DEPLOYMENT_TARGET=15.4
> 
> or similar.  I don't think we want to require people to do that,
> so we need to fix things so that the code works with or without
> a deployment target that satisfies <string.h>.  This is pretty
> reminiscent of a problem that we faced a couple years ago with
> preadv and pwritev, and solved in commit f014b1b9b by depending
> on AC_CHECK_DECLS instead of AC_CHECK_FUNCS.  I made a patch
> (attached) to solve this similarly.  Interestingly, this actually
> makes the one usage in snprintf.c simpler, since we no longer
> need to special-case the situation where GNU <string.h> doesn't
> agree with the does-it-link test.

Agreed, this matches my research.

> However ... testing this here shows that it fixes the autoconf
> build as desired, with or without MACOSX_DEPLOYMENT_TARGET.
> But the meson version *does not work*: it will set
> HAVE_DECL_STRCHRNUL to 1 with or without MACOSX_DEPLOYMENT_TARGET,
> and in the "without" case the build then blows up.
> 
> I speculate that the meson test for preadv/pwritev has never worked
> for macOS either, and we haven't noticed because nobody has tried to
> build with meson on a machine with low enough default deployment
> target to not have preadv/pwritev.

Agreed.  Attached is a patch that implements the test more along the 
lines of how Autoconf does it.  This gives correct results for me for 
strchrnul() in various configurations.

Btw., I see on the buildfarm that strchrnul() is also available on 
FreeBSD, DragonFly BSD, NetBSD, and musl (Alpine Linux).  So perhaps 
some of the comments ought to be rewritten away from that it's a 
glibc-specific extension.