missing memset_explicit()

[enh]

yeah, i think we'd all prefer a compiler builtin ... but in the
meantime the perfect is the enemy of the good.

(and there's none of us that doesn't already have the barrier trick in
existing code. and unlike me, iirc you folks like to support ancient
compilers anyway, so you're still going to need the barrier fallback
for the foreseeable future anyway :-) )

On Wed, Jun 4, 2025 at 4:15 PM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 04/06/25 16:31, Sam James wrote:
> > Cristian Rodríguez <cristian@rodriguez.im> writes:
> >
> >> On Wed, Jun 4, 2025 at 1:39 PM Adhemerval Zanella Netto
> >> <adhemerval.zanella@linaro.org> wrote:
> >>>
> >>>
> >>>
> >>> On 04/06/25 14:29, enh wrote:
> >>
> >>> I think we can implement this like explicit_bzero, where it would be
> >>> memset call plus the compiler barrier.
> >>
> >> Shouldn't this be a compiler builtin that the compiler promises
> >> *never* to remove or reorder under any circumstances?
> >
> > I think something explicit on the compiler side would be nice, I was
> > wondering this when looking into exactly this topic as someone asked me
> > about it last week. But copying explicit_bzero for now is I think fine.
>
> I recall we had a similar discussion for explicit_bzero and the compiler
> barrier was the best option back then.  Ideally I think the best course
> would be a builtin (__builtin_memset_explicit) where we have compiler
> guarantee that the call will never be elided.
>