Arsen Arsenović <ar...@aarsen.me> writes: > Indeed they should be - but warning vs. error holds significance. A > beginner is much less likely to be writing clever code that allegedly > uses these features properly than to be building new code, and simply > having made an error that they do not want and will suffer through > confused.
Most programs already paste a chunk of Autoconf into their configure.ins which turns on more diagnostics if it looks like the program is being built by a developer. i.e. from Emacs: AC_ARG_ENABLE([gcc-warnings], [AS_HELP_STRING([--enable-gcc-warnings@<:@=TYPE@:>@], [control generation of GCC warnings. The TYPE 'yes' means to fail if any warnings are issued; 'warn-only' means issue warnings without failing (default for developer builds); 'no' means disable warnings (default for non-developer builds).])], [case $enableval in yes|no|warn-only) ;; *) AC_MSG_ERROR([bad value $enableval for gcc-warnings option]) ;; esac gl_gcc_warnings=$enableval], [# By default, use 'warn-only' if it looks like the invoker of 'configure' # is a developer as opposed to a builder. This is most likely true # if GCC is recent enough and there is a .git directory or file; # however, if there is also a .tarball-version file it is probably # just a release imported into Git for patch management. gl_gcc_warnings=no if test -d "$srcdir"/.git && test ! -f "$srcdir"/.tarball-version; then # Clang typically identifies itself as GCC 4.2 or something similar # even if it is recent enough to accept the warnings we enable. AS_IF([test "$emacs_cv_clang" = yes], [gl_gcc_warnings=warn-only], [gl_GCC_VERSION_IFELSE([5], [3], [gl_gcc_warnings=warn-only])]) fi]) So this is really not a problem. > Indeed. I said facilitates, not treats equally. I think the veterans > here won't lose much by having to pass -fpermissive, and I think that's > a worthwhile sacrifice to make, to nurture the new without pressuring > the old very much. Until `-fpermissive' goes the way of `-traditional', `-fwritable-strings'. > On that note - lets presume a beginners role. I've just started using > GCC. I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out. It > mentions some 'implicit function generation', dunno what that means - if > it mattered much, it'd have been an error. I wrote a function called > test that prints the int it got in hex, but I called it with 12.3, but > it printed 1.. what the heck? Have you actually seen anyone make this mistake? > Why that happened is obvious to you and I (if you're on the same CPU as > me), but to a beginner is utter nonsense. > > At this point, I can only assume one goes to revisit that warning.. I'd > hope so at least. > > I doubt the beginner would know to pass > -Werror=implicit-function-declaration in this case (or even about > Werror... I just told them what -Wall and to read the warnings, which > was gleefully ignored) I'd expect a question from the newbie, directed at a web search engine. > Hell, I've seen professors do it, and for a simple reason: they knew how > to write code, not how to use a compiler. That's a big gap. > > The beginner here can't adapt - they don't know what -Wall means, they > just pass it because they were told to do it (if they're lucky!). If this is really such a bad problem, then how about clarifying the error message? > At the same time, they lose out on what is, IMO, one of the most useful > pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables > it by default.. we do). It provides effective bug detection, when the > code compiles right. It regularly spots bugs that haven't happened yet > for me. > > (and same goes for all the other useful analysis the toolchain can do > when it has sufficient information to generate correct code, or more; > some of which can't reasonably be a default) > > (on a related note, IMO it's a shame that the toolchain hides so many > possibilities behind 'cult knowledge', depths of many manuals and bad > defaults) _FORTIFY_SOURCE is not really important enough to be considered here. It's not even available everywhere. > This sample is subject to selection bias. My testing targets mostly > more modern codebases that have long fixed these errors (if they have > active maintainers), and exclusively Free Software, so I expect that the > likelyhood that you'll need to run `export CC='gcc -fpermissive' > CXX='g++ -fpermissive'` goes up the more you move towards old or more > corporate codebases, but, for a veteran, this is no cost at all. > > Is it that much of a stretch to imagine that a maintainer of a codebase > that has not seen revisions to get it past K&R-esque practices would > know that they need to pass -std=c89 (or a variant of such), or even > -fpermissive - assuming that they could even spare to use GCC 14 as > opposed to 2.95? There's bash, which still tries to work on later 4.3BSDs (AFAIK), while also building with just `gcc'. > As an anecdote, just recently I had to fix some code written for i686 > CPUs, presumably for GCC 4.something or less, because the GCC I insist > on using (which is 13 and has been since 13.0 went into feature-freeze) > has started using more than the GPRs on that machine (which lead to hard > to debug crashes because said codebase does not enable the requisite CPU > extensions, or handle the requisite registers properly). I think this > fits within the definition of 'worked yesterday, broke today'. Should > that change be reverted? Replacing it with -mmore-than-gprs would make > GCC more compatible with this old code. > > I don't think so. > > This is a sensitive codebase, and not just because it's written poorly, > but because it's a touchy thing it's implementing, any change in > compiler requires reverification. The manifestation here has *no* > significance. And the problematic part of the code in question is implementing something like swapcontext in assembler, correct? That's a far cry from breaking C code, which does have clearly defined (albeit not exactly intuitive) semantics. > ... speaking of that, if one builds their codebase without -std=.., > they're risking more than just optimization changes breaking code that > relies on bad assumptions, they're also risking a change in language > semantics.. The Standards committee does have a reasonable track record of keeping backwards compatibility, since they prioritize existing practice and the existing body of C code. So I'm not too worried about that. > With all that to consider, is it *really* a significant cost to add > -fpermissive? Yes, in case it goes away. > Would that cost not be massively overshadowed by the cost > of a compiler change? It feels like it's a footnote compared to > checking whether added optimizations go against invalid assumptions > (which is, by the way, also rectified by adding more hard and easy > to see errors). > > I expect no change in behavior from those that maintain these old > codebases, they know what they're doing, and they have bigger fish to > fry - however, I expect that this change will result in: > > - A better reputation for GCC and the GCC project (by showing that we do > care for code correctness), A compiler should care about the correctness of its own code, not that of others. > - More new code being less error prone (by merit of simple errors being > detected more often), As I said, making such things errors will simply result in people inserting `extern' declarations everywhere, which may or may not be wrong. I've seen this happen before with my own eyes. > - Less 'cult knowledge' in the garden path, I guess search engines, and better written diagnostic messages, would be enough to accomplish that? > - More responsible beginners, and > - Fewer people being able to effectively paint GNU and/or C/++ as the > backwards crowd using a error-prone technique of yesteryear. This never worked in GNU C++, right? > (and yes, optics matter) > > Builds break. Builds breaking cleanly is a treat compared to the usual > breakage. At least this breaks the few that do break with a positive > outcome. Builds shouldn't break, and the ``usual treat'' should also not happen...