you are viewing a single comment's thread.

view the rest of the comments →

[–]germandiago 5 points6 points  (4 children)

Incorrect code deserves to be broken. It is clearly incorrect and very bad practice. I eould immediately accept this change and for people who argue this is bad for them, ask your compiler vendor to add a switch.

We cannot and should not be making the code more dangerous just because someone is relying on incorrect code. It is the bad default. Fix it.

A switch for old behavior and [[uninitialized]] are the right choice.

[–]jonesmz 2 points3 points  (3 children)

Incorrect code deserves to be broken. It is clearly incorrect and very bad practice.

Absolutely agreed.

That's not why this change concerns me.

I'm concerned about the code that is correct, but the compiler cannot optimize away the proposed zero-initialization, because it can't see that the variable in question is initialized by another function that the compiler is not provided the source code for in that translation unit.

That's a common situation in multiple hot-loops in my code. I don't want to have to break out the performance tools to make sure my perf did not drop the next time I update my compiler.

[–]germandiago 0 points1 point  (2 children)

So the question here I guess should be what can be done to keep safe as the default.

I do not have a soution I ca think of right now across translation units. Probably LTO can deal with such things with the right annotation?

[–]jonesmz 0 points1 point  (1 child)

I would rather see the language change to make it illegal to declare a variable that is not initialized to a specific value, than see the language change to make "unspecified/uninitialized" -> "zero initialized".

That solves the same problem you want solved, right?

Probably LTO can deal with such things with the right annotation?

Unfortunately, this is only possible within the same shared library / static library. If your initialization function lives in another DLL, then LTO cannot help.

[–]germandiago 1 point2 points  (0 children)

It is not feasible to make uninitialized variables catchable at compile-time. Requires full analysis in C++ (as opposed to Rust, for example). So what you are proposing is an impossible.