On 02/05/2024 19.34, Jonathan Wakely wrote:
>
>
> On Thu, 2 May 2024 at 18:29, Jonathan Wakely <cxx_at_[hidden] <mailto:cxx_at_[hidden]>> wrote:
>
>
>
> On Thu, 2 May 2024 at 18:11, Jens Maurer <jens.maurer_at_[hidden] <mailto:jens.maurer_at_[hidden]>> wrote:
>
>
>
> On 26/01/2024 13.29, Jonathan Wakely via Liaison wrote:
> > - memset_explicit
> > I assume we want this.
>
> I can't see how to specify these effects in the C++ abstract machine.
> If your array goes out-of-scope after the memset, there's no way to
> normatively prevent the dead-store elimination.
>
>
> What about defining it in terms of writes to volatile objects?
>
>
> That isn't even a terrible abuse of volatile semantics, because the observable side effects of writing to that memory really do matter.

We can do writes through volatile glvalues, i.e. something like

  *(volatile char *)p = value;

to cause observable behavior ([intro.abstract] p7), but if the array goes
out-of-scope afterwards, then the compiler is free to execute this code
and then memcpy the old contents back (that was saved earlier).
That would be a conforming implementation, recommendations notwithstanding.

Regarding the question of the compiler storing stuff also elsewhere:
I think Richard Smith said he doesn't know how to implement the purpose
of this function within the confines of the LLVM IR, precisely because
he can't be sure the data doesn't escape.

> The entire purpose is to ensure that any secrets in those memory locations are not visible if there are reads that happen outside the abstract machine (e.g. reading those bytes after the object has gone out of scope, because exploit code doesn't care about our stinking "rules" and whether such reads would be undefined).

I understand the purpose.

> Volatile semantics seem quite appropriate for writes that are non-elidable side effects and reads that happen outside the abstract machine.

Except there aren't really any volatile objects there, just (one-shot) volatile writes.

Jens