macOS 15.4 versus strchrnul()

Last night I updated the machine that hosts sifaka and indri
to spankin' new macOS Sequoia 15.4, and that promptly broke
the build on both animals:

snprintf.c:350:1: error: static declaration of 'strchrnul' follows non-static declaration
350 | strchrnul(const char *s, int c)
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX15.4.sdk/usr/include/_string.h:198:9: note: previous declaration is here
198 | strchrnul(const char *__s, int __c);
| ^
snprintf.c:414:27: error: 'strchrnul' is only available on macOS 15.4 or newer [-Werror,-Wunguarded-availability-new]
414 | const char *next_pct = strchrnul(format + 1, '%');
| ^~~~~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX15.4.sdk/usr/include/_string.h:198:9: note: 'strchrnul' has been marked as being introduced in macOS 15.4 here, but the deployment target is macOS 15.0.0
198 | strchrnul(const char *__s, int __c);
| ^
snprintf.c:414:27: note: enclose 'strchrnul' in a __builtin_available check to silence this warning

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.

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.

I do not know nearly enough about meson to fix that test;
can anyone help?

regards, tom lane