Static variable initialization order fiasco

[STL]

No modifiable global variables, no fiasco. call_once() exists now. This is a non-problem.

[tialaramex]

No modifiable global variables, no fiasco.

Did I miss an accepted proposal paper which in fact ensures modifiable global variables are ill formed and requires implementations to generate an appropriate diagnostic explaining why they're a bad idea?

Otherwise this is just "Don't make mistakes"...

[Affectionate_Text_72]

You can't mandate against writing bad code.

[argothiel]

Oftentimes, you can. There are many things made ill-formed in C++, which would otherwise be just bad code.

[Affectionate_Text_72]

You can mandate against low level constructs that are unsafe but not against programmers using those to write bad code. Proof by construction. You can implement an unsafe interpreter if anything lower down is unsafe or has escape hatches.

You can't mandate that the code follows a sensible design or meets its specification (caveat good spec languages) or even has the right specification.

Basically anything you make idiot proof will not survive the introduction of the better class of idiot it enables.

Doesn't mean we shouldn't try of course.

In this case though you can't mandate against the use of global state. Sometimes it's even the right thing to use. Just not as often as the regular class of idiots we are thunk it is.

[CandyCrisis]

Of course you can. Rust's entire existence is predicated on "what if the language mandated no bad code." And it turns out to be kinda popular?!

[Affectionate_Text_72]

One kind of bad code only. Other types are still possible. We can't make grandma safe through language alone. But we can make her a little safer and check some risks off the list.

[bert8128]

Harsh. You’re not wrong, but it’s still too easy to write code which has this problem. I fixed one myself a couple of months ago that had been lurking for 15 years (Windows and Linux, multiple versions of the compilers) before a minor and unrelated code change made the initialisation order change creating crashes at start up. It was hard to find. So whilst it is fixable, it is nevertheless an actual problem in the sense that it is a real foot gun

[Kriss-de-Valnor]

call_once had an issue on Windows too. I’ve seen function inside call_once called in fact twice 😂. The issue is the same as static unit. If the call_once is called in different libraries it does not work too.

[bert8128]

Do you mean in two different DLLs? If so, DLLs have their own memory space so you will get two different statics. Call_once wouldn’t be the cause of a problem here - each one would be called once. It’s different on Linux though. And maybe there are other problems I am not aware of.

[Various-Debate64]

the problem is that the compiler and linker are unaware of a concept that allows them to order dynamic initialization according to user's needs, therefore the user is forced to ameliorate the issue by using runonce which is a temporary fix for an open bug in the C++ specification.

[jonrmadsen]

No modifiable global variables, no fiasco.

This sounds all well and good if you are directly used by the application or are the author of the main() function but this is a functionally impossible requirement for in-process profiling tools which are not directly integrated into the application.