Re: Check for memset_explicit() and explicit_memset()
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-02-24T16:02:07Z
Lists: pgsql-hackers
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.
Commits
-
Check for memset_explicit() and explicit_memset()
- 386ca3908de2 19 (unreleased) landed