On 5/7/25 02:04, Walter Bright wrote:
> 
> Having the program stop when it enters an invalid state is a good thing, not a bad thing.

It seems you have been the one who wants `-release` to be used. While that will cause invalid instruction errors sometimes, it will also disable other checks that would detect an invalid state. This goes as far as disabling bounds checks so memory can get corrupted without the program stopping. x)

On 07/05/2025 12:04 PM, Walter Bright wrote:
> On 5/6/2025 1:53 AM, Richard (Rikki) Andrew Cattermole wrote:
>> This is why its so important to switch over to calling the global functions like assert handler does.
> 
> You cannot know if the global function is corrupted or not at that stage.
> 
> A bad actor can also hijack that global function to facilitate his nefarious schemes.

Which is no different than a signal.

Or our existing assert handler.

>> People can configure it to do whatever they want, we don't have to have a default that is anything but instant crash.
> 
> It's not an instant crash. It generates an invalid instruction fault, which then goes to a handler for it, and the default behavior of that handler is to terminate the process.
> 
> I can tell I'm the oldest person here. I programmed for many years on a machine that had no concept of a fault. When your program crashed, it didn't stop. It kept running. It would execute data as instructions. Invalid opcodes would execute random snippets of microcode. It would run wild. Usually the only way to get control back is to do a cold boot. Now *that* is a crash.
> 
> Having the program stop when it enters an invalid state is a good thing, not a bad thing.
> 
> If you want to keep a program running on your customer's machine after it crashes, that is entirely up to you. But I cannot recommend it.

Right, which is why everything I've said aligns with it defaulting to crashing out with a call to a function.

Even Windows supports logging in process on a crash. In practice this does work every day right now, running on your computer.

On Tuesday, 6 May 2025 at 23:51:05 UTC, Walter Bright wrote:

> 2. if in invalid state, shut down immediately

There's one case where D blatantly violates this principle. Consider a system with allowed state transitions A->B, B->C, C->B, B->A:

```
enum State
{
    A, B, C
}

State state;

void AtoB()
{
    assert(state == State.A);
    state = State.B;
}

void BtoC()
{
    assert(state == State.B);
    state = State.C;
}

void CtoB()
{
    assert(state == State.C);
    throw new Exception("CtoB failed"); // or an Error, doesn't matter
    state = State.B;
}

void BtoA()
{
    assert(state == state.B);
    state = State.A;
}

void main()
{
    AtoB();
    scope(exit)
        BtoA(); // relies on the downstream handler having completed successfully.

    BtoC();
    scope(exit)
        CtoB(); // this handler runs, even though the program is in an invalid state.
}
```

On Wednesday, 7 May 2025 at 07:42:06 UTC, Max Samukha wrote:

>         CtoB(); // this handler runs, even though the program

Misplaced comment. It's the upstream handler (BtoA) that must not run.

Let's break it down:

```
void main() { assert(0); }
```
Compile with -vasm:
```
0000:   55                       push      RBP
0001:   48 8B EC                 mov       RBP,RSP
0004:   BE 01 00 00 00           mov       ESI,1
0009:   BF 00 00 00 00           mov       EDI,0
000e:   E8 00 00 00 00           call      L0
0013:   31 C0                    xor       EAX,EAX
0015:   5D                       pop       RBP
0016:   C3                       ret
```
The `call L0` is the call to the assert failure function.

Compile with -vasm -release:
```
0000:   0F 0B                    ud2
0002:   C3                       ret
```
The `ud2` is the illegal instruction.

Compile with -vasm -release -checkaction=D:
```
0000:   0F 0B                    ud2
0002:   C3                       ret
```
So what's going on here? First, `-release` turns off all the checking. The `assert(0)` means this code should never be reached. But something has to be inserted there, so the compiler emits the `ud2`.

It seems to me that if the `assert(0)` has a message, say `assert(0,"kilroy was here")`, the checkaction should govern what happens. I'll make that change.

----

I said that -release turns off the checks. Let's turn them on:

Compile with `-vasm -release -check=on`:
```
0000:   55                       push      RBP
0001:   48 8B EC                 mov       RBP,RSP
0004:   BE 01 00 00 00           mov       ESI,1
0009:   BF 00 00 00 00           mov       EDI,0
000e:   E8 00 00 00 00           call      L0
0013:   31 C0                    xor       EAX,EAX
0015:   5D                       pop       RBP
0016:   C3                       ret
```
Next, there's druntime being compiled with `-release`. What does that mean for the array bounds check:
```
void main(){
     int[2] x=[0,1];
     auto y=x[1..2];
     x[]=y[];
}
```
Compile with -vasm -release -check=on
```
core.exception.RangeError@x.d(4): Range violation
----------------
??:? [0x40cc4c]
??:? [0x41da17]
??:? [0x40cba5]
??:? [0x41504d]
??:? [0x414fe5]
??:? [0x4070b1]
??:? [0x404f02]
??:? [0x403511]
??:? [0x403487]
??:? [0x4039ce]
??:? [0x40387d]
??:? [0x403956]
??:? [0x40387d]
??:? [0x4037e6]
??:? [0x4035cf]
??:? [0x4034b1]
??:? __libc_start_main [0x7f9b1b129f44]
??:? [0x403368]
```
Compile with -g:
```
core.exception.RangeError@x.d(4): Range violation
----------------
??:? [0x40cc64]
??:? [0x41da2f]
??:? [0x40cbbd]
??:? [0x415065]
??:? [0x414ffd]
??:? [0x4070c9]
??:? [0x404f1a]
??:? [0x403529]
./x.d:4 [0x40348b]
??:? [0x4039e6]
??:? [0x403895]
??:? [0x40396e]
??:? [0x403895]
??:? [0x4037fe]
??:? [0x4035e7]
/home/walter/forks/dmd/druntime/src/core/internal/entrypoint.d:29 [0x4034c7]
??:? __libc_start_main [0x7f310c464f44]
??:? [0x403368]
```
and you get the location of the error.