On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds torvalds@linux-foundation.org wrote:
And I don't want somebody with a newer compiler version to not notice that he or she ended up using a c17 feature, just because _that_ compiler supported it, and then other people get build errors because their compilers use gnu11 instead by default.
Put another way: I see absolutely no upside to allowing different users using higher/lower versions of the standard. There are only downsides.
If gnu11 is supported by gcc-5.1 and up, and all the relevant clang versions, then let's just pick that.
Ok, changed my patch to -gnu11 now.
And if there are any possible future advantages to gnu17 (or eventual gnu2x versions), let's document those, so that we can say "once our compiler version requirements go up sufficiently, we'll move to gnuXX because we want to take advantage of YY".
Please?
I think all of the options here are equally bad: picking gnu11 means we use a non-standard default for anything other than gcc-5 and may get surprised again in the future when we want to change to a newer version; -std=gnu1x would work as an alias for gnu17 in all versions including gcc-5 but is already marked as 'deprecated' in the gcc documentation; and using -std=gnu17 for modern compilers requires a workaround for gcc-7 and earlier.
Regarding new features from gcc-2x, I think we already use most of what is listed in https://en.wikipedia.org/wiki/C2x, as those are all GNU extensions that are valid in modern gnu89 as well. Newly added features seem to only depend on the compiler version, e.g. #elifdef works in both clang-13 and gcc-12 with any -std=gnu?? argument, so picking an earlier standard won't stop people from breaking the build with older compilers.
Arnd