Not that I will disagree with wanting just one way of reporting this, and not allowing optional behavior, but isn't there a valid use case for recoverable access exceptions?

That's how copy-on-write works.

 Is that no longer used, or is it done a different way on modern systems and I'm showing my age? 

On Fri, Feb 26, 2021 at 10:54 AM Richard Trauben <rtrauben@...> wrote:

Hi All,

In my opinion, we will not recover from a malformed pte, so Violation (INSTEAD of fault) seems more appropriate.

Richard

On Fri, Feb 26, 2021 at 10:48 AM swallach <steven.wallach@...> wrote:

here is my 2cents

a fault is an action  that can be recovered from and processing continue (eg page fault)

and access violation is something,  then in general you can NOT recover from

i will defer to others to pick/chose the appropriate term.  but there should be a distinction  imho

—————————————————————————————————————————————————————————

On 2/26/2021 10:42 AM, Jonathan Behrens wrote:

Could you clarify what concern would be addressed by specifying that using
those reserved bits cause a specific trap?

It would just seem to be an unnecessary degree of freedom in the spec.

Now, for example, the Sail model would have to presumably be
parameterized for which fault should be returned in this situation,
for no apparent benefit (other than maintaining backwards compatibility
with implementations that already do both).

The architecture test case for this situation would now have two valid
signatures instead of one, and Allen has been commenting for a while
how that would require big changes in the architecture testing framework.

If software is using "try setting it and see if it traps" as a
discovery mechanism, now that software is more complicated because it
needs to handle either type of fault there.

...etc.  I expect this type of issue will be more noticeable now that
we're proposing to start actually using these bits.

Dan

WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer