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 D03F83858CDA for ; Fri, 12 May 2023 07:52:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D03F83858CDA 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=Xd9DeCNdgdybgK8+jFCg5YuMCkHsprqcZxdGI2rsbWE=; b=cqlYDLP1Wg7Q3HyUMBBK jQqM1PUV3KTMkLZrQP9WBK358oz4KmttHnrUbZnPoCUbLtMMpzDZAzV1OjRqa67V9Lx1AY6vYL5Ip g3djq25IyXJ/CiaCg7ZY3KsMmK4bzMfpsKWyrT+n+izG/Alhocebd/Nvhbi2Xcq908sVEUD+hcE7t T12NPu2tQ4DuSigwWO+5s04iZSPzfA5QqfjsgOwRTMit2+3Okr0plASjnkAXi709b0xouTXFV4xdc YUcdmLIk8IfP46X1M7DVc6FglZRj8CTG2sDJE7iNg3H4xKqKIuYAfsalLyxK5/NJ9NkIzTcN4xZ8F JCwfxtNps2oHsQ==; 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 1pxNZb-00066e-66; Fri, 12 May 2023 03:52:19 -0400 Date: Fri, 12 May 2023 10:53:28 +0300 Message-Id: <834joi3s07.fsf@gnu.org> From: Eli Zaretskii To: Arsen =?utf-8?Q?Arsenovi=C4=87?= Cc: luangruo@yahoo.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org In-Reply-To: <865y8y8tjr.fsf@aarsen.me> (message from Arsen =?utf-8?Q?Arse?= =?utf-8?Q?novi=C4=87?= on Thu, 11 May 2023 21:25:53 +0200) Subject: Re: More C type errors by default for GCC 14 References: <877cth66qb.fsf@oldenburg.str.redhat.com> <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net> <87r0rp5uf8.fsf@aarsen.me> <83ttwla1ep.fsf@gnu.org> <83lehx9vix.fsf@gnu.org> <83fs859unu.fsf@gnu.org> <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> 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,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: > From: Arsen Arsenović > Cc: luangruo@yahoo.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org > Date: Thu, 11 May 2023 21:25:53 +0200 > > >> This seems like a good route to me - it facilitates both veterans > >> maintaining code and beginners just learning how to write C. > > > > No, it prefers beginners (which already have the warnings, unless they > > deliberately turn them off) to veterans who know what they are doing, > > and can live with those warnings. > > Indeed. I said facilitates, not treats equally. I think the veterans > here won't lose much by having to pass -fpermissive, and I think that's > a worthwhile sacrifice to make, to nurture the new without pressuring > the old very much. 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". > > The right balance is exactly what we have now: emitting warnings > > without breaking builds. > > I disagree - I think breaking builds here (remember, it takes 13 bytes > to fix them) is a much lower weight than the other case being shot in > the foot for an easily detectable and treatable error being made easily > missable instead, so I reckon the scale is tipped heavily towards the > veterans. I described in an earlier message how this breakage looks in real life, and why it causes a lot of frustration. The main problem is discovering that things broke because GCC defaults, and then discovering how to pacify GCC with the least effort. You are talking only about what follows these two discovery processes, and that misses the main disadvantage of this proposal (an in fact almost any breaking proposal). > On that note - lets presume a beginners role. I've just started using > GCC. I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out. It > mentions some 'implicit function generation', dunno what that means - if > it mattered much, it'd have been an error. I wrote a function called > test that prints the int it got in hex, but I called it with 12.3, but > it printed 1.. what the heck? > > Why that happened is obvious to you and I (if you're on the same CPU as > me), but to a beginner is utter nonsense. > > At this point, I can only assume one goes to revisit that warning.. I'd > hope so at least. That's perfectly okay: the beginner made a mistake of ignoring a warning, and now he or she will need to pay for that mistake. But why should someone else pay, and pay dearly, for the mistakes of such newbies? That is simply unfair. The payment should be on the one who made the mistake. > I doubt the beginner would know to pass > -Werror=implicit-function-declaration in this case (or even about > Werror... I just told them what -Wall and to read the warnings, which > was gleefully ignored) They don't need to. They just need to fix their bad code, that's all. > Is it that much of a stretch to imagine that a maintainer of a codebase > that has not seen revisions to get it past K&R-esque practices would > know that they need to pass -std=c89 (or a variant of such), or even > -fpermissive - assuming that they could even spare to use GCC 14 as > opposed to 2.95? If the program built okay till now, they might not know. > As an anecdote, just recently I had to fix some code written for i686 > CPUs, presumably for GCC 4.something or less, because the GCC I insist > on using (which is 13 and has been since 13.0 went into feature-freeze) > has started using more than the GPRs on that machine (which lead to hard > to debug crashes because said codebase does not enable the requisite CPU > extensions, or handle the requisite registers properly). I think this > fits within the definition of 'worked yesterday, broke today'. But it broke for a valid technical reasons: GCC was improved by supporting more registers, and thus it now emits better code. This kind of reason is perfectly legitimate for breaking some old and borderline-invalid programs, especially if GCC was emitting warnings for those programs in past releases. But the change discussed here is not like that. > With all that to consider, is it *really* a significant cost to add > -fpermissive? See above (and my earlier message): the significant cost is to discover the root cause of the problem, and that -fpermissive is the solution. The rest might be relatively easier, at least in some projects. > I expect no change in behavior from those that maintain these old > codebases, they know what they're doing, and they have bigger fish to > fry - however, I expect that this change will result in: > > - A better reputation for GCC and the GCC project (by showing that we do > care for code correctness), > - More new code being less error prone (by merit of simple errors being > detected more often), > - Less 'cult knowledge' in the garden path, > - More responsible beginners, and > - Fewer people being able to effectively paint GNU and/or C/++ as the > backwards crowd using a error-prone technique of yesteryear. These are not technical reasons in my book, they are PR stuff. Breaking code that was building previously based on such reasons should be unacceptable in any project that respects its users. > Builds break. Yes, and cars crash every day. But we still consider car crashes to be undesirable, and take measures to minimize that. IOW, there's no reason to be fatalistic about build breakage; we should instead proactively try to minimize that.