Thread
Commits
-
Check for memset_explicit() and explicit_memset()
- 386ca3908de2 19 (unreleased) landed
-
Check for memset_explicit() and explicit_memset()
Peter Eisentraut <peter@eisentraut.org> — 2026-02-23T07:12:41Z
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.
-
Re: Check for memset_explicit() and explicit_memset()
Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-02-23T15:22:22Z
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] (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 " Should we move from AC_CHECK_FUNCS to AC_CHECK_DECLS? (same kind of idea as 12eee85e511f)? [1]: https://postgr.es/m/CAA4pTnLcKGG78xeOjiBr5yS7ZeE-Rh%3DFaFQQGOO%3DnPzA1L8yEA%40mail.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 -
Re: Check for memset_explicit() and explicit_memset()
Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-02-24T05:59:36Z
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
-
Re: Check for memset_explicit() and explicit_memset()
Peter Eisentraut <peter@eisentraut.org> — 2026-02-24T16:02:07Z
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.
-
Re: Check for memset_explicit() and explicit_memset()
Peter Eisentraut <peter@eisentraut.org> — 2026-03-02T07:27:15Z
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.