Re: More C type errors by default for GCC 14

[Florian Weimer <fweimer@redhat.com>]

* David Edelsohn:

> Yes, GCC has two, distinct user groups / use cases, but GCC also has a
> very unique and crucial role, as the foundation for a large portion of
> the GNU/Linux and FOSS software ecosystem.  This proposal is missing a
> motivation for this change, especially making new errors the default.

I tried to explain that in my introductory comments, but perhaps that
was a bit too abstract.

Here are some examples of the stuff I personally deal with in this space
on a semi-regular basis.

* alleged code generation bugs because the upper 32 bits of a pointer
  are set to zero or 0xffffffff, resulting in crashes.  This can happen
  if GCC synthesizes an implicit int declaration for a pointer-returning
  function.

* Alleged code generation bugs because a function returning bool does
  not set the entire register, as expected the caller.  This can happen
  if GCC makes up a function declaration returning int for a function
  that actually returns bool on x86-64.

* Making source-only API transitions away from a particular function is
  surprisingly hard if you still want to provide binary compatibility,
  and not put ugliness like

    #define function_api_v1(arg0, arg1, arg2) \
      DO NOT CALL THIS, USE function_api_v2 instead

  into installed header files (or rely on GCC extensions such as the
  poison pragma).

* Incomplete ports of C extensions to newer Python and Ruby versions
  which still compile and link, but fail at some point during run time
  because they try to call functions that do not exist.  (BIND_NOW
  mitigates that to some extend, but that's mostly a downstream thing.)

These are just a subset of the issues that are escalated to me, and I
don't even work on the compiler for real.  I don't know how much of that
ends up with the real compiler developers, or in how many cases
programmers eventually debug the issue on their own, finally spot the
warning in the build log, and make the connection.

Nowadays I ask for full build logs before I look at anything else, and
given the way we build our applications, we usually have that, so that
is a convenient shortcut.  (For others, it will be buried in some IDE,
and all you can get from them are screenshots.)  But if application
developers poked at the problem with GDB to the point that they can
share disassembly they think that shows a compiler bug, they must have
spent quite some time on it.  If GCC had different defaults, they
wouldn't have to do that, increasing their productivity.

I hope this makes things clearer.  I do think the current GCC defaults
are needlessly frustrating, which is why I spent so much time on proving
(from my perspective) that it should be feasible to change them.

> GCC needs to be proactive, not reactive, without annoying and
> frustrating its user base.  Clang has been making some aggressive
> changes in warnings, but its constituency expects that.  Developers
> who want that experience already will use Clang, so why annoy
> developers who prefer the GCC experience and behavior?

I really would like to keep GCC as the system compiler, but avoid the
hidden costs of the current GCC defaults.

We can get fairly close by injecting appropriate -Werror= options during
the distribution build.  On the other hand, we are already up to about
fifteen recommended compiler flags.  We are looking at adding between
two and four additional -Werror= flags for this.  The optics aren't
great.  In our case, ISVs who do not do RPM builds would have to
replicate and maintain this flag list in their own build environments
because they wouldn't benefit from the distribution default flags.  I'm
worried all this looks rather unprofessional.

> The new warnings and errors help some developers and improve software
> security, but also drive some developers away, or at least cause them
> to reass their choice of toolchain.

That goes in the other direction as well, I think.  Developers are
pressured to use languages which are generally perceived to offer more
type safety.  Here we have a few cases where we could increase the type
safety of C, without having to switch to a completely different
language.

I don't think C is as static as used to be, by the way.  C2X (and glibc
before that, especially with _GNU_SOURCE) is adding lots of widely-used
identifiers to existing headers, so that will cause some breakage, too.
The C2X changes seem to conflict with keeping GCC as the 90s C compiler
(at least by default).

And g++ regularly fixes language and header conformance issues as bugs,
not treating them as perpetually supported extensions.  The resulting
churn does not seem to have hurt adoption of C++ or g++.

Thanks,
Florian