Re: More C type errors by default for GCC 14

[Po Lu <luangruo@yahoo.com>]

Arsen Arsenović <arsen@aarsen.me> writes:

> Relying on human scrutiny when an algorithm can trivially deduce an
> answer more quickly and more reliably (because even in the case that the
> code you showed compiles, it assumes processor specific facts) has
> historic precedent as being a bad idea.

The algorithm in question is not much of an algorithm at all.  Rather,
it makes the blanket assumption that the lack of an explicit declaration
means the implicit declaration is incorrect, and that there is a correct
declaration in a header file somewhere.  That sounds rather premature,
don't you agree?

> I'm curious, though, about how lint checks for this.

Lint generates a lint library describing (among others) a description of
each function definition in every translation unit it checks.  It also
imports pregenerated lint libraries, such as those for the C and math
libraries.  All declarations are then checked against the lint libraries
being used.

> So be it.  The edge case still exists.  The normal case that I expect
> most code is dealing with is much simpler: a missing include.  That case
> is not discounted by the existence of misdeclarations across TUs.

I can't believe that the normal case is a missing include, because I see
`extern' declarations outside header files all the time (just look at
bash, and I believe one such declaration was just installed in Emacs.)

And how does that discount what I said people will do?  They will get
into the habit of placing:

  extern int foo ();

above each error.  Such declarations are also much more common than
implicit function declarations, and are more likely to lead to mistakes,
by the sole virtue of being 100% strictly conforming Standard C that
need not lead to any diagnostics, and thus, extra scrutiny from the
programmer.

The point is, such checks are the job of the linker and lint, because as
you yourself have observed, those are the only places where such bugs
can really be caught:

> There's already -Wlto-type-mismatch.  It has spotted a few bugs in my
> own code.

[...]

> Yes, indeed.  And code should keep working on those machines, because it
> costs little to nothing to keep it working.  And it will if you pass
> -fpermissive.

And what prevents -fpermissive from being removed in the future, once
the folks here decide that -fpermissive must go the way of -traditional?

> It is unfeasible for GCC to entirely stop compiling this code, there's
> nobody that is advocating for doing that; however, the current default
> of accepting this code in C is harmful to those who are writing new
> code, or are learning C.

I expect people who write new code to pay even more scrutiny to
diagnostics from their C translator than usual, so the existing strategy
of issuing warnings should be sufficient.

> Have a lovely day.

You too.