3 ms·

I don't see the UB. Are you implying or assuming that x and y are defined in different translation units? That would be certainly be UB, but what you wrote does

I don't see the UB. Are you implying or assuming that x and y are defined in different translation units? That would be certainly be UB, but what you wrote doesn't look like that. ETA: from https://en.cppreference.com/w/cpp/language/siof https://en.cppreference.com/w/cpp/language/siof "The static initialization order fiasco refers to the ambiguity in the order that objects with static storage duration in different translation units are initialized in." "Within a single translation unit, the fiasco does not apply because the objects are initialized from top to bottom."

KMag 3y ago
Sorry, from the context, you could assume the above was C++. At least in C89, floating point literals aren't constant expressions, and static initialization order is only defined for constant expressions. I distinctly remember getting burned by this in 2003. GCC was acting sanely, but Sun Studio was initializing two static const floats in successive lines in the same file in reverse order they were defined, resulting in 0.0 for the product of two nonzero constants. Tracking that down was rather painful. Switching the file to C++ solved the issue, but this was radio network simulation code that took several days to run on my client's $250,000 Sunfire V1280 with 96 GB of RAM (quite a large amount of RAM for 2003), and Sun's C++ compiler generated slower code for this same file. I presume some amount of monkeying with compiler flags would have brought the C++ performance back in line with the C performance, but I had more important things to do. So, I changed the static const doubles to #defines and that also fixed the bug.