2 ms·

Stuff like this sounds great but if you dig into the details of actually trying to implement it, it's not at all simple, and it would inevitably slow down the a

by TillE 3y ago

Stuff like this sounds great but if you dig into the details of actually trying to implement it, it's not at all simple, and it would inevitably slow down the already-terrible compilation speed of C++. We have static analysis tools which do a decent job. But like, there's a reason Clang has UBSan to detect undefined behavior at runtime. It's a hard problem.

kelnos 3y ago
Not really, at least for two of the three examples mentioned. Failing compilation on an uninitialized variable is easy. The compiler can already warn about this situation (and gcc and clang at least allow you to promote individual warnings to errors). Making this default would be simple, and not at all a performance concern. Allowing signed arithmetic to overflow (in a defined 2's complement manner) would be just exactly what the hardware does on modern machines, so there'd be no slowdown there. Sure, the compiler would no longer be allowed to omit code that checks for overflow, but that's fine: if the programmer truly doesn't care, they won't write that check in the first place. (Changing these two behaviors might have backward-compatibility concerns, though.) You are of course correct that NULL dereference checking is would incur a performance penalty at runtime. However, the compiler should be able to catch some subset of cases at compile time. At the very least, there could be a mode where it could at least warn you at compile-time that some dereferences could result in SIGSEGV. Unfortunately, I think it would be hard to get that warning to a point where there weren't a lot of false positives, so such a warning would be routinely ignored to the point of uselessness.
- agwa 3y ago
  > You are of course correct that NULL dereference checking is would incur a performance penalty at runtime. However, the compiler should be able to catch some subset of cases at compile time. At the very least, there could be a mode where it could at least warn you at compile-time that some dereferences could result in SIGSEGV. SIGSEGV on null pointer deference is not the problem. It's actually fine, in the sense that it predictably terminates the program. The problem is that modern optimizing compilers don't guarantee that SIGSEGV will happen; they may rewrite your program to do insane shit instead, as the example in the blog post shows. So we don't need NULL checks at runtime; we just need the compiler to stop doing insane optimizations.
- lelanthran 3y ago
  > Failing compilation on an uninitialized variable is easy. On uninitialised variable, sure, but impossible to tell at compile time if the program is using an uninitialised value. Compiler authors also appear, to me, to be malicious. In the past, they worked hard to provide warnings when they detected uninitialised variables. In the rare case, now, that the compiler is able to tell that a line is using an uninitialised value, instead of issuing a warning, it simply removes the offending code altogether. If compiler authors now were more like compiler authors of the past, they'd value the user interface enough to make any and all dead code a compile error. Imagine if past compiler authors had their compiler, when seeing the use of an uninitialised variable, simply go ahead and remove any code that used that variable. Imagine how poor a user experience that would be considered, and then ask yourself why they feel it is okay now to simply remove dead code. There is no situation where actual source code lines should be removed rather than warned. Typing on phone so not going to go into all the data flow explanations.

by TillE 3y ago

kelnos 3y ago

Not really, at least for two of the three examples mentioned. Failing compilation on an uninitialized variable is easy. The compiler can already warn about this situation (and gcc and clang at least allow you to promote individual warnings to errors). Making this default would be simple, and not at all a performance concern. Allowing signed arithmetic to overflow (in a defined 2's complement manner) would be just exactly what the hardware does on modern machines, so there'd be no slowdown there. Sure, the compiler would no longer be allowed to omit code that checks for overflow, but that's fine: if the programmer truly doesn't care, they won't write that check in the first place. (Changing these two behaviors might have backward-compatibility concerns, though.) You are of course correct that NULL dereference checking is would incur a performance penalty at runtime. However, the compiler should be able to catch some subset of cases at compile time. At the very least, there could be a mode where it could at least warn you at compile-time that some dereferences could result in SIGSEGV. Unfortunately, I think it would be hard to get that warning to a point where there weren't a lot of false positives, so such a warning would be routinely ignored to the point of uselessness.

agwa 3y ago
> You are of course correct that NULL dereference checking is would incur a performance penalty at runtime. However, the compiler should be able to catch some subset of cases at compile time. At the very least, there could be a mode where it could at least warn you at compile-time that some dereferences could result in SIGSEGV. SIGSEGV on null pointer deference is not the problem. It's actually fine, in the sense that it predictably terminates the program. The problem is that modern optimizing compilers don't guarantee that SIGSEGV will happen; they may rewrite your program to do insane shit instead, as the example in the blog post shows. So we don't need NULL checks at runtime; we just need the compiler to stop doing insane optimizations.
lelanthran 3y ago
> Failing compilation on an uninitialized variable is easy. On uninitialised variable, sure, but impossible to tell at compile time if the program is using an uninitialised value. Compiler authors also appear, to me, to be malicious. In the past, they worked hard to provide warnings when they detected uninitialised variables. In the rare case, now, that the compiler is able to tell that a line is using an uninitialised value, instead of issuing a warning, it simply removes the offending code altogether. If compiler authors now were more like compiler authors of the past, they'd value the user interface enough to make any and all dead code a compile error. Imagine if past compiler authors had their compiler, when seeing the use of an uninitialised variable, simply go ahead and remove any code that used that variable. Imagine how poor a user experience that would be considered, and then ask yourself why they feel it is okay now to simply remove dead code. There is no situation where actual source code lines should be removed rather than warned. Typing on phone so not going to go into all the data flow explanations.