From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic315-21.consmr.mail.ne1.yahoo.com (sonic315-21.consmr.mail.ne1.yahoo.com [66.163.190.147]) by sourceware.org (Postfix) with ESMTPS id 0CB183858CDA for ; Fri, 12 May 2023 02:08:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0CB183858CDA 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=1683857320; bh=FsT7gEVvuhCVlZrDk2veuwL6A0QNbJu/nzfkzxYhf+c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=FvdrGJHU89U15/1NcdXZmoO99FhyAzl4j1DMwOvsjrrrsbDqeTZtbMKh6+IDaVOfwsadIURrXgpdqAAASVpKIxkHXM2lSCSa4PcyHVwccj7rRtZYDFccAevtkBSWCKzj6+XOhQfx+Gu754l2GSx4mrol6OKvQ3LxAJkz+y4hb8fUmeIyQEN/A3p+ac/lz3JoH5TA0c+9BWmyFYzskPpQ09MYh4QCwOMvlufXtHCkeCYAfTLu7M0D1W+tAYmygF5bfU5JFD9/T01AqnGAk695PqG5E4oj8OjsbSRBOhYI7m5VvRmmMGnYfnCAhaRog9mvDXb23QwY5DMRI/Mchb+Z5w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1683857320; bh=QIOkkkySaNEXDVGiBz6AZxkjh9z4MopzfSNM25dbzzV=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=U3/CFVEne3+BwgFsUrTkH4s9zVQBDkSV4Ij1GTIYif+oId9nX+TwdwWrg8e5vynpvJvotfgNBUK+HF+OkS4jKM6wWnUkRUeAXFApVkSHqdjoMcMbmCij4cKUjpVuBgZfo8IPMQ3wczUGOqDgdSeEFQ39UNCOWb58h2H51Y48TX7tQ2+SP2FptjCeiNCX3AlFY6MsOoVUvfTRQugIVPaflrQLQ0496Hb1GLWc6GCceuwO8+pf44dbvauzyc/xby9i0m5QyoGp97f7RmxiGGFmPmyLzWEXvKPryN5hB0Y/FQmnCcjJDN47GHptRoROSrlIri6dV9qamPyPH3T8f1qqXg== X-YMail-OSG: velInIgVM1mc7mNMa8H1GEin.GGbO3_jDoAd2twwwHro5U8X.rEA3ziJ03gM17n arpfeHJqWtNeZYiitdALIc6rt5jXCOslYy89ByagrZ19EnzDSIq3.MOSh46yB8XMuICGiUTuHyBF ht6Q9gj8q.aySeRbTdSYpdFJjVBM6P5WyDxUux.eEn5cEm4B.u4Gf.wnsYpR5sBfr7EVFFb.V2Y6 s2P0FYxlRjyeuCPNH25JQlEZx_FUWO1r1EAvc4yGTbv51QCFDWwMRaSCOlJug6ktgL655ADGt_NQ 0hp3sbaPaw5rkzHzgWVek6nqwIkS1qWXq.iIIXOfVsu0u5MP.6FSFJg9oBUMn3OjGMyW9hy.m.as xuBxQT_E43vlNQclR.SnTs3xnUi93n.h81oUvkuyqSxQrrmMiS3Qu1jodm6wiFHyTJDwc7uEygnx Fi32SpMu_E9IA3BEc0zwh9ln0sDV9FOJ.zLCYybQhgbbM7CehWo0LFbc2MFasinp0msgcmiUdMCZ VYJKxYbJvQq9Oj25E5avWduCBliyMR51UXpiqGdbcRf5x1Fc9pWG8SJYey39baMP2BwfC4xsOjZi .cd4DtaUUKtScFtNDXv3zffmgF1aIlV1q6_qdpt_wEjKMRkhNI.EXAC7j53lvsbjLlaW9xFo_F17 f4Hig0lhWTFnn2ft6iionamPkjbW1eEcTI7DsQtkvQVo3GhfmQeyJ.xwwVwpmqZitjG6_S5AXpb8 4a2aoZAB6ms8sY5n1dlgBSepvr1IUgr4fw6wJJBJ4uM_vlLa2ZCAPQJAv7L1N1ul4YhCy4r0jVDv OndKags8_Tn_fZyr1wGEUIpTxmL.IffdB_CE8GWCXJdvtKFZK0kzR7GnrGLzMR9JSoJI0wtboHm6 P1g8ZQfRYB8PVYOLuD92PxX2Un2idYS2R6zc4lsQJvk3ZK4oMiO7M44irWLp_i_1CMde6kFH.j3D cx_Bqx53S2SpzIAiaoORoKtdr2lhU9tfmpucJryNfVZTW8CWnDtC8DNuHZI7oiEUEl6bpwfKCsLq 0LtURdevUPhrR3_q9jJvh2fYo_E6R4f5WJKCZreX5qgS7VYa3KYt7S2FwAikC49Oz2MC4NMTedCW jNwQND4kig.um3S1bgemd1MOVAywt_v5yCBBVqBWp1zq5ya35nYHUvl1uDaT_K7W4fyG0tQO3eTL Nsg2nU33YPk4kzscrEOx29uMhBXIuRzgxKyF2slzhSHCh0SRX8jPhx8BWSAmBGpudW3q7P6mGaJo 2l2JsJDbDiMAmvpLMsbo2rAOUFtXD3yxEkJsspdodB_hZM100pWLaSLmjkPlD9aUjo5VblUTV_Ue hc6sse9u5SlScqlr8FYhqLuNzgz5cTpMR1SopAEQSgJlIUAIHYMJwQyI8rRCTniSwdSEkcODR3wj ybdJWv3yf.k4G8.lnsX2_oZ5AEf.sOakPpcA4vIMbwMycXx3uLKWDtsdp4OqM17vrho_ncwn0r.p rb4PMEwRMv6hb8YkvDQWlO3qtzz2dW9NApiUhfYgRNPxvVY2NHLeROqcKBwhymQldtbZ2a7rhmzw vHrWxhiD8zBG.kKsp2_2OFNbiAowj5lmPQdDsiKQqGaVPU94SOSjjSs9W8e9DeEB22lyFzBjIxGS PqSI46tG4quHsFJuWplqKt4_fNKphHe9kTcX.VO4be33di7875S87_X6cEyMhtHW02Gzio6oxZtT iqkndx3GqxQEQwfxJsJRIZJS2qA9TcdrHi3C0xEM6oqQtK2thrdkVf1ANk9B8D0eRyhHaKFpxGiu O_5JmThoGWh9nTURuAE_xyJpJQn2RRpRQDCOYY9m_DAqHwSLa.FjqnIQjQ9ptBTRWRwho9vAKvkY QzDNc4asvUQA7tNjLgPT4OmlfxXjd1mZzG0lcuhxq.N7REygRGr.THnqC51_9QDS6NofNpHJlKmK RrOc38IHb9jZz5JT8GBh14.CqTmu_8yPGH6YfPixZZXRefpxcB0Ux8n9LPG5udyjBooEuGAYh.BD Dx1PyF9HJ0DaWGTvnGNWlTAMPcrWTQ15t4l.5otC74THHth.3r7hzNwlSv_77f1IvMpgMxo3MQel u2VdrKYOH7ntJRV.4H0xq9atH_eLZbv39_D4owgqlj2GE5feXnGe6QaUAx8hEkuMyhinaAoY9g2b mVeE9sXj_0S879.gX3W5K2HYqS295HaPBvXlKCA6LCz_x3J90.V38OSdFVPRM5FifJptnLNlRCCI zoTxiYjLf5BvMT3DFoFjphsyS_3kPVUBbcW6NoiGvmZH2Ke8WySyVunJ8S3aM_J1D2w-- X-Sonic-MF: X-Sonic-ID: 415ba961-88a2-460b-b27e-9f07e1718bb3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Fri, 12 May 2023 02:08:40 +0000 Received: by hermes--production-sg3-748897c457-vf9wl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ea47d361176ab9d534210ac59756e1f2; Fri, 12 May 2023 02:08:33 +0000 (UTC) From: Po Lu To: Eli Schwartz Cc: gcc@gcc.gnu.org Subject: Re: More C type errors by default for GCC 14 In-Reply-To: <4d2af697-2f28-9e17-6b35-3a4ba19313d2@gmail.com> (Eli Schwartz's message of "Thu, 11 May 2023 18:41:48 -0400") References: <87mt2behdl.fsf@yahoo.com> <57238276-5966-98d6-d5f0-f5451013ed17@gmail.com> <871qjned25.fsf@yahoo.com> <67e65b41-5400-d1c2-9f43-f94d0ea7da9b@gmail.com> <87wn1fcrw4.fsf@yahoo.com> <4d2af697-2f28-9e17-6b35-3a4ba19313d2@gmail.com> Date: Fri, 12 May 2023 10:08:29 +0800 Message-ID: <87mt2ab8te.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: Eli Schwartz writes: > I expect no such thing, but I do expect that people making decisions in > the real world acknowledge that ***they*** (and no one else) made those > decisions of their own volition. > > I am unsure what "decisions made in the real world" has to do with my > observation that this real-world decision was a decision to invest time > and effort and money in one direction rather than another direction -- > and the rejected other direction was the one that would make them users > of GCC who are affected by GCC decisions. The point is, we chose not to modify GCC for various reasons, and the changes being proposed here will cause more people to make this choice. > I do not consider that you are being told what to do with your code. > Your code is not being broken. You may have to update your Makefile to ^^^^^^^^^^^^^^^^^^^^ My code is being broken. There are thousands of Makefiles, Autoconf files containing configure tests, and so on. > add a flag that turns off a changed default, but that does not > constitute being told what to do with your code, only being told what to > do with GCC. That's GCC trying to tell me what to do with my own code. > Very well then, (lots of) C++ is C. > > But many people do in fact argue that missing function declarations do > not, in fact, look like C. It doesn't compile in a C compiler (using ^^^^^^^^^^ % cc -V cc: Studio 12.5 Sun C 5.14 SunOS_i386 2016/05/31 % cc -Xs -Werror hello.c -o hello % ./hello hello world the time is: 1683856188 % cat hello.c struct timeval { long tv_sec; long tv_usec; }; main () { struct timeval tv; printf ("hello world\n"); if (gettimeofday (&tv, 0L)) exit (1); printf ("the time is: %ld\n", tv.tv_sec); } % > -Werror) either. Some of the warnings under discussion in this thread > were never valid *anywhere*. Really? Is that, or is that not, a C compiler? > Some people like writing some code in one language version, and some > code in another language version, and doing so in the same file or > perhaps even the same function. Acknowledged. I would personally be > afraid to do that, it seems incredibly dangerous even if in the highly > specific case of implicit function declarations it happened to work. > > Because that's exactly what is going on here. Features that were valid > C89 code are being used in a GNU99 or GNU11 code file, despite that > ***not*** being valid GNU99 or GNU11 code. How GCC currently behaves defines what is valid GNU C. > The fact that it compiles with a warning in GNU99 or GNU11 mode doesn't > make it a GNU extension. It compiles with a warning in c11 mode too, > does that make it a c11 extension? No it does not. Except it does? Since the compiler is defining behavior that is otherwise undefined (i.e. the behavior of a program after a diagnostic is emitted after encountering an erroneous construct), it is defining an extension. > I am not dictating anything to you or anyone else in this paragraph, > though? All I said was that if one writes a c89 program and tells the > compiler that, then they will not even notice this entire discussion to > begin with. > > What, precisely, have I dictated? That people who are writing GNU C code should be forced to rewrite their code in ANSI C, in order to make use of GNU C extensions to the 1999 Standard. > Have I dictated to you that a c89 program can be described to the > compiler by use of the -std=c89 flag? This seems to be a pretty standard > understanding, to me. No, see above. > Correction: I am arguing by analogy that your statement: "what > guarantees that -Wno-implicit will not be removed in the future" is > arguing to absurdity. The reason I asked for such a guarantee was that two important options were in fact removed by the GCC developers in the past: -traditional and -fwritable-strings. So there is not exactly a good track record of keeping useful options around, after features are made into those arguments. > Many people write strictly conforming program, and consider lack of > conformance to be a coding error that must be fixed. It seems like a > wise endeavor, frankly. I am not sure why you are challenging me to do > so as though you think that I will be incapable of it and therefore be > forced to concede that toggling the default diagnostic for very old code > is a bad idea. Really? So how many programs work when int is 16, 36, or 40 bits wide? How many programs work when signed char has trap representations? How many programs when char not 8 bits? How many programs assume pointers can be converted into an integer type without any loss of information? How many programs assume that pointers have only one possible integer representation? (think lookup tables using pointers to objects as keys) How many programs assume NULL is all-bits-zero? IOW, that this initialization makes sense: struct foo { void *ptr; int xxxxx; }; ... struct foo foo; memset (&foo, 0, sizeof foo); if (foo.ptr != 0) /* here, 0 is a null pointer constant, NOT zero */ How many programs assume that arithmetic comparisons between pointers to different objects are defined behavior? (think anything that involves sorting and comparing different objects, i.e. binary trees) And how many programs written today even work at all when `int32_t' (and similar types) are not defined in stdint.h? How many programs use external identifiers that require more than six (or thirty-two) significant characters, or case significance? A strictly conforming program cannot make ANY of these assumptions: A strictly conforming program shall use only those features of the language and library specified in this International Standard.) It shall not produce output dependent on any unspecified, undefined, or ^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation-defined behavior, and shall not exceed any minimum ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ and as a result, they are very rarely seen. > However, it does appear that we are still stuck in confusion here, > because you think that GCC is no longer able to compile such code, when > in fact it is able to. It won't, not by default. > Maybe I was unclear, allow me to rephrase. > > If a future proposal to GCC results in GCC becoming unable to compile > some code, then and only then should we worry about the existence of > such a proposal. > > Since no such proposal has been made, it is a slippery slope fallacy to > argue that ***this*** proposal constitutes a threat to users' ability to > compile their code (even their implicit-function-declarations code). > > I do not believe it is reasonable to: > > - engage in tons of argumentation and insist that it's a bad move for > GCC 14 to change a default and add a flag to get back the old default > > by claiming that it would be bad for users if: > > - GCC 16 deletes the flag for getting back the old default I'm sorry, but this is what people have seen repeatedly happen over the years. Thus, > If it is proposed to delete the flag for getting back the old default, > then and only then do people with old codebases have a valid complaint > that GCC is becoming unusable for their purposes. Being sceptical about the future is perfectly reasonable.