From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 04D9A2105
	for <c-std-porting@lists.linux.dev>; Wed, 10 May 2023 12:26:31 +0000 (UTC)
Received: from fencepost.gnu.org ([2001:470:142:3::e])
	by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.90_1)
	(envelope-from <eliz@gnu.org>)
	id 1pwiZj-0004MV-Sa; Wed, 10 May 2023 08:05:43 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
	s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
	Date; bh=cM/Oo3b43Gto5EStV7f3E7erJe9vs2/WSKZJHnMYX/8=; b=hKjN0CzgNK1+18iS3laN
	Tr/zQIwM/zHmwOB17CaqkcL77cjTUDhzgqzPrbqAptTOHxYSz86DBVivJV3zCDfeyKchFgX0CZCaj
	EqxLrydiROytM5JVgmPNv7xy6D+pr4Ef9DqT7WYxWRkHOziT4R0XvyzziCdfun/UwDxD5XE5YQ2oE
	dnC+fW8GqfWe4ZmrQBNWADGvt62OQy9xW3Tx89F7Q2hVFImJYISgzi17r8JG8fcgvXC1zk4u23yPQ
	jjahZN22xV8O2M8ISheno1/qW6oNNNal8+hMc6i9STuQC7rngSN0e5upUg+BjnTo0sF1FB8W4Kazg
	eqPaVJM/VV+aYQ==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
	by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.90_1)
	(envelope-from <eliz@gnu.org>)
	id 1pwiZa-0005Et-BH; Wed, 10 May 2023 08:05:40 -0400
Date: Wed, 10 May 2023 15:06:37 +0300
Message-Id: <83ttwk8k6q.fsf@gnu.org>
From: Eli Zaretskii <eliz@gnu.org>
To: Neal Gompa <neal@gompa.dev>
Cc: sam@gentoo.org, egall@gwmail.gwu.edu, jwakely.gcc@gmail.com,
	joel@rtems.org, dje.gcc@gmail.com, jakub@redhat.com,
	arsen@aarsen.me, gcc@gcc.gnu.org,
	c-std-porting@lists.linux.dev
In-Reply-To:
	<CAEg-Je8iHRMVNzecpr6eNT5YZ+Qdxmv-N4E0zu5o9DRUEWqkJg@mail.gmail.com>
	(message from Neal Gompa on Wed, 10 May 2023 06:56:32 -0400)
Subject: Re: More C type errors by default for GCC 14
References: <877cth66qb.fsf@oldenburg.str.redhat.com> <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
 <CAH6eHdS5=AED+7MSe0prr8CZ-sYqnD159OjhTp9=R-a0aBZ3qw@mail.gmail.com>
 <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net> <87r0rp5uf8.fsf@aarsen.me>
 <83ttwla1ep.fsf@gnu.org> <CAH6eHdS-7USHzX3rPJaR66sEdjG+-nHp7mDb0gD7ceBnp+Fmpg@mail.gmail.com>
 <83lehx9vix.fsf@gnu.org> <ZFqZ25xKm4w4IkqF@tucnak> <83fs859unu.fsf@gnu.org>
 <CAGWvny=xi++Ghyo2Ez5MJdYy5h3yH16gVpviKC99Ufu_bUmdYQ@mail.gmail.com>
 <CAH6eHdRAVwBcCmBgiuPyQNWGx3x33diAgQU8UG3s_NrJxK3ucQ@mail.gmail.com>
 <CAGWvnyk_MkQOrNNh1C=ubPj8qzg5x-p8CBfgWNqqtDVJ1mbhMg@mail.gmail.com>
 <CAF9ehCWsq-N9+U1+mTQahKT7cXEqLTptLb=b3Yq58gsWFEnxgA@mail.gmail.com>
 <CAH6eHdS_sQ37VTpJHL7cqtgSdCSL3i4=tqMoY65wep9G56cf5g@mail.gmail.com>
 <CAMfHzOsR=gY6QTss2R029Q-uMOTpC-RDV09bEF2FO7x5jpy5gg@mail.gmail.com> <87mt2cihs6.fsf@gentoo.org> <CAEg-Je8iHRMVNzecpr6eNT5YZ+Qdxmv-N4E0zu5o9DRUEWqkJg@mail.gmail.com>
Precedence: bulk
X-Mailing-List: c-std-porting@lists.linux.dev
List-Id: <c-std-porting.lists.linux.dev>
List-Subscribe: <mailto:c-std-porting+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:c-std-porting+unsubscribe@lists.linux.dev>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

> From: Neal Gompa <neal@gompa.dev>
> Date: Wed, 10 May 2023 06:56:32 -0400
> Cc: Eric Gallager <egall@gwmail.gwu.edu>, Jonathan Wakely <jwakely.gcc@gmail.com>, joel@rtems.org, 
> 	David Edelsohn <dje.gcc@gmail.com>, Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>, 
> 	Arsen Arsenović <arsen@aarsen.me>, gcc@gcc.gnu.org, 
> 	c-std-porting@lists.linux.dev
> 
> On Wed, May 10, 2023 at 6:48 AM Sam James <sam@gentoo.org> wrote:
> >
> > Neal Gompa wasn't keen on the idea at
> > https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=Od5DH+h9AQzGE_4ghzgx_ow4RyJVPwFTg@mail.gmail.com/
> > because it'd feel like essentially "repeated punches".
> >
> > Maybe it'd work with some tweaks: I would, however, be more open to GCC 14 having
> > implicit-function-declaration,implicit-int (these are so closely related
> > that it's not worth dividing the two up) and then say, GCC 15 having int-conversion and maybe
> > incompatible-pointer-types. But spreading it out too much is likely counterproductive.
> 
> Right, we've been going through a similar effort with C++ over the
> past decade. GCC incrementally becoming more strict on C++ has been an
> incredibly painful experience, and it eats away a ton of time that I
> would have spent dealing with other problems. Having one big event
> where the majority of changes to make the C compiler strict happen
> will honestly make it less painful, even if it doesn't seem like it at
> the moment.

But not having such an event, ever, would be even less painful.