c-std-porting.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Sam James <sam@gentoo.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
	gcc@gcc.gnu.org, c-std-porting@lists.linux.dev
Subject: Re: More C type errors by default for GCC 14
Date: Tue, 09 May 2023 18:07:16 +0100	[thread overview]
Message-ID: <87h6sljurv.fsf@gentoo.org> (raw)
In-Reply-To: <87pm794f1m.fsf@oldenburg.str.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]


Florian Weimer <fweimer@redhat.com> writes:

> * Richard Biener:
>
>>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>:
>>> 
>>> TL;DR: This message is about turning implicit-int,
>>> implicit-function-declaration, and possibly int-conversion into errors
>>> for GCC 14.
>>
>> I suppose the goal is to not need to rely on altering CFLAGS but
>> change the default behavior with still being able to undo this using
>> -Wno-error= or -Wno-?
>
> That's what Clang does (and the defaults chang along with -std=
> settings). To me, -Werror by default for some warnings seems rather
> hackish.  But that's just my personal preference, I do not have a strong
> objection to doing it that way.

Not that we have to follow Clang, but deviating by adding -fpermissive
(which is a GCC-only flag) for C may not be desirable, and following
Clang would let people use the same method for silencing known-bad
codebases for now.

>
> One downside with -Wno- is that some developers jump on this rather
> quickly instead of fixing the real problem.  So far, I've seen this in
> both Chromium and the kernel, in fringe areas admittedly, but still.
> The advantage is that there is a familiar workaround to get things
> compiling quickly again, of course.
>

I've not seen very much of this so far, FWIW. Only for the more annoying
C23 warnings which have well-documented problems (and unrelated to this,
so I won't go on about it anymore).

But -fpermissive does have a nice property in that it's immediately
obvious you're doing something *terrible* if you use it.

>> I think instead of hard-coding a set of changes would it be possible
>> to alter the default setting of diagnostic options during GCC
>> configuration?  And maybe even note that when diagnosing?
>
> I'd be worried about our package maintainers if we do something like
> that.  We'd like them to report build failures upstream, and if it's
> just one or two distributions doing that and not GCC upstream, well, I
> guess we just got a preview of how some upstreams are going to react.
> Package maintainers tend to be volunteer or junior engineering roles, I
> think, so this doesn't seem fair to me.

Yeah, this is one of those things where we need it happening in CI for
people and at the point of development.

(Such an option might be nice in general, but not for this if its
default didn't include these warnings or if distributions were likely
to override it to something weaker.)

thanks,
sam


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

  reply	other threads:[~2023-05-09 17:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09 12:15 More C type errors by default for GCC 14 Florian Weimer
2023-05-09 15:16 ` Richard Biener
2023-05-09 16:05   ` Jakub Jelinek
2023-05-09 16:11     ` Sam James
2023-05-09 16:59   ` Florian Weimer
2023-05-09 17:07     ` Sam James [this message]
2023-05-09 17:35       ` Florian Weimer
     [not found] ` <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
2023-05-09 15:07   ` Sam James
2023-05-09 15:14   ` Jonathan Wakely
     [not found]     ` <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net>
     [not found]       ` <87r0rp5uf8.fsf@aarsen.me>
     [not found]         ` <83ttwla1ep.fsf@gnu.org>
     [not found]           ` <CAH6eHdS-7USHzX3rPJaR66sEdjG+-nHp7mDb0gD7ceBnp+Fmpg@mail.gmail.com>
     [not found]             ` <83lehx9vix.fsf@gnu.org>
     [not found]               ` <ZFqZ25xKm4w4IkqF@tucnak>
     [not found]                 ` <83fs859unu.fsf@gnu.org>
     [not found]                   ` <CAGWvny=xi++Ghyo2Ez5MJdYy5h3yH16gVpviKC99Ufu_bUmdYQ@mail.gmail.com>
     [not found]                     ` <CAH6eHdRAVwBcCmBgiuPyQNWGx3x33diAgQU8UG3s_NrJxK3ucQ@mail.gmail.com>
     [not found]                       ` <CAGWvnyk_MkQOrNNh1C=ubPj8qzg5x-p8CBfgWNqqtDVJ1mbhMg@mail.gmail.com>
     [not found]                         ` <CAF9ehCWsq-N9+U1+mTQahKT7cXEqLTptLb=b3Yq58gsWFEnxgA@mail.gmail.com>
     [not found]                           ` <CAH6eHdS_sQ37VTpJHL7cqtgSdCSL3i4=tqMoY65wep9G56cf5g@mail.gmail.com>
     [not found]                             ` <CAMfHzOsR=gY6QTss2R029Q-uMOTpC-RDV09bEF2FO7x5jpy5gg@mail.gmail.com>
2023-05-10 10:45                               ` Sam James
2023-05-10 10:56                                 ` Neal Gompa
2023-05-10 12:06                                   ` Eli Zaretskii
2023-05-10 12:10                                     ` Neal Gompa
2023-05-10 12:41                                       ` Eli Zaretskii
2023-05-09 18:22   ` Florian Weimer
2023-05-11 21:32     ` Segher Boessenkool
2023-05-12  9:33 ` Martin Jambor
2023-05-12 12:30   ` Jakub Jelinek
2023-05-15 12:46     ` Michael Matz
2023-05-15 13:14     ` Richard Earnshaw (lists)
     [not found] <CAGWvnynMpa83AduLhRhf1PxkVujngDmmwE7Z4vk1z6+UqqAuKA@mail.gmail.com>
     [not found] ` <BBE9950C-28AA-4A1C-A4C5-7F486538004E@gmail.com>
2023-05-09 16:44   ` Florian Weimer
2023-05-09 16:58     ` Ian Lance Taylor
2023-05-09 17:08     ` Jason Merrill
2023-05-09 17:16       ` Sam James

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h6sljurv.fsf@gentoo.org \
    --to=sam@gentoo.org \
    --cc=c-std-porting@lists.linux.dev \
    --cc=fweimer@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).