Re: Check for memset_explicit() and explicit_memset() - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Check for memset_explicit() and explicit_memset()
Date
Msg-id 79a2584f-8e79-464b-8606-a97cad500f80@eisentraut.org
Whole thread Raw
In response to Re: Check for memset_explicit() and explicit_memset()  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
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.




pgsql-hackers by date:

Previous
From: Blessy Thomas
Date:
Subject: Extension - multilingual_fuzzy_match : Multilingual phonetic matching extension for PostgreSQL
Next
From: Peter Eisentraut
Date:
Subject: Re: Unicode update and some tooling improvements