There's another aspect to the discussions: the word 'secure', which makes
people
uncomfortable due to the number of execution artefacts that can result from
computation
and be exploited even when target bits are actually cleared.

I don't think we can claim any more than "these bits will be cleared" with
such a
functionality, so we'll probably want to push for a more neutral name.
That, however,
should not prevent us (IMO) from working on the relevant aspects of the
abstract
machine (thanks JF for the reminder about p1382) since they seem important
for
other features as well as this one.



Le mer. 29 avr. 2020 à 19:30, JF Bastien <cxx_at_[hidden]> a écrit :

> On Wed, Apr 29, 2020 at 4:26 PM Patrice Roy <patricer_at_[hidden]> wrote:
>
>> The need for a mechanism to ensure some operations are actually
>> performed, under whatever name we use, seems clear to me and has
>> been a recurring topic over the years. The work done by JF on
>> deprecating some uses of volatile also show (if we needed this to
>> be shown) that volatile lacked love... and, more formally, that
>> it was not sufficiently specified.
>>
>> John Regehr has suggested in the past that, should be rethink
>> the volatile-related parts of the standard, one interesting avenue
>> could be to express volatile in terms of operations instead of
>> expressing them in terms of objects. If we took that path for
>> this mechanism (as was discussed in Cologne, from the paper
>> history; voting at 4 5 4 0 0 seems encouraging), we could start
>> to address the problems of adapting the abstract machine in terms
>> of a smaller subset of functions that impact the way we express
>> "as if", using some function that are not "as if" but have to be
>> taken literally by the compiler. This might localize the impact
>> of such changes to the sections where we discuss observable
>> behavior and fit in with std::observable.
>>
>> Should we invest efforts in re-expressing aspects of the abstract
>> machine that discuss volatile in terms of volatile loads and
>> stores, and build facilities such as p1315 and n4534 from there?
>>
>
> I believe we should: wg21.link/P1382
> Paul will likely need help on the wording aspects.
>
>
> Le mar. 28 avr. 2020 à 17:55, Jens Maurer via SG12 <sg12_at_[hidden]>
>> a écrit :
>>
>>> On 28/04/2020 23.21, Miguel Ojeda wrote:
>>> > # Jens Maurer
>>> >
>>> >> In order to solve these issues satisfactorily, we probably need a
>>> research effort approximately on the same level as improving our memory
>>> model for multi-threaded operations. This was a multi-year effort involving
>>> top-notch experts in the trade.
>>> >
>>> > Perhaps (I don't disagree with you on this, as you know), but the
>>> > multi-threaded memory model is a good example of how something can
>>> > work in practice, given programs using it were a thing decades before
>>> > the memory model was formalized into the standard. Of course, it was
>>> > not in the standard, but `memset_s` provides the example of something
>>> > useful in the standard without being fully formal yet.
>>>
>>> There's a bit of ambiguity here regarding the phrase "the standard".
>>> My understanding is we're talking about the C++ standard, but
>>> memset_s was never in that standard.
>>>
>>> Jens
>>> _______________________________________________
>>> SG12 mailing list
>>> SG12_at_[hidden]
>>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
>>> Link to this post: http://lists.isocpp.org/sg12/2020/04/0878.php
>>>
>>