On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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
