It seems to me that the question here really boils down to whether it makes
sense to have a function with the same normative semantics as memset(), but
different recommended practice. In my view, that seems OK.

I'm not sure the C wording here is perfect, in that this doesn't
necessarily really make prior information inaccessible to a root user. It
may still be in main memory and possibly swap space, since the store may
not propagate beyond the cache for a long time. But nonetheless, and in
spite of the fact that there seem to be no precise semantics, this seems to
be commonly requested functionality. Although imperfect, it does seem to be
useful in practice.

Hans


On Fri, May 3, 2024 at 8:59 AM aaron_ng#inode.at aaron_ng#inode.at via
Liaison <liaison_at_[hidden]> wrote:

>
>
> Ville Voutilainen via Liaison <liaison_at_[hidden]> hat am
> 02.05.2024 20:47 EEST geschrieben:
>
>
> On Thu, 2 May 2024 at 20:44, Martin Uecker via Liaison
> <liaison_at_[hidden]> wrote:
>
>
> The two problems we discussed for C were
>
> 1. even when we require those stores (I see no problem there),
> it is difficult to make sure that the information does not
> leak in a different way, e.g. because registers or other
> stack area are not cleared. WG14 was content with making the
> intent clear.
>
> We have Recommended Practice that we can use for the intent.
>
>
> 2. if there is UB afterwards then the extreme interpretation
> of UB (which WG14 later rejected) makes the complete program have
> no meaning.
>
> That's a separable problem (because we have a separate proposal for an
> optimization barrier),
> but if it's a volatile write, it's an optimization barrier because the
> volatile write is an observable effect.
> So I don't think this is a problem.
>
> At least in C volatile accesses are only ordered in respect to other
> volatile accesses.
>
> Regards, Aaron Peter Bachmann
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2024/05/1403.php
>