RFC: Change what assert does on error

[Richard (Rikki) Andrew Cattermole]

On 04/07/2025 6:58 PM, Walter Bright wrote:
> Malware continues to be a problem. I wound up with two on my system last 
> week. Ransomware seems to be rather popular. How does it get on a system?

Step 1. Run outdated and insecure software.

For instance Windows 7.

I cannot remember the last time I had malware on my computer. The built 
in anti-virus is good enough on Windows. Staying fairly up to date is 
enough to combat any potential attacks in modern operating systems due 
to the automatic and frequent updates.

Ransomware generally requires people to disable OS protections on 
Windows, or for that specific virus to have never before been used. When 
you hear postmortems of them they typically have "variant of" in its 
description, as this is how they get around anti-virus.

Anti-virus today is quite sophisticated, they can analyze call stack 
patterns. I don't know how prevalent it is however, but it does exist.

> I don't share your confidence. Malware authors seem to be very, very 
> good at finding exploits.

Yes, they are very good at reading security advisories and then applying 
an attack based upon what is written.

Turns out lots of people have out dated software, so even if a bug has 
been fixed, its still got a lot of potential benefit for them.

So many web apps get taken over specifically because of this.

I found one website here in NZ that was exactly this. Out of date 
software ~10 years old, with security advisories and would have been 
really easy to get in if I wanted to. And that was pure chance.
It was advertised on TV at some point...

> Besides, a bug in a program can still corrupt the data, causing the 
> program to do unpredictable things. Do you really want your trading 
> software suddenly deciding to sell stock for a penny each? Or your 
> pacemaker to suddenly behave erratically? Or your avionics to suddenly 
> do a hard over? Or corrupt your data files?

An Error is thrown in an event where local information alone cannot 
inform the continuation of the rest of the program.

Given this we know that a given call stack cannot proceed, it must do 
what it can to roll back transactions to prevent corruption of outside 
data. Leaving them half way could cause corruption too. A good example 
of this is the Windows USB drive support.

To give an example of this relevant to D; for an application shipped by 
Microsoft's App store.

It must have the ability to keep the GUI open and responsive even after 
the error has occurred. It must if it can't handle it automatically, 
inform the user that a program ending event has occurred and allow that 
user to close the program in their own time.

You are not allowed to call abort or exit in this situation. It is 
illegal as per the contract you sign. Do I think they should have added 
this? No. But it is there and yet C++ can handle this but we can't.

> If you knew what the bug is that caused an assert to trip, why didn't 
> you fix it beforehand?

Q: How do you know that the the bug was fixed and won't reappear?

A: You write an assert.

Q: How do you know that your assumptions are correct about code that you 
didn't write or haven't reevaluated and is quite complex?

A: You write an assert.

In a perfect world we'd throw proof assistants at programs and say they 
have no bugs ever. But the real world is the opposite, quick changes and 
rarely tested thoroughly enough to say it won't trip.