I wrote:
> Here's a lightly-tested fix for that (against HEAD, but it likely
> works on v17 too).
Pushed that. It did require adjustments for the back branches.
For the archives' sake: I checked which buildfarm animals report
having memset_s(). They are
anaconda | 2025-05-18 08:22:35 | checking for memset_s... (cached) yes
billbug | 2025-05-18 15:00:02 | checking for memset_s... (cached) yes
conchuela | 2025-05-18 08:20:25 | checking for memset_s... (cached) yes
dikkop | 2025-05-18 09:05:01 | checking for memset_s... (cached) yes
hake | 2025-05-18 08:20:04 | checking for memset_s... (cached) yes
indri | 2025-05-18 08:24:31 | checking for memset_s... (cached) yes
loach | 2025-05-18 08:25:12 | checking for memset_s... (cached) yes
longfin | 2025-05-18 08:12:01 | checking for memset_s... (cached) yes
margay | 2025-05-18 16:00:03 | checking for memset_s... (cached) yes
opaleye | 2025-03-12 03:06:14 | checking for memset_s... (cached) yes
pollock | 2025-05-17 06:17:24 | checking for memset_s... (cached) yes
sevengill | 2025-04-29 03:51:04 | Checking for function "memset_s" : YES
sifaka | 2025-05-18 08:11:57 | checking for memset_s... (cached) yes
These are all macOS, FreeBSD, Solaris, or derivatives. However,
FreeBSD and Solaris also have explicit_bzero(). That means we don't
need to build explicit_bzero.c on those platforms, and thus macOS is
the only platform where we are attempting to use memset_s(). So we
don't actually have any evidence whether there's an issue on anything
besides macOS. The FreeBSD man page for memset_s() does mention
__STDC_WANT_LIB_EXT1__ [1], so it's possible our code would have
failed there too, if we were reaching it. I didn't check Solaris.
regards, tom lane
[1] https://man.freebsd.org/cgi/man.cgi?query=memset_s&sektion=3
