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