Undefined behavior can cause perfectly functioning code in one compiler version to be completely elided in a different version, as we've seen numerous times in the past. Review the article and comments here[1] for a good example of exactly this and discussion about the how and why, but the TL;DR is that a specific optimization in a specific compiler release determined that the adding of two variables, one of which a pointer, would result in an overflow which is undefined for pointers, and thus elided the check to see if the result was less than should be possible (overflowed), and the entire error handling case it resulted in. This caused the value to be used while invalid (as the error check and handling was elided), causing a segfault.

Perhaps the features used in this project protect against that, but my point is that undefined behavior and the way compilers deal with it is variable and problematic.

1: https://news.ycombinator.com/item?id=14163111

It's definitely problematic, but so is having your interpreter completely redefine language constructs on every point release. Or having different interpreter implementations act differently because there's no standard.

Somehow we make do in these cases and don't act like the sky is falling.

> Somehow we make do in these cases and don't act like the sky is falling.

I think "there's enough edge cases and undefined behavior in the language that I take it as a fairly bold claim unless it's also been thoroughly reviewed for any places some undefined behavior may be induced" was me acting like the sky is falling. I think that's a very sane push back against a claim that I think either wasn't well founded or wasn't well explained.

Ultimately it's up to you to decide whether to accept I'm expressing what my words actually say or whether I'm expressing what you presented me as in your straw man argument you originally replied with. At this point, there's not much else I can or am willing to waste any more time saying that I haven't already.