On Wednesday, 2 July 2025 at 08:11:44 UTC, Walter Bright wrote:
> On 6/30/2025 2:18 PM, Sebastiaan Koppe wrote:
>> Just know that the idea of exiting directly when something asserts on the pretense that continueing makes things worse breaks down in multi-threaded programs.
>
> An assert tripping means that you've got a bug in the program, and the program has entered an unanticipated, unknown state.

This program

   void main ()
   {
      assert (false);
   }

is a valid D program which is free of bugs and without any
"unanticipated, unknown" state.

Do you agree?

On Wednesday, 2 July 2025 at 16:51:40 UTC, kdevel wrote:
> On Wednesday, 2 July 2025 at 08:11:44 UTC, Walter Bright wrote:
>> On 6/30/2025 2:18 PM, Sebastiaan Koppe wrote:
>>> Just know that the idea of exiting directly when something asserts on the pretense that continueing makes things worse breaks down in multi-threaded programs.
>>
>> An assert tripping means that you've got a bug in the program, and the program has entered an unanticipated, unknown state.
>
> This program
>
>    void main ()
>    {
>       assert (false);
>    }
>
> is a valid D program which is free of bugs and without any
> "unanticipated, unknown" state.
>
> Do you agree?

Nah, clearly this wouldnt pass boeings standards

On 7/2/2025 5:37 AM, Adam D. Ruppe wrote:
> I keep hearing that asserts and Errors and whatnot only happen when the program has encountered a bug,

Using asserts for anything other than detecting a programming bug in the code is using the wrong tool. Asserts are not recoverable.


> but it is worth nothing they tend to happen *just before* a task actually executes the problematic condition. Sure, you weren't supposed to even get to this point, but you can still reason about the likely extent of the mystery

If a variable has an out of bounds value in it, it cannot be determined why it is out of bounds. It may very well be out of bounds because of memory corruption elsewhere due to some other bug or a malware attack.


> and rollback to that point... which is what stack unwinding achieves.

Stack unwinding may be just what the malware needs to install itself. The stack may be corrupt, which is why Error does not guarantee running destructors on the stack.


> This is why OpenD tries to make sure that stack unwinding actually works - it will call destructors as it goes up, since this is part of rolling back unfinished business and limiting the damage.

Limiting the damage from a program being in an unknown and corrupted state is only achieved by limiting the code being executed to possibly logging the error and exiting the program. Nothing else.

`enforce` https://dlang.org/phobos/std_exception.html#enforce is a soft assert for errors that are recoverable.

On Wednesday, 2 July 2025 at 23:26:36 UTC, Walter Bright wrote:
> If a variable has an out of bounds value in it, it cannot be determined why it is out of bounds. It may very well be out of bounds because of memory corruption elsewhere due to some other bug or a malware attack.
>
>
>> and rollback to that point... which is what stack unwinding achieves.
>
> Stack unwinding may be just what the malware needs to install itself. The stack may be corrupt, which is why Error does not guarantee running destructors on the stack.

This argument is, in practice, a Slippery Slope fallacy and thus can be dismissed without further consideration.

But because this is the NG's we will consider it further anyways.

Yes, malware could theoretically use the stack unwinding to inject further malware. But doing so would require Administrative level local access and if the malware has that level of access, then you have far bigger problems to occupy yourself with. Furthermore, I, and GROK, are not aware of any actual attacks exploiting stack unwinding in the wild.

So your malware case is purely theoretical at this point in time.

And yes, the stack may be corrupt ... so what? I'll still know more than I get from a terse termination message. There is no rational argument that can be made that intentionally reducing error reporting data is ever a good idea. Even corrupt data tells me something that a terse termination method cannot.

Finally, we don't live in the 80's anymore. Most of my code lives on servers located in data centers hundreds of miles away from where I live and is guarded by dudes with guns. If I show up to the DC to try to debug my program on their servers I'll end up in jail. Or worse.

It is an absolute non-negotiable business requirement that I be able to get debugging information out of the server without physical access to the device. If you won't deliver the logging data, corrupted or not, on an assert, then no business can justify using D in production. It's that simple.

On Thursday, 3 July 2025 at 07:21:09 UTC, Adam Wilson wrote:
> This argument is, in practice, a Slippery Slope fallacy and thus can be dismissed without further consideration.

Ok, technically it's a Reification fallacy with an implied Slippery Slope.

Still, it's not an argument of logic or reason.

On 03/07/2025 11:26 AM, Walter Bright wrote:
>     and rollback to that point... which is what stack unwinding achieves.
> 
> Stack unwinding may be just what the malware needs to install itself. The stack may be corrupt, which is why Error does not guarantee running destructors on the stack.

I've been looking into this and I am failing to see this as a risk.

Here is why:

1. Due to MMU's which we all love, you can't jump to some random address and execute. The execute flag isn't set, and setting it is a complex bit of a function call. To do in sequence with a write. Extremely unlikely, to the point that we can consider this one solved. A JIT will typically set as writable, write then reflag as readable+executable without executable prior jumping. So the likelihood of write + execute on ANY memory in a process is basically zero.

2. MSVC has the /GS flag to enable protections against injections from corrupting the stack itself. So does LLVM although we don't enable them (ssp) https://llvm.org/docs/LangRef.html#function-attributes

3. According to Microsoft MSVC has had mitigations in place since XP for all these issues. https://msrc.microsoft.com/blog/2013/10/software-defense-mitigating-stack-corruption-vulnerabilties/

4. Microsoft are so certain that this is solved, they legally REQUIRE that you can handle all errors in a process to publish on the Microsoft App Store. "The product must handle exceptions raised by any of the managed or native system APIs and remain responsive to user input after the exception is handled." https://learn.microsoft.com/en-us/windows/apps/publish/store-policies#104-usability

What I am missing here is any evidence that shows the use of stack corruption, or stack unwinding cannot be mitigated with code gen or is inherent in our existing execution environment.

Do you have any evidence that would help inform opinions on these topics that is current?

On Thursday, 3 July 2025 at 07:21:09 UTC, Adam Wilson wrote:
> then no business can justify using D in production. It's that simple.

And this is already true (except couple of outliers that just prove the main rule) :)

A couple of us have gone and asked both Gemini and Grok what they think of this: "Are there any currently known malware or attacks that use stack unwinding as an attack vector?"

Gemini unsurprisingly gave the best answer.

It is based upon the paper "Let Me Unwind That For You: Exceptions to
Backward-Edge Protection": https://www.ndss-symposium.org/wp-content/uploads/2023/02/ndss2023_s295_paper.pdf

The premise is you must be able to overwrite stack data (this is solved in D between @safe and bounds checking). Then throw ANY exception. It does not have to be an Error, it can be an Exception.

Before all that occurs you need some code to execute. This requires you to bypass things like ASLR and CET. And know enough about the program to identify that there is code that you could execute.

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.

Need more evidence to suggest that Error shouldn't offer cleanup. Right now I have none.

On Thursday, 3 July 2025 at 08:25:42 UTC, Richard (Rikki) Andrew Cattermole wrote:
> A couple of us have gone and asked both Gemini and Grok what they think of this: "Are there any currently known malware or attacks that use stack unwinding as an attack vector?"
>
> Gemini unsurprisingly gave the best answer.
>
> It is based upon the paper "Let Me Unwind That For You: Exceptions to
> Backward-Edge Protection": https://www.ndss-symposium.org/wp-content/uploads/2023/02/ndss2023_s295_paper.pdf
>

I want to state for the record, that what Rikki is saying here is that because Walter's proffered example attack would work on *any* stack unwinding mechanism, then the correct solution to Walter's proposed attack is to remove *ALL* stack unwinding from the language.

Which I will assert is a terminally bad idea.

Therefore, since there is no functional difference in threats between Errors and Exceptions, then Error should offer the same unwinding facilities as well.

On Thursday, 3 July 2025 at 07:21:09 UTC, Adam Wilson wrote:

> Finally, we don't live in the 80's anymore. Most of my code lives on servers located in data centers hundreds of miles away from where I live and is guarded by dudes with guns. If I show up to the DC to try to debug my program on their servers I'll end up in jail. Or worse.
>
> It is an absolute non-negotiable business requirement that I be able to get debugging information out of the server without physical access to the device. If you won't deliver the logging data, corrupted or not, on an assert, then no business can justify using D in production. It's that simple.

What's preventing you to have debugging information in remote server environment without  physical access the device?

We are not in the 80 anymore, but even in the 80 ...

/P