From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic302-20.consmr.mail.ne1.yahoo.com (sonic302-20.consmr.mail.ne1.yahoo.com [66.163.186.146]) by sourceware.org (Postfix) with ESMTPS id D40F53858CDA for ; Fri, 12 May 2023 01:42:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D40F53858CDA Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=yahoo.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1683855740; bh=farh3osMjW+zonX2PAb6q8TXxTDDQJwPVlCYmDqYJ/k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=QwsroHHiml+i/t7yYyjE+tbvoZNzG+ep78t/5eXzM8CyGX68MjBOT+rpIJgKRcOhMxuHQUSoIcmt8WfLrs/4LhH1pyzrIW0CoAE+aVC78zAoHysPl6Qtx/FANBcPicm5zjX00I+M5xUSX1PFr9leoMoziFSa/pJfKWkoISiLYoiYtOCnC+AviKvlZYjFbcpfWUFJ+YktI2SpDM3pikDkNDkH2DVZJeBQM9f+KHlDA5/KU5MhiOQK4G0nztxu0iWt9Z9fMFMONpaW5vumifPV488JiuvqwR/9LDPzszgI15TnEgxTm5+yxigYdPudc3be3vZTJG9FApPUR74KQ7nW5g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1683855740; bh=ygMiLcB9YOk/mLmz6YPPPeW8HOAdfuw/gu6v3huweFy=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=lyEp54PCW6ynU85a/eGRVA8Q40AqYAKoa5dl+sQUltBQfhEbqsYx7gXCFkmcgNXur2xnlgIVzrh063idclh7FNinMxqecJ6Q8nQWHgtc5YFgGOwtj5EIsibUkUL8aD3fszswj8ajjjbuL+7WZX2YN3v1wOdRlZX2Qobd/hUtQz3gsubRgz0bdFWUfxzmu6BbgHkMxGmzrTbhD3dCApbeO8oZw2NYzO3I0CUrUoff+1lzhuDo/+AICHkemfRV+nI7pTKo8YZZtABCbFp0sc/Ua1q9QTRVME7q8VnEj7Nj1OnySsrEBLLb1eZ82C7KuaEpLZYawraZWj2H5mmtQSYpBg== X-YMail-OSG: 3vbmepAVM1mU4AzwPNlgsXVLvUFaluwPGe6fuY4PyCZxlW6MzkL8AXfzp03bIZW lWMAxWa2f1jOuTfus8LgJtcIEG2QHH_LeKrFDNlyVLu0hANidbaWyXU9dI4etKsVW7N5jTVob5._ ZFRSpxp9MRlxOG1o44V79KUYSOoSncZxtC4D6SAbFOtNS1lwWFs6tT2QHsNRGlicjC5kZ..tOxLr 5BV_64ppDR8Of5v9Ch9cBG2saFSatnXM8LMELRHLD0LPSbwQ82fh2w.hlpQRervXItcxSsK8HFSO x_jarau.BIO5PR3gWtNkldr3qiv77tSBRJ0A.KAv4TyDfaf5CGX_IY4Vv40gTpnhiv_SgnhA0hSu tgoSmzxlxSfZC5AoNNCuUgjZfkys86a3SVXnDQKJm6I5mTZBopWsuYyTZqRf2PIZiGchUiS6bUtR luEqu5X5pc8VJ_PcylS4jWlsB.rW66Qd6AA2lMaVxezSS7cwUC7AX0x7wzpcD9BIGk5AgCPPQeBh jd0f9u6MeM.vt1edPKlIqa_JWDrAgeNY7JK4EfUc58bGkJBJqm9.sfr98X.lH3wemU25AuTz2RAg VdLnvbRmhWGoNCDAb3Abp5rWNE5K9wgm8aqBPCgB8bO33ngxKVl8aBY5.03E7mGFWg43VLcSkd6K dklTdA9.AluD6W1qNKsxtw3YwUgrJBeHTPiW_AjQMaFP84sbbkvc7KzvF72J7preOjOmfYKEq6Ny hoSw8ReEUoj5woWNQgdhxD5VfocC6GgY_DBubALr5wHt_JMrbikAoPb7icZ2s1sZvE1tLDAwIrkB fjLunhuaHBZR1fJouFCOT1SZ3OCkalvE756pE9ZdANy_jdMB93_zC0bt_Mz85pS85OBhZCmMC89. P8o5qBYV46kRIkhwsW.nVyujkOzEhq4.nmmDkXGI039M6GJUL1W2H2FZ0FcSgXuQrMeKrX1NR86c H3BoykjmdoNcQVJ9DBb1zJUY6.i8ZafRYsSaM7ap_P4Z1QeFwqyTfOuZYyLNBDVkoG8210FpQG40 TU5T0P75LrQ0cA4dZWtcspsMbp3cLpwaZ7eho.nwGQNUtMRVWn1t2ciMQwc0D6JJSVMKmBTSbkl_ _tvPrQzjsv3Pmjd4T7t8ryTflv0bbVJacoBohKSRKCG1CPS_nxZbz43hAsrOh9SDnIs9PttvyUPl a.McYAUKcBoh5oSmv8EyOlORXR.m3YS7nYcbDrRCx6Uw.qg4dP4OXYR_Ya_WX4.SvKYeMDxxAxaI wKxs.zPVe1GPAw8izk.Zy5Tj__0RQC0u7LWxRLblu2ix3H4zEpmOgawtrL6avnSoVwvSyuClkTkX oRw7DtAhgkCkqom0unlZpIgcYS.dm1_kl4dY9qmhFHEuTkqaTaMn2w38gKExr9.CexOHuR77YHqU OeFdxn0P39.1808F87u1f3mnlaFRYVDacmzHnfEKtctYhavcYsazVaRe5GzAjqQddl0YQC8k1gJq W54z1mnKyKxTy.c6jqkJVbmBTxzJcsHsRICs4KAVOGTICNuF1rh3KCr_Md1scdyo30ugccyF0.LM 95BTXIFTaJnJe.icMnlT5WzTpe9x3sHmmakYIxDf9gvyBmzEr6AItYtX357IyJa9qzO1k62KwmnQ dMFi6tdfICeAmHlsK3ubLsRUsSvICoWOZdwwH5CKyHvmLuZlroW7e5yF2QfbgiVQrCS3bfwj7X7x Q8VrCO6ApPBAvSVLBiyF6pXTqDbG3gYDzrBqAo50no5ndK0UDX8WWGNs0sl3c06x4R_auYhRLuc5 vsvoYJqGj_2PbrMgOrmu0ItKa9_OUHtR4x2smdk6q1p0t5T50.gGJxQm882S0aCrRxOhkwOp4HN0 I51lLQpgmzeYc9BucPC5LvkIcg2SdCzTsiRSynM8IE6da4HYOYV_hTBsSrWcLxvHOBofdBYv3GEx hE5Fux8XPIII71UpUzdMOMHLlJb16UZWHkEYIoNsgejaaPMAcdigwSPrysZS.As3gitmkYISP8lv MVKZFVMtEcKjYIVLoTwvEtBssfJUYpfH3etrQzgwu6KNo3tFShVgGQXwbAzAZCdT6elt5O2DvTsM nAHotxwV1MOQ1k9hZWK.tZBksZ7AWJKfNmTUnZTpmzjisKYu6gpdqn_2kdAzJ2.xvU95vdR1sOEk hpbc5ap4iGFKyjoUtivCA7mONN9_O1Fr6TwQs1JCabjRWcaiMMSXbNtRs_R_TGv9fPVzfdmt58_. kBClH41ygnsHV5CWnHiBf.A..pVHBRDsDgRDuITMX_mxJ7RyPvGZB_EENxpAVWjgi X-Sonic-MF: X-Sonic-ID: 8a564720-a15b-4cc3-895f-37c65fb7dd1d Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Fri, 12 May 2023 01:42:20 +0000 Received: by hermes--production-sg3-748897c457-ppt9c (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 95795a7c36e96c0136e7d989e4804806; Fri, 12 May 2023 01:42:15 +0000 (UTC) From: Po Lu To: Arsen =?utf-8?Q?Arsenovi=C4=87?= Cc: Jonathan Wakely , gcc@gcc.gnu.org Subject: Re: More C type errors by default for GCC 14 In-Reply-To: <8635424kxf.fsf@aarsen.me> ("Arsen =?utf-8?Q?Arsenovi=C4=87?= =?utf-8?Q?=22's?= message of "Thu, 11 May 2023 23:10:42 +0200") 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> <87zg6bb4k4.fsf@yahoo.com> <8635424kxf.fsf@aarsen.me> Date: Fri, 12 May 2023 09:41:58 +0800 Message-ID: <87r0rmba1l.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.21471 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,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: Arsen Arsenovi=C4=87 writes: > Seems that the algorithm and I agree. I don't see any use in the int() > guess that the compiler does, besides accepting old code (which makes it > candidate for -fpermissive). I believe: extern int foo (); covers at least 50% of all C functions, since they are generally defined to return int (as an error indication) with no narrow types in any prototyped parameter list. That's a reasonable enough guess. > We can diagnose these without invoking expensive machinery, unlike > mismatched declarations. How so? Remember that `extern int foo ()' declares a function with no parameter specification returning int. Thus, it could mean either: foo (a, b) char *a; long b; or foo (x, y) double x; double y; or perhaps even foo (va_alist) va_dcl The function may even be defined with a prototyped parameter list, as long as said parameter list does not contain any narrow types which are subject to default argument promotions. > I don't see why these not being diagnosed by default makes erroring on > the far simpler implicit case not valuable (even if it leads to people > just consciously inserting wrong declarations - that means they > acknowledged it and made a poor decision). All this will lead to is people making what you deem to be a ``poor'' decision. Especially if the people who have to solve the build problems are not the original author(s) of the program being built. > They can be caught in multiple places when obvious, such as when not > done explicitly. These are two different errors. An implicit function declaration is NOT an obvious error. It simply may be an error. What is the error here? a (b, c) long c; { return pokeaddr (c, b * FOO); } /* in another translation unit */ b () { a (1, 0L); } GCC is not a judge of other people's code, and shouldn't try to be one. > I can't say. I don't have memory of the traditional mode outside of > cpp. -traditional tried to make GCC a K&R compiler. It wasn't completely K&R, but it worked well enough for most cases. There, - `extern' definitions take effect even outside the scope in which they are declared. - typeof, inline, signed, const and volatile are not recognized. - unsigned narrow types promote to unsigned int. - string constants are always writable. (BTW, -fwritable-strings was also removed, so you can see why I'm sceptical about any commitment to `-fpermissive' if it is ever introduced.) - register allocation is not performed within functions that call setjmp. - bit-fields are always unsigned. - single precision floating point arithmetic is carried out in double precision. - __STDC__ is not defined. > The changes proposed today, however, are a few bits of entropy > relevant in a few places - the overhead is low. Yet it's rather pointless, as I explained above. > It's not, though. That's why this is being conversed about. Even > highly diligent people miss these (and even not-so-diligent people like > me do - I've had more of these found by me passing -flto than I did by > remembering to use an extra four -Werror=3D... flags, and that, of course, > misses the int(...) case - which is not a useful one, usually what I > meant there was (void), but strict-prototypes are a story for another > day or year). I can't say I've seen any such errors myself. Perhaps people should be told to run lint instead, whose sole job is to prevent these errors from happening?