More C type errors by default for GCC 14

[Arsen Arsenović]

Po Lu <luangruo@yahoo.com> writes:

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

Seems that the algorithm and I agree.  I don't see any use in the int()
guess that the compiler does, besides accepting old code (which makes it
candidate for -fpermissive).

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

Ah, sounds similar to the LTO-time checking GCC can do.

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

We can diagnose these without invoking expensive machinery, unlike
mismatched declarations.

(theoretically, we could make an enabled-by-default Link Time Check mode
instead, I suppose... but we don't have that today, and it's certainly
more maintenance overhead than flipping a few defaults.)

I don't see why these not being diagnosed by default makes erroring on
the far simpler implicit case not valuable (even if it leads to people
just consciously inserting wrong declarations - that means they
acknowledged it and made a poor decision).

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

They can be caught in multiple places when obvious, such as when not
done explicitly.  These are two different errors.

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

I can't say.  I don't have memory of the traditional mode outside of
cpp.  The changes proposed today, however, are a few bits of entropy
relevant in a few places - the overhead is low.

Someone else would have to answer about why -traditional was replaced.

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

It's not, though.  That's why this is being conversed about.  Even
highly diligent people miss these (and even not-so-diligent people like
me do - I've had more of these found by me passing -flto than I did by
remembering to use an extra four -Werror=... flags, and that, of course,
misses the int(...) case - which is not a useful one, usually what I
meant there was (void), but strict-prototypes are a story for another
day or year).

Have a loevly evening.
-- 
Arsen Arsenović
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 381 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20230511/35f0e9da/attachment-0001.sig>