Check for memset_explicit() and explicit_memset()
We can use either of these to implement a missing explicit_bzero().
explicit_memset() is supported on NetBSD. NetBSD hitherto didn't have a
way to implement explicit_bzero() other than the fallback variant.
memset_explicit() is the C23 standard, so we use it as first preference.
It is currently supported on:
- NetBSD 11
- FreeBSD 15
- glibc 2.43
It doesn't provide additional coverage, but as it's the new standard,
its availability will presumably grow, and eventually we'll be able to
remove some of the fallback variants.
Attachments:
0001-Check-for-memset_explicit-and-explicit_memset.patchtext/plain; charset=UTF-8; name=0001-Check-for-memset_explicit-and-explicit_memset.patchDownload+28-6
Hi,
On Mon, Feb 23, 2026 at 08:12:41AM +0100, Peter Eisentraut wrote:
We can use either of these to implement a missing explicit_bzero().
explicit_memset() is supported on NetBSD. NetBSD hitherto didn't have a way
to implement explicit_bzero() other than the fallback variant.memset_explicit() is the C23 standard, so we use it as first preference. It
is currently supported on:- NetBSD 11
- FreeBSD 15
- glibc 2.43
@@ -1846,6 +1847,7 @@ AC_CHECK_FUNCS(m4_normalize([
kqueue
localeconv_l
mbstowcs_l
+ memset_explicit
posix_fallocate
ppoll
Could we hit the same kind of issue as in [1]/messages/by-id/CAA4pTnLcKGG78xeOjiBr5yS7ZeE-Rh=FaFQQGOO=nPzA1L8yEA@mail.gmail.com (when using -std=c11)?
Asking because I can see (in [2]https://sourceware.org/git/?p=glibc.git;a=blob;f=string/string.h;hb=glibc-2.43), that in glibc 2.43, memset_explicit is guarded
that way (string/string.h):
"
#if defined __USE_MISC || __GLIBC_USE (ISOC23)
/* Like memset, but the compiler will not delete a call to this
function, even if S is dead after the call. */
extern void *memset_explicit (void *__s, int __c, size_t __n)
__THROW __nonnull ((1)) __fortified_attr_access (__write_only__, 1, 3);
#endif
"
Should we move from AC_CHECK_FUNCS to AC_CHECK_DECLS? (same kind of idea as
12eee85e511f)?
[1]: /messages/by-id/CAA4pTnLcKGG78xeOjiBr5yS7ZeE-Rh=FaFQQGOO=nPzA1L8yEA@mail.gmail.com
[2]: https://sourceware.org/git/?p=glibc.git;a=blob;f=string/string.h;hb=glibc-2.43
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Mon, Feb 23, 2026 at 03:22:22PM +0000, Bertrand Drouvot wrote:
Could we hit the same kind of issue as in [1] (when using -std=c11)?
Asking because I can see (in [2]), that in glibc 2.43, memset_explicit is guarded
that way (string/string.h):"
#if defined __USE_MISC || __GLIBC_USE (ISOC23)
/* Like memset, but the compiler will not delete a call to this
function, even if S is dead after the call. */
extern void *memset_explicit (void *__s, int __c, size_t __n)
__THROW __nonnull ((1)) __fortified_attr_access (__write_only__, 1, 3);
#endif
"
I did more research on it and that seems to work with -std=c11. While
-std=c11 does not define __USE_MISC, the fact that we add -D_GNU_SOURCE by
default enables __USE_MISC.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 24.02.26 06:59, Bertrand Drouvot wrote:
Hi,
On Mon, Feb 23, 2026 at 03:22:22PM +0000, Bertrand Drouvot wrote:
Could we hit the same kind of issue as in [1] (when using -std=c11)?
Asking because I can see (in [2]), that in glibc 2.43, memset_explicit is guarded
that way (string/string.h):"
#if defined __USE_MISC || __GLIBC_USE (ISOC23)
/* Like memset, but the compiler will not delete a call to this
function, even if S is dead after the call. */
extern void *memset_explicit (void *__s, int __c, size_t __n)
__THROW __nonnull ((1)) __fortified_attr_access (__write_only__, 1, 3);
#endif
"I did more research on it and that seems to work with -std=c11. While
-std=c11 does not define __USE_MISC, the fact that we add -D_GNU_SOURCE by
default enables __USE_MISC.
Yeah, using _GNU_SOURCE makes almost everything available. Otherwise,
we should be using AC_CHECK_DECLS for everything. Which might in
principle be right, but it's a separate project.
The difference with memset_s() is that we don't make
__STDC_WANT_LIB_EXT1__ universally enabled.
On 24.02.26 17:02, Peter Eisentraut wrote:
On 24.02.26 06:59, Bertrand Drouvot wrote:
Hi,
On Mon, Feb 23, 2026 at 03:22:22PM +0000, Bertrand Drouvot wrote:
Could we hit the same kind of issue as in [1] (when using -std=c11)?
Asking because I can see (in [2]), that in glibc 2.43,
memset_explicit is guarded
that way (string/string.h):"
#if defined __USE_MISC || __GLIBC_USE (ISOC23)
/* Like memset, but the compiler will not delete a call to this
function, even if S is dead after the call. */
extern void *memset_explicit (void *__s, int __c, size_t __n)
__THROW __nonnull ((1)) __fortified_attr_access
(__write_only__, 1, 3);
#endif
"I did more research on it and that seems to work with -std=c11. While
-std=c11 does not define __USE_MISC, the fact that we add -
D_GNU_SOURCE by
default enables __USE_MISC.Yeah, using _GNU_SOURCE makes almost everything available. Otherwise,
we should be using AC_CHECK_DECLS for everything. Which might in
principle be right, but it's a separate project.The difference with memset_s() is that we don't make
__STDC_WANT_LIB_EXT1__ universally enabled.
I have committed this.