More C type errors by default for GCC 14
Arsen Arsenović
arsen@aarsen.me
Thu May 11 21:10:42 GMT 2023
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>
More information about the Gcc
mailing list