PG 17.2 compilation fails with -std=c11 on mac

Lakshmi Narayana Velayudam <dev.narayana.v@gmail.com> writes:

When I trying to compiling postgres 17.2 with -std=c11 I am getting the
below error on mac

explicit_bzero.c:22:9: error: call to undeclared function 'memset_s'; ISO
C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]

Yeah, I can reproduce that. After some digging, I see that
the problem is explained by "man memset_s":

SYNOPSIS

#define __STDC_WANT_LIB_EXT1__ 1

#include <string.h>

errno_t
memset_s(void *s, rsize_t smax, int c, rsize_t n);

We lack that #define, which results in <string.h> not supplying
the declaration. AFAICT the requirement for this is in the C11
standard, this is not just Apple doing something weird.

(I did not figure out how come the code compiles without -std=c11.)

Aside from this compilation error, we're probably failing to use
memset_s on some platforms where it's available, for lack of
the #define in our configure/meson probes. I know how to fix
that in configure, but I'm less clear on how nonstandard probes
work in meson --- any help there?

regards, tom lane

I wrote:

We lack that #define, which results in <string.h> not supplying
the declaration. AFAICT the requirement for this is in the C11
standard, this is not just Apple doing something weird.
Aside from this compilation error, we're probably failing to use
memset_s on some platforms where it's available, for lack of
the #define in our configure/meson probes. I know how to fix
that in configure, but I'm less clear on how nonstandard probes
work in meson --- any help there?

Here's a lightly-tested fix for that (against HEAD, but it likely
works on v17 too).

regards, tom lane

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]https://man.freebsd.org/cgi/man.cgi?query=memset_s&amp;sektion=3, 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&amp;sektion=3