Re: Check for memset_explicit() and explicit_memset()

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Check for memset_explicit() and explicit_memset()
Date: 2026-02-24 16:02:07
Message-ID: 86b7c6b8-4f07-441a-9bf6-cbff1bb6d070@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-02-24 16:05:34 Re: Don't cast away const where possible
Previous Message Andrew Dunstan 2026-02-24 15:58:31 Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote