4 ms·

For such inlining optimization it is the compiler that 'introduces' the UB in its intermediate step. That is not a fault of the input code, so no warning should

by jononor 10y ago

For such inlining optimization it is the compiler that 'introduces' the UB in its intermediate step. That is not a fault of the input code, so no warning should be emitted? If the compiler can know that the pointer is non-null, why would it need to rely on UB to optimize it? Problem I guess is the ever-present possibility of pointer aliasing and such nearly allowing anything to change anything else at any time... Not easy making things more sound on such a foundation.

derf_ 10y ago
If the compiler can know that the pointer is non-null, why would it need to rely on UB to optimize it? You've got this backwards. The compilers "knows" the pointer is non-null because you dereferenced it, and dereferencing null would have been undefined behavior. That's what allows the compiler to assume that didn't happen. There are many operations which will produce undefined behavior for some inputs (e.g., every pointer dereference, every signed integer arithmetic operation). Figuring out if it is possible for a program to encounter such inputs at runtime is equivalent to the halting problem. This is why any attempt to craft a -Wundefined-behavior that works on non-trivial programs is doomed to failure. It may be possible to prove a program will definitely invoke undefined behavior in some useful subset of cases. Compilers already do this in some of them, even. But those cases (and many more, besides) would also be caught with ubsan and a unit test.
- jononor 10y ago
  You're right, it is an intractable problem in general. I guess just use Rust if one cares about this..
masklinn 10y ago
> For such inlining optimization it is the compiler that 'introduces' the UB in its intermediate step. Technically the UB is in the original code, it's the dereferencing of a pointer without checking it. The compiler can merely use that to assert dead code (checking for a null pointer after having already deref'd the pointer is nonsensical) and optimise it away.
- jononor 10y ago
  I don't support this unsafe compiler behavior. There should be a check on the pointer in sight, or a manual declaration that "this is safe, trust me". Otherwise, emit a UB warning...
  - adrianN 10y ago
    Then you want to use a different language. Java for example throws NullPointerException instead of having UB for null pointer accesses.
    - benibela 10y ago
      Object Pascal just calls the function with this == null (well self = nil)
      - adrianN 10y ago
        ON ERROR RESUME NEXT

by jononor 10y ago

derf_ 10y ago

If the compiler can know that the pointer is non-null, why would it need to rely on UB to optimize it? You've got this backwards. The compilers "knows" the pointer is non-null because you dereferenced it, and dereferencing null would have been undefined behavior. That's what allows the compiler to assume that didn't happen. There are many operations which will produce undefined behavior for some inputs (e.g., every pointer dereference, every signed integer arithmetic operation). Figuring out if it is possible for a program to encounter such inputs at runtime is equivalent to the halting problem. This is why any attempt to craft a -Wundefined-behavior that works on non-trivial programs is doomed to failure. It may be possible to prove a program will definitely invoke undefined behavior in some useful subset of cases. Compilers already do this in some of them, even. But those cases (and many more, besides) would also be caught with ubsan and a unit test.

jononor 10y ago
You're right, it is an intractable problem in general. I guess just use Rust if one cares about this..

masklinn 10y ago

> For such inlining optimization it is the compiler that 'introduces' the UB in its intermediate step. Technically the UB is in the original code, it's the dereferencing of a pointer without checking it. The compiler can merely use that to assert dead code (checking for a null pointer after having already deref'd the pointer is nonsensical) and optimise it away.

jononor 10y ago
I don't support this unsafe compiler behavior. There should be a check on the pointer in sight, or a manual declaration that "this is safe, trust me". Otherwise, emit a UB warning...
- adrianN 10y ago
  Then you want to use a different language. Java for example throws NullPointerException instead of having UB for null pointer accesses.
  - benibela 10y ago
    Object Pascal just calls the function with this == null (well self = nil)
    - adrianN 10y ago
      ON ERROR RESUME NEXT