RFC: Change what assert does on error

[Richard (Rikki) Andrew Cattermole]

On 04/07/2025 7:24 PM, Walter Bright wrote:
> On 7/3/2025 1:25 AM, Richard (Rikki) Andrew Cattermole wrote:
>>>  From what I can tell this kind of attack is unlikely in D even 
>>> without the 
>> codegen protection. So once again, the Error class hierarchy offers no 
>> protection from this kind of attack.
> 
> The paper says that exception unwinding of the stack is still vulnerable 
> to malware attack.
> 
> 
>> Need more evidence to suggest that Error shouldn't offer cleanup. 
>> Right now I have none.
> 
> Because:
> 
> 1. there is no purpose to the cleanup as the process is to be terminated

A task has to be terminated, that doesn't have to be the process.

Logging still requires the stack to be in a good state that isn't being 
clobbered over. That can and will produce data corruption.

You need to clean things up like sockets appropriately. They can have 
side effects on computers on the other side of the planet that isn't 
just data is corrupt, it could be worse. They are not always accessible 
in every part of the program. GC may need to run ext.

> 2. code that is not executed is not vulnerable to attack

Sounds good, no more catching of Throwable at any point in programs.

Shall we tell people that unwinding exceptions are hereby recommended 
against in D code, and that we will be replacing them with a different 
solution?

Unless we are prepared to rip out unwinding, D program will be 
vulnerable to these kinds of attacks (even though the probability is low).

> 3. the more code that is executed after the program entered unknown and 
> unanticipated territory, the more likely it will corrupt something that 
> matters
> 
> Do you really want cleanup code to be updating your data files after the 
> program has corrupted its data structures?

Hang on:

- Executing the same control path after a bad event happens.

- Executing a different control path to prevent a bad event.

Are two very different things.

I do not want the first that has long since shown itself to be a lost 
cause, but the second works fine in other language and people are 
relying on this behavior. So what is so special about D that we should 
inhibit entire problem domains from using D appropriately?

> ---
> 
> This whole discussion seems pointless anyway. If you want to unwind the 
> exception stack every time, use enforce(), not assert(). That's what 
> it's for.

The current situation of not having a solution for when people need 
Error to be recoverable is creating problems, rather than solving them.

You can't "swap out" Error for Exception due to nothrow and druntime not 
having the ability to do it.

Error has to change, the codegen of nothrow has to change, there is 
nothing else for it.

Does it have to be the default? Not initially, it can prove itself 
before any default changes. We'll talk about that at the monthly meeting.