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...
