From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:470:142:3::e]) by sourceware.org (Postfix) with ESMTPS id D2F293858C54 for ; Fri, 12 May 2023 10:38:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D2F293858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org 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=ooSTQ63H2m8NUAjYBze9hA/BHfd5UhWqa1g4jhMkyAA=; b=LIDOS9RAWnIor31Yt+46 eutHM5xjrzelOkc7EjUgcZmkxEla83IsoFFEJZLBVnbJ9L6W4qWxmBq/VKiy0T2uMXGF+IRc85ULO PU5+yiD1IA2xz534MrS2gOvACNT+72QEAUmjtosU/Jn7KBNcjIB1R6yEe7wrohfIfFI5LBAZikCqm T29ehA1/hSRfggWXShFavX8xmGnlhSWgRQ4W9tViOjklgnSGoPx+CJNV17z6UJZmqHPmRqwfrw4Zl XA12wCYxeUh+lmhiJoyJ+VR1wl19HH4S80BwUB9hY7CTmKEIn/NVTUymp2yCINkxlNcxRmamMck/b Cmy2Re4U8MJyuQ==; 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 ) id 1pxQAn-0001yQ-7h; Fri, 12 May 2023 06:38:53 -0400 Date: Fri, 12 May 2023 13:40:04 +0300 Message-Id: <83y1lt3kaj.fsf@gnu.org> From: Eli Zaretskii To: Jakub Jelinek Cc: arsen@aarsen.me, luangruo@yahoo.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org In-Reply-To: (message from Jakub Jelinek on Fri, 12 May 2023 10:15:45 +0200) Subject: Re: More C type errors by default for GCC 14 References: <87y1lx1avj.fsf@oldenburg.str.redhat.com> <83ednoapb6.fsf@gnu.org> <875y8zegnc.fsf@yahoo.com> <865y8zmi08.fsf@aarsen.me> <87bkirclqv.fsf@yahoo.com> <86a5ybjlbd.fsf@aarsen.me> <83ilcz5f5e.fsf@gnu.org> <865y8y8tjr.fsf@aarsen.me> <834joi3s07.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Date: Fri, 12 May 2023 10:15:45 +0200 > From: Jakub Jelinek > Cc: Arsen Arsenović , luangruo@yahoo.com, > jwakely.gcc@gmail.com, gcc@gcc.gnu.org > > On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote: > > > > Let's keep in mind that veterans are much more likely to have to deal > > with very large programs than newbies, and so dealing with breakage > > for them is much harder than doing that in a toy program. Thus, the > > proposal does "pressure the old very much". > > Pressure for something they should have done decades ago if the code was > really maintained. Why not assume that at least some of them didn't because they had good reasons? > Anyway, I don't understand why these 3 (implicit fn declarations, > implicit ints and int-conversions) are so different from anything that > one needs to change in codebases every year as documented in > gcc.gnu.org/gcc-NN/porting_to.html . It is true that for C++ there are > more such changes than for C, but say GCC 12 no longer accepts > computed gotos with non-pointer types, GCC 10 changed default from > -fcommon to -fno-common for C which also affects dusty codebases > significantly, GCC 9 changed the lifetime of block scope compound literals > (again, affected various old codebases), GCC 5 broke bad user expectations > regarding preprocessor behavior by adding extra line markers to represent > whether certain tokens come from system headers or not, etc. > And of course compiler optimizations added every year can turn previously > "working" code with undefined behaviors in it into code not working as user > expected. E.g. compared to the above 3 that are easily fixed, it is obvious > what the problem is, tracking undefined behavior in code even when one > has sanitizers etc. is much more time consuming. The difference, IMO, is that in all the cases you describe the changes were done because they were necessary for GCC to support some new feature, or fix a bug. By contrast, in this case there's no new features that require to fail to compile the code in question. > Can we stop this thread. I'm afraid everything has been said multiple > times, it is up to the GCC Steering Committee to decide this if there is > disagreement on it among GCC developers, but my current understanding is > that that is not the case here and that the active GCC developers agree on > it. Fine, I will stop posting at this point. Thanks for listening.