Nick Bowler <nbowler@xxxxxxxxxx> writes: > My gut feeling is that Autoconf should just determine the necessary > options to get compatible behaviour out of these modern compilers, at > least for the purpose of running configure tests. For example, Autoconf > should probably build the AC_CHECK_FUNC programs using gcc's > -fno-builtin option I fear this will cause more problems than it solves. Messing with compiler options inside a configure script has a track record of clashing with “outer” build tools that expect to be able to dictate the options. > It saddens me to see so much breakage happening in "modern C", a > language that has (until now) a long history of new language features > being carefully introduced to avoid these sort of problems. I don’t exactly _disagree_ with this. Quite a few of the compatibility- breaking changes going into C2x (promoting ‘bool’ to a true keyword, for instance, and changing the meaning of an empty argument list in a function declaration) strike me as unnecessary churn. However, the specific set of changes that are under discussion right now—removal of implicit function declarations, implicit int, and old-style function definitions from the _default_ language accepted by C compilers—I’m very much in favor of, because they make life significantly easier for people writing _new_ code. It’s not healthy for a language to always prioritize old code over new code. (Yes, you _can_ opt in to all three of those changes now, but you have to type a bunch of -W options. With my day job hat on, I am very much looking forward to a day where ‘cc test.c’ errors out on implicit function declarations, because then I won’t have to _explain_ implicit function declarations, and why they are dangerous, to my students anymore.) >> p.s. GCC and Clang folks: As long as you’re changing the defaults out >> from under people, can you please also remove the last few predefined >> user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the >> -std=gnuXX modes? > > Meh, even though these macros are a small thing I don't accept the > "things are breaking anyway so let's break even more things" attitude. Getting rid of these is another change that will make life easier for people writing new code. zw
