Hello Joshua,

on Tue, 30 May 2023 22:12:49 +0000 you ("Cranmer, Joshua via Liaison"
<liaison_at_[hidden]>) wrote:

> As a more minor naming issue, I'm not entirely satisfied with the
> name "fault" for the issue here,

yes, this was just the first that came to my mind and that was not yet
highly connotated in the context of the standard. If you have another
idea for a term, that would be great.

> since it strikes me as something that would tend to imply it's the
> point of a hardware trap,

what I would like to have is something that clearly identifies this as
a point in time (in the sense of happens-before) where things go
wrong. We should distinguish "the things that made that the program
went wrong" from the "the crap that a faulty system might do after
things went wrong".

> whereas the "fault" associated with producing a poison value can
> occur at some distance from the actual trap, and we absolutely want
> to have the weird effects of UB kick in after the "fault" but before
> the trap.

I am not much in favor (nor do I really understand) these models of
program failure that somehow delay the faulty read of an inapropriate
value to the point where this value is actually used. I still don't
understand what that brings other than trouble.

Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::