[lmm]

How do you know? One of the reasons they're so insidious is that code that hits them tends to work fine until it gets compiled with a newer version of the compiler. E.g. signed integer overflow did exactly what you expect in most compilers until fairly recently.

[steerablesafe]

> E.g. signed integer overflow did exactly what you expect in most compilers until fairly recently.

How recently? Both gcc 4.1.2 (2007) and clang 3.0.0 (2011) optimizes `x+1 > x` to true for a signed int `x` on -O1. And it probably goes way back, these are just the oldest compilers I found on godbolt.

https://c.godbolt.org/z/sdd15c

[lmm]

Ah, point taken, but that's within the bounds of what many people expect; propagating the fact that the overflow is "impossible" to rearrange earlier control flow is more surprising and more recent.

[steerablesafe]

> Ah, point taken, but that's within the bounds of what many people expect;

The thing is it's very hard to draw the line once you go that route. Different people expect different things from undefined behavior. The best thing is to not expect anything sane. And if you are unhappy about certain undefined behaviors in the standard then it's better to push the standard to define more behavior. Certain unnecessary undefined behaviors get resolved with newer standards, although I would expect significant pushback on defining the behavior signed integer overflow.

[lmm]

I understand there's a good chance the next standard will specify that signed integer overflow results in an unspecified value, which would match the behaviour of older compilers and what (IME) most programmers tend to expect.

[steerablesafe]

> I understand there's a good chance the next standard will specify that signed integer overflow results in an unspecified value

Do you have a source for this?

[lmm]

It was linked from a discussion on HN but I didn't record where.

[rightbyte]

Ye that is true. C compilers got some strange gotchas that you need to memorize but my main point is that those problems atleast to my projects are miniscule compared to off by one out of bound array access or dereferencing null pointers.

[MaxBarraclough]

I agree with you here, but even these two categories of runtime errors are much more painful in C/C++ than in most other languages.

As I mentioned elsewhere in the thread, you can ask gcc to trap if your code is about to dereference NULL, but the compiler can't easily detect all instances of out-of-bounds array access, due to the way arrays and pointers work in C. I believe Valgrind can help detect out-of-bounds errors at runtime, but in most languages you don't need a sledgehammer like Valgrind to find these common errors.