5 ms·

Any instance of undefined behavior should result in a Warning, if not an Error. Similarly, 'dead code paths' should also result in a Warning, if not an Error.

Any instance of undefined behavior should result in a Warning, if not an Error. Similarly, 'dead code paths' should also result in a Warning, if not an Error. (Possibly with a way of turning that off for specific functions.) I also fully agree with the author's statement about what a good compiler should be doing.

millstone 7y ago
> Any instance of undefined behavior should result in a Warning, if not an Error How would you implement this? For example, use-after-free is undefined, and difficult to detect.
- vnorilo 7y ago
  Warning when optimization passes take advantage of UB is a reasonable desire. The compilers are getting increasingly good at this, but I believe it would be far too noisy to blanket enable all of that.
  - mjevans 7y ago
    The point is to push the info to the programmer so that the code can be re-written as only defined behavior. Yes this would eliminate the 'gains' of abusing UB, but it would actually fix the errors of abusing UB.
    - vnorilo 7y ago
      I guess signed indvars would be a prime example. Compilers famously ignore overflow of signed integers when computing loop trip counts. Would it be better to only ever use unsigned integers for indvars and loop limits? Maybe. But that would reach deep into the types in stdlib for example. And then there's https://software.intel.com/en-us/forums/intel-c-compiler/topic/698664 https://software.intel.com/en-us/forums/intel-c-compiler/top... So, all in all, not simple. Not that that invalidates your point: I just wanted to add some nuance.
    - marcan_42 7y ago
      The problem is the compiler cannot prove UB actually happens. The point of these "use UB to optimize" approaches isn't to screw over simple programs with bugs. It's to better optimize larger, correct programs where higher levels of logic that the compiler is unaware of ensure UB never happens.
- jcelerier 7y ago
  C++ is able to do it in constexpr contexts - a constexpr function cannot exhibit UB (else it's a compile error)
  - saagarjha 7y ago
    This is technically correct, but I believe this is also a very buggy area of the compiler and there are cases where it will accept undefined behavior in a constexpr context: https://shafik.github.io/c++/undefined%20behavior/2019/05/11/explporing_undefined_behavior_using_constexpr.html https://shafik.github.io/c++/undefined%20behavior/2019/05/11...
    - jcelerier 7y ago
      right, but all compilers / interpreters for all languages have bugs.
      - saagarjha 7y ago
        They do, but I'm just pointing out that trying to use constexpr as the judge of what is defined is generally not a great idea at the moment unless what you're actually trying to do is find some language-lawyer compiler bugs to file.
- pjmlp 7y ago
  Most static analyzers are already able to spot a big chunck of such cases, even if not everything, e.g. clang tidy and VC++ 2019 lifetime profile. Additionally, SPARC ADI, ARM MTE and CHERRY can be used to invalidate memory regions after free and trap on further accesses. While not perfect, better than nothing.
gpderetta 7y ago
> Any instance of undefined behavior should result in a Warning, if not an Error. Beyond trivial cases, UB is a runtime behaviour, not compile time. > 'dead code paths' should also result in a Warning, if not an Error. the noise generated would be unbearable.
- icedchai 7y ago
  Most of the UB people complain about is related to aggressive, compile time optimizations. This may or may not be trivial. Often it isn't, since decades old "working" code can be broken by new compilers. You can argue that the code was always broken, of course.
  - gpderetta 7y ago
    Yes, but the way these optimizations work, is not that they detect UB and optimize accordingly, instead they optimize assuming no UB. There is nothing to report at compile time.
sbmassey 7y ago
This would presumably include any pointer dereferences where the compiler cannot prove that the pointer is always non null.
bluGill 7y ago
There is good reasons compilers don't warn about most undefined behavior: there is so much might be but really isn't undefined behavior in the world. I often write code that won't divide by zero, something I can prove because I know my whole program while the compiler only knows the file/library it is working with at the moment. As such I didn't put in a if divisor is zero check, and now want the compiler to waste my time on a warning that is wrong.
throwaway2048 7y ago
this is a complete misunderstanding of what undefined behavior is, the compiler doesn't detect UB and then call emit_nasal_daemons().

millstone 7y ago

> Any instance of undefined behavior should result in a Warning, if not an Error How would you implement this? For example, use-after-free is undefined, and difficult to detect.

vnorilo 7y ago
Warning when optimization passes take advantage of UB is a reasonable desire. The compilers are getting increasingly good at this, but I believe it would be far too noisy to blanket enable all of that.
- mjevans 7y ago
  The point is to push the info to the programmer so that the code can be re-written as only defined behavior. Yes this would eliminate the 'gains' of abusing UB, but it would actually fix the errors of abusing UB.
  - vnorilo 7y ago
    I guess signed indvars would be a prime example. Compilers famously ignore overflow of signed integers when computing loop trip counts. Would it be better to only ever use unsigned integers for indvars and loop limits? Maybe. But that would reach deep into the types in stdlib for example. And then there's https://software.intel.com/en-us/forums/intel-c-compiler/topic/698664 https://software.intel.com/en-us/forums/intel-c-compiler/top... So, all in all, not simple. Not that that invalidates your point: I just wanted to add some nuance.
  - marcan_42 7y ago
    The problem is the compiler cannot prove UB actually happens. The point of these "use UB to optimize" approaches isn't to screw over simple programs with bugs. It's to better optimize larger, correct programs where higher levels of logic that the compiler is unaware of ensure UB never happens.
jcelerier 7y ago
C++ is able to do it in constexpr contexts - a constexpr function cannot exhibit UB (else it's a compile error)
- saagarjha 7y ago
  This is technically correct, but I believe this is also a very buggy area of the compiler and there are cases where it will accept undefined behavior in a constexpr context: https://shafik.github.io/c++/undefined%20behavior/2019/05/11/explporing_undefined_behavior_using_constexpr.html https://shafik.github.io/c++/undefined%20behavior/2019/05/11...
  - jcelerier 7y ago
    right, but all compilers / interpreters for all languages have bugs.
    - saagarjha 7y ago
      They do, but I'm just pointing out that trying to use constexpr as the judge of what is defined is generally not a great idea at the moment unless what you're actually trying to do is find some language-lawyer compiler bugs to file.
pjmlp 7y ago
Most static analyzers are already able to spot a big chunck of such cases, even if not everything, e.g. clang tidy and VC++ 2019 lifetime profile. Additionally, SPARC ADI, ARM MTE and CHERRY can be used to invalidate memory regions after free and trap on further accesses. While not perfect, better than nothing.

gpderetta 7y ago

> Any instance of undefined behavior should result in a Warning, if not an Error. Beyond trivial cases, UB is a runtime behaviour, not compile time. > 'dead code paths' should also result in a Warning, if not an Error. the noise generated would be unbearable.

icedchai 7y ago
Most of the UB people complain about is related to aggressive, compile time optimizations. This may or may not be trivial. Often it isn't, since decades old "working" code can be broken by new compilers. You can argue that the code was always broken, of course.
- gpderetta 7y ago
  Yes, but the way these optimizations work, is not that they detect UB and optimize accordingly, instead they optimize assuming no UB. There is nothing to report at compile time.

sbmassey 7y ago

This would presumably include any pointer dereferences where the compiler cannot prove that the pointer is always non null.

bluGill 7y ago

There is good reasons compilers don't warn about most undefined behavior: there is so much might be but really isn't undefined behavior in the world. I often write code that won't divide by zero, something I can prove because I know my whole program while the compiler only knows the file/library it is working with at the moment. As such I didn't put in a if divisor is zero check, and now want the compiler to waste my time on a warning that is wrong.

throwaway2048 7y ago

this is a complete misunderstanding of what undefined behavior is, the compiler doesn't detect UB and then call emit_nasal_daemons().