Hi Richard, On 18.06.21 08:19, Richard Biener wrote:
The issue is that a 'const T' declaration is _not_ a valid constant initializer:
const int i = 0; static int j = i;
is not valid C. Now, compilers are free to accept extra initializers and there's no diagnostic required so it happens that newer compilers accept more forms of constant expressions for convenience.
Thanks for the explanation. It's beyond my limited understanding of C (and beyond my capabilities) to suggest a fix to upstream. Even patching it to compile on Leap's gcc-7 is apparently not trivial...
It doesn't make it valid C though. C18 in 6.6(7) and then (8) still makes this invalid, but as said (10) says "An implementation may accept other forms of constant expressions".
...and the newer implementations apparently do. So for me, considering the limited usage that a newer bluez package on anything older than Factory will see in general (I just build it in case I see something strange happening on a Leap system, to be able to quickly test if it is fixed in the latest version), the "cheapest" method is to just use the (easily available) gcc-8 to build it on Leap.
It's unfortunate there's no strict mode that diagnoses this consitently.
A "fix" would be to use C++ which has constinit / constexpr to force compile-time evaluation (otherwise you risk runtime initialization).
I'd guess it would be pretty interesting to introduce C++ to upstream for one single testing tool in bluez ;-) The code in question is contributed by intel, maybe I'll try compiling it with intel's compiler, maybe it also does not like that syntax and that will let the authors fix their stuff ;-) Thanks again, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman