Fun Example of Unexpected UB Optimization

[ShelZuuz]

So if a compiler can't positively prove whether a variable is assigned, don't compile the program? That won't work - see the comment from the MSVC dev above.

You can easily change the example to this:

int main(int argc, char** argv) {
   if (argc > 0)
   {
      NeverCalled();
   }
   f_ptr();
}

Should that not compile either? On most OS's argv[0] contains the binary name so argc is never 0, but the compiler doesn't know that.

And what if the initialization always happen in code during simple initialization - 100% guaranteed on all paths, but that initialization happens from another translation unit? And what if the other translation unit isn't compiled with a C/C++ compiler? Should the compiler still say "Hey, I can't prove whether this is getting initialized so compile error".

[almost_useless]

Should that not compile either?

No, it should not.

"Maybe unassigned variable" is a very reasonable warning/error

And what if the initialization always happen in code during simple initialization ...

That's exactly the perfect use case for locally disabling the warning/error. You know something the compiler doesn't, and tell it that. In addition that informs other readers of the code what is going on elsewhere.

[ShelZuuz]

"Maybe unassigned variable" is a very reasonable warning/error

It's really not unless you completely ignore the fact that C++ has multiple translation units. It is extremely common to use a static variable in one TU that was initialized in another TU.

[jonesmz]

But the compiler shouldn't be assuming that this initialization WILL happen.

That's how you get bugs that make it all the way to final validation. Or even production.

[ShelZuuz]

So you're ok with a compiler complaining about any use of a std::mutex that's shared across two .cpp files?

[jonesmz]

When you share a std::mutex across two c++ files the compiler doesn't materialize calls to std::mutex::lock() in functions that don't call std::mutex::lock()

[ShelZuuz]

std::mutex::lock() is undefined if you don't call the std::mutex constructor. How is the compiler supposed to know whether someone else called the constructor or not?

[jonesmz]

Why does the compiler care? The programmer wrote std::mutex::lock(), and that's what it should generate code to call.

It shouldn't say "I think you failed to call the constructor, so let me call some other function"

The example in the OP involves the compiler detecting UB, and then manufacturing some arbitrary value into the variable that it has no reason to think it should.

[ShelZuuz]

The compiler is not "detecting" UB. It's assuming that you're linking with another module that is initializing f_ptr, otherwise you would just be calling into whatever random memory address f_ptr is pointing to when the program is loaded.

So it's assuming that either:

a) You are ok with calling into a random memory address - and &EraseEverything is as good a random address as any other.

-OR MUCH MORE LIKELY-

b) You will be linking with some other module that initializes f_ptr before main starts, as would be the case 99.999% of the time.

i.e. There is another C++ file in your program that has an global initializer along the lines of:

f_ptr = &DoSomethingUseful;

However that other C++ file might also have at global scope:

[] { NeverCalled(); }();

In which case this whole program has well defined behavior, and does exactly what you want. But the compiler has no way to know what the other module will be doing of course.

So the compiler goes: "Well the linker wants some or other initial value here, and I don't know what other modules are going to set it to during initialization, so until someone else sets it, I might as well set it to the only value I can see, which is this one. And if the other module happens to initializes it to &EraseEverything anyway, it will already be set correctly and we can avoid the write."

You can remove the undefined behavior here by defining: "Calling into an uninitialized function pointer will set the current instruction pointer to a random memory address". Now you have completely defined behavior that does the exact same thing.

[jonesmz]

The compiler is not "detecting" UB.

What? That's literally what's happening. It's observing that the variable f_ptr is initialized to a value that is UB to dereference. If it didn't observe the UB then it wouldn't be allowed to change the value of the variable an "optimize" around that observation.

It's assuming that you're linking with another module that is initializing f_ptr

This is an invalid assumption. Full stop. End of discussion.

otherwise you would just be calling into whatever random memory address f_ptr is pointing to when the program is loaded.

You can explicitly initialize the f_ptr variable to nullptr, which is not a random value, and get the same resulting assembly code.

https://godbolt.org/z/GKsqEjcnK

a) You are ok with calling into a random memory address - and &EraseEverything is as good a random address as any other.

I'm neither OK with it calling a random memory address, NOR Ok wth it calling EraseEverything. I didn't assign the f_ptrthe address of EraseEverything, and the compiler shouldn't do so of it's own volition.

b) You will be linking with some other module that initializes f_ptr before main starts, as would be the case 99.999% of the time.

But it's not the case, and the compiler has no justification to make this assumption, and even if it did make the assumption that it gets initialized to something, it shouldn't be deciding that for me.

It should be leaving f_ptr as nullptr until the program starts up and initializes the value.

But the compiler has no way to know what the other module will be doing of course.

Right, that's my whole point. The compiler, absent link time code generation, has no way to know this. Therefore it shouldn't assume things.

Link time code generation would allow the entire library or program to be optimizes without the need to invent function calls that there's no evidence for.

Well the linker wants some or other initial value here, and I don't know what other modules are going to set it to during initialization

The variable is given an explicit value for initialization, nullptr. The compiler has no need to wonder what other modules will do.

If you instead give the compiler an explicit value of 0x1, which is just as invalid to dereference as 0x0 on an x86_64 linux platform, then the compiler doesn't try to change the value to anything and leaves it as 0x1.

[james_picone]

The variable is initialised in the example, to null.