Program crash: GC destroys an object unexpectedly

[jfondren]

On Thursday, 23 September 2021 at 13:30:42 UTC, eugene wrote:
> So, in C it is MY (potentially wrong) code.
> In D, it is NOT MY code, it is GC.

Actually in both cases it is MY+the compiler's code. A very 
similar example from C-land (without my digging up the exact 
details) is something like

```c
for (int i = 0; i >= 0; i++) {
   // exit loop on signed integer overflow
}
```

where gcc 2.95 would do what "MY code" said, but later gcc 
versions would 'optimize' into an infinite loop (followed by dead 
code that can now be removed):

```c
for (;;) {
   // never exit loop
}
```

Because in math, positive numbers never +1 into negative numbers. 
And in C this is undefined behavior which is (modern 
understanding:) complete license for the compiler to do anything 
at all. And on the specific architecture we are specifically 
compiling for there is specific behavior--but who cares about 
that, this is optimization! And if you complained about it, well 
you were a sloppy coder actually, for wanting the target 
architecture's actual behavior with your actual code as you 
actually wrote it. (If you feel like defending C's honor here, 
please, I've heard it already. Everybody thinks very highly of 
the nasal demons joke.)

There are other cases where very security-minded software had 
defensive code that an optimizer decided would never be needed, 
that then exposed a software vulnerability, or there are 
'unnecessary' writes that are intended to remove a password from 
memory:

https://duckduckgo.com/?q=dead+code+elimination+security+vulnerability