From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by sourceware.org (Postfix) with ESMTPS id 4DAA33858D35 for ; Sun, 14 May 2023 12:46:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4DAA33858D35 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 smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (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-103.mailbox.org (Postfix) with ESMTPS id 4QK2M22BDbz9slX; Sun, 14 May 2023 14:46:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1684068414; 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=tyLy5Yn8piX/MZtNKcFqOi2PSfzOxZ4wmxjiVAOGp/0=; b=16mnW/9lXk4DPzN32/DXCVMswTtM21qt4MROtfjeEZFGEJqzEwnapPlEi0zOwQ1Dbtd612 F4NqSEO9AkiABQ1EwuvF1WdUTDtHn/gdec6SRH6t/oNT78OtumRX8t2jgg1CLWYit4M/k/ lrEVK1x0oVtKJCIUj213P8U5JLN0tWUFyvNK6kR1ag0Ziuwgob2aAXAKgswkoEc3d2NUHY czqqOU9ej7SYq/DUU1a7liM72xai+YABj31ZM1Wp/ROpyslY/tFTXvM2AsxUoILfUOrRWC ahXhzEonAhiwJ9PSgnxaV1d3SArXNrasp5FAHiliZmhbE0goL66EzAA8KVVzzg== 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> <87mt2ab8te.fsf@yahoo.com> <83bkiq3umf.fsf@gnu.org> <87sfc18z66.fsf@yahoo.com> <1cb56b16-1ee0-e233-30f2-464c30d19fd4@gmail.com> <87y1lt6ouy.fsf@yahoo.com> <4ea0b0de-c1f6-0708-eb57-69b4b0e458fc@gmail.com> <87353z7a7o.fsf@yahoo.com> <4b378f94-340d-de5b-c523-e7a5a603c11b@gmail.com> <87ttwf5dq7.fsf@yahoo.com> From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Po Lu Cc: Eli Schwartz , Gabriel Ravier , Jonathan Wakely , Eli Zaretskii , gcc@gcc.gnu.org Subject: Re: More C type errors by default for GCC 14 Date: Sun, 14 May 2023 14:22:31 +0200 In-reply-to: <87ttwf5dq7.fsf@yahoo.com> Message-ID: <86fs7zw05h.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 4QK2M22BDbz9slX X-Spam-Status: No, score=-4.5 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 Po Lu via Gcc writes: ... > Where is it written that GNU CC follows your so-called > ``specification-driven development''? Any development style making documentation a source of truth matches this principle. This does not refer to ISO specifications specifically, though, normally, unless the standard disagrees with reality, as implicit-... did many years ago, ISO decisions are taken seriously. > Here is an explanation from one of the original GCC developers. It > discusses strict aliasing, but the same principles apply here: > > (199909100634.CAA01815@psilocin.gnu.org) > > My comment is similar to Mark's comment. Documentation, what can > we document as working? > > We should not even try to document that these cases work. > Documentation is what we do when we add a feature. > > I am not proposing this as a feature, just as a way to avoid evitable > trouble for users. We should not even try to document a class of > cases that are "supposed" to work, because I'm not saying these are > "supposed" to work. We should just let them work. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Anway, more questions from me than answers... Off hand though, if > we can make the compiler generate `right' code in more cases, even > if the users code is wrong, I think we should probably do it. > > In C, we cannot divide all user code into "right" and "wrong" in this > kind of simple way, and certainly not based on the ISO standard. That > standard is just the decisions of a certain committee (which I was a > member of) about what cases conforming compilers should commit to > support. We must not let ourselves start thinking that C code is > "wrong", just because it is not conforming ISO C code. > > C programs use many cases that are not conforming, but do work. This > will be true for as long as C is used, because changing it would > require major changes in the C language. > > From time to time, there is a real *need* to make some of these cases > stop working, for the sake of some benefit that users want. When this > happens, we should do it; the user community will accept it, because > they will see that it is being done for their sake. Some will > grumble, but the users who appreciate the benefits will convince them. > > But when there is no *need* to break these cases, when we can keep > them working fairly easily, we should keep them working. If we break > them unnecessarily, we invite the legitimate anger of the users. > > and another (199909100634.CAA01812@psilocin.gnu.org): > > However, I have a rather serious objection: it means that users > cannot tell whether their code is valid, even according to the GCC > rules, without knowing the internals of the compiler. > > This has always been true. It is true in the current version of GCC > with regard to aliasing, even when -fstrict-aliasing is used. It is > part of the nature of C. > > The goal of trying to avoid it is unrealistic and misguided; it can't > be done. So this cannot be a valid reason to reject a change. > > The compiler should continue to aggressively break code that > misbehaves in this way. > > This proposes to break users' code, just to bully them into changing > it. That is a callous and harsh attitude towards the users of GCC. > No wonder users are angry. They know that the problems are not due to > necessity, but due to callous disregard for them. > > We cannot do everything all users want, and sometimes a maintainer has > to say no to users. "You cannot please everyone," as the saying goes. > There are many kinds of reasons which can sometimes be good reasons to > say no. > > But maintainers should always say no reluctantly--never eagerly. We > should never aggressively cause trouble for users today, just because > someday it might be necessary. That is like amputating limbs because > someday they might be crushed. > > This treatment of users brings shame on the GNU Project. I ask > everyone therefore not to suggest that we should treat users this way. > >> Sound familiar? A bit like GCC triggering a warning, telling you that >> what you're doing is bad and should not be relied on? > > A diagnostic message is supposed to inform me of a diagnosis by the > translator. The severity of the diagnosis, is, as always, up to the > user to decide, as long as enough information remains for translation to > continue. It is, after this proposal is accepted, still up to the user to decide. The only difference is that the default would be friendlier to new code and users and most code that exists today, rather than to very old code and incorrect code. Additionally, there isn't enough information to compile. The compiler makes up new information to fill in the gaps. If that definition accepted, most error recovery should be turned into valid code paths that participate as GNU extensions, for instance, there's no reason that: int f (int x) { x +=3D 10 return x + 123 } shouldn't compile, as the compiler knows where to insert semicolons to make it (probably) work. I'd say that extension is more acceptable than the ones being proposed into turning into errors by default, since it isn't very ambiguous, unlike an implicit function declaration or such. >> But GCC isn't dropping support for it in semver version anything, just >> guarding its use behind an opt-in flag. > > Which is liable to disappear in the future, as many have before it. It has been 25 years since the addition of -fpermissive to G++. I'm optimistic. Have a lovely day. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZGDYO18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTtMsBAPB185fLKOnkQvMXJNAFXReMvXNE9GScEs0x QTLMbZxwAP9+XsRLuZBY0txL1DH0r1+5swl8+tlwoA5/kXfUQW5zBQ== =/s8v -----END PGP SIGNATURE----- --=-=-=--