From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) by sourceware.org (Postfix) with ESMTPS id F07143858434 for ; Thu, 11 May 2023 21:09:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F07143858434 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=aarsen.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=aarsen.me Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4QHPdk5k0Zz9spB; Thu, 11 May 2023 23:08:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1683839338; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=t1osB3TUoU9Ss1KkQ/+1HpDwNu4uJpW7oXw9Kz3i75w=; b=vtBUdWDRPNppBfLGXGt4GL1agEMd+b/3p/NN4b0il0Z4DauIwf7AZuJrY+EReYytSuks4w 6eAbUPF11KljiwnyEjfnvKgdtJ8EKgeEIQRxW+M+H22jWVArU356TXwMSyEEslgLGP3p6q HaMjmIvVQ8UvdcKMg60qe7UC92GB7NthCLV4EpfdEqLctIFoB2uQxQTa54hncarvy5lCZP yMSVhJ03CvM1VEjNj7AhnW/fTRCFuIHEXeyPGTSmhjJ24xIChT7o9CAhAiN/b93y3KHf9h cECMb9Jv7+BskzsveejP5A1jHW/d3nCRpIJRwTlLIHSvGUcM8twseUzXqM51ow== 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> From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Eli Zaretskii Cc: luangruo@yahoo.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org Subject: Re: More C type errors by default for GCC 14 Date: Thu, 11 May 2023 21:25:53 +0200 In-reply-to: <83ilcz5f5e.fsf@gnu.org> Message-ID: <865y8y8tjr.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_INFOUSMEBIZ,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> Cc: Jonathan Wakely , gcc@gcc.gnu.org >> Date: Thu, 11 May 2023 10:44:47 +0200 >> From: Arsen Arsenovi=C4=87 via Gcc >>=20 >> the current default of accepting this code in C is harmful to those >> who are writing new code, or are learning C. > > People who learn C should be advised to turn on all the warnings, and > should be educated not to ignore any warnings. So this is a red > herring. Indeed they should be - but warning vs. error holds significance. A beginner is much less likely to be writing clever code that allegedly uses these features properly than to be building new code, and simply having made an error that they do not want and will suffer through confused. >> 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. > 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. 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. I doubt the beginner would know to pass =2DWerror=3Dimplicit-function-declaration in this case (or even about Werror... I just told them what -Wall and to read the warnings, which was gleefully ignored) Anyway - I'm not making that up - this circle of 'yeah the warnings actually matter.. a lot' has happened with everyone I've tutored that has had little to no contact with programming before (those who had more contact have a higher respect for the word 'warning'), and it will keep happening. Hell, I've seen professors do it, and for a simple reason: they knew how to write code, not how to use a compiler. That's a big gap. The beginner here can't adapt - they don't know what -Wall means, they just pass it because they were told to do it (if they're lucky!). At the same time, they lose out on what is, IMO, one of the most useful pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables it by default.. we do). It provides effective bug detection, when the code compiles right. It regularly spots bugs that haven't happened yet for me. (and same goes for all the other useful analysis the toolchain can do when it has sufficient information to generate correct code, or more; some of which can't reasonably be a default) (on a related note, IMO it's a shame that the toolchain hides so many possibilities behind 'cult knowledge', depths of many manuals and bad defaults) On the other hand... I've been writing C for a long time, and you have been doing so for a longer time. We see 'error: ...' in an old codebase for a pedantic (rather, by my definition, bare essential) check and we know where to look to fix it or ignore it. I build old, unfamiliar codebases all the time, and I've been using a modified toolchain that enables the error proposed today for a while; my peers and I, who are proposing this, have gone over thousands of old codebases, I've fixed some personally, yet the percentage of those that have been full-out broken by this change is small (configure scripts are almost all of it, too; Po has mentioned that they use a laxer compiler for those - we (Gentoo) test two compilers in order to detect when these differences happen, but keep the results of the laxer one, and then try to fix the code upstream - often it comes down to just running autoconf =2Df, even). This sample is subject to selection bias. My testing targets mostly more modern codebases that have long fixed these errors (if they have active maintainers), and exclusively Free Software, so I expect that the likelyhood that you'll need to run `export CC=3D'gcc -fpermissive' CXX=3D'g++ -fpermissive'` goes up the more you move towards old or more corporate codebases, but, for a veteran, this is no cost at 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=3Dc89 (or a variant of such), or even =2Dfpermissive - assuming that they could even spare to use GCC 14 as opposed to 2.95? 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'. Should that change be reverted? Replacing it with -mmore-than-gprs would make GCC more compatible with this old code. I don't think so. This is a sensitive codebase, and not just because it's written poorly, but because it's a touchy thing it's implementing, any change in compiler requires reverification. The manifestation here has *no* significance. Mind you, this GCC change cost me more than someone seeing 'error: implicit declaration of function ...' before adding -fpermissive would pay when compiling their code with the wrong -std=3D value, because that fails early, and unambiguously, and I had to fight a variety of nonsense to actually debug this error. ... speaking of that, if one builds their codebase without -std=3D.., they're risking more than just optimization changes breaking code that relies on bad assumptions, they're also risking a change in language semantics.. With all that to consider, is it *really* a significant cost to add =2Dfpermissive? Would that cost not be massively overshadowed by the cost of a compiler change? It feels like it's a footnote compared to checking whether added optimizations go against invalid assumptions (which is, by the way, also rectified by adding more hard and easy to see errors). 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: =2D A better reputation for GCC and the GCC project (by showing that we do care for code correctness), =2D More new code being less error prone (by merit of simple errors being detected more often), =2D Less 'cult knowledge' in the garden path, =2D More responsible beginners, and =2D Fewer people being able to effectively paint GNU and/or C/++ as the backwards crowd using a error-prone technique of yesteryear. (and yes, optics matter) Builds break. Builds breaking cleanly is a treat compared to the usual breakage. At least this breaks the few that do break with a positive outcome. Have a lovely evening. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZF1ZaF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTaWoA/3Ibg7JYGag4mH5wH8VwFf4GMWndhVCVBg76 L/SnldsfAP46p08U/amTMCo+WjInPSZyWAlBi5rD+P4yBg9vhwPbAA== =gqsT -----END PGP SIGNATURE----- --=-=-=--