From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 60BBE3858C54 for ; Fri, 12 May 2023 07:28:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 60BBE3858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-50bc4bc2880so14756961a12.2 for ; Fri, 12 May 2023 00:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683876493; x=1686468493; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hC7r6QYpq888L4VjAGAmk+Od7KV/f10kBJsl0+pY5pQ=; b=hz7pZEs1Q8B+27Dg8UjYL7mwQdXgcxOYzyjtUuMm7ic4C0fVPYQ8px8nvgtnFKe1wR PG1XCPFKli9d7u4W40HkECuZ1zmPFQH6IeUtX4c5xgmAJoKozHgnDOEW6WT+ylaAt08W mT0MVBjJ5wYcgbtYtZSXnw8Z86Q7wpzZsq67CB+NHnoUghIaPJ66i5yMmQZ+S6QQxSBu W4g12ftaj4C4zSeEWCKv5I7VBtDfayd/Dn8wShVUqDNMK3BBsKD19m8mkjF9XnHrYSr5 +4TX0QrVZTnyRcr3/0vWRDxATN+zNvJeHrxm9NGDqXtMP29CzOK/+8qcyMN/+nNc75WV 6heQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683876493; x=1686468493; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hC7r6QYpq888L4VjAGAmk+Od7KV/f10kBJsl0+pY5pQ=; b=SNjCj1DCe37JFw5RWESQfXO8Aww6bSWgBanGVozYKCzZ+mFuh9TbVzDQ8rvVyX6C63 XbKKRB4V9jV5Q63iXiZgik4zEkYGQYRMSgHiehmBRaBq1oOisF1XSyig5oW8K1cOFSlC hGeq4pSmaGyxvlVRMast44dkxvZrpGYo/9jrcGytuRASnNbQnqJtoazFzjV0pk1ev7In Od4BNsihSpwW4qdqo7xNYrR+jFxkSbFIdjJfc/x7Syl7GRDCoHsZHoP0Ojs9rnYh0Abi luRLK5lS2hDJqhAsQ3I0DW0tzxO7S6/2K7U9qC/dbFMRyH05uxf7dyR9qsgU0o2F5sni LhdA== X-Gm-Message-State: AC+VfDxkU5g3v1idnbFYWRIuJziV1LHdmvElyWC7rkAzgZ5KIaqo61PH gQaUWK+DfRnDKhckQ18K9QQ1avcDULuxAlEy5yQ= X-Google-Smtp-Source: ACHHUZ7b18lVbheiB/uFDRXalQLPYJ8QJ7GuR3Ebb49y78u7s5LdnXhRCzYkpWyoIoV4TE1ovltk8eHFk/ttJMMVIt8= X-Received: by 2002:a17:907:3e27:b0:965:b517:89a4 with SMTP id hp39-20020a1709073e2700b00965b51789a4mr20313651ejc.56.1683876492676; Fri, 12 May 2023 00:28:12 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <83bkiq3umf.fsf@gnu.org> From: Jonathan Wakely Date: Fri, 12 May 2023 08:28:00 +0100 Message-ID: Subject: Re: More C type errors by default for GCC 14 To: Eli Zaretskii Cc: Eli Schwartz , Po Lu , "gcc@gcc.gnu.org" Content-Type: multipart/alternative; boundary="00000000000031159705fb7a0cb1" 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,HTML_MESSAGE,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: --00000000000031159705fb7a0cb1 Content-Type: text/plain; charset="UTF-8" On Fri, 12 May 2023, 07:56 Eli Zaretskii via Gcc, wrote: > > Date: Thu, 11 May 2023 23:07:55 -0400 > > Cc: gcc@gcc.gnu.org > > From: Eli Schwartz via Gcc > > > > > Being sceptical about the future is perfectly reasonable. > > > > My opinion on this is (still) that if your argument is that you don't > > want -fpermissive or -std=c89 to be removed, you are more than welcome > > to be skeptical about that (either one or both), but I don't see why > > that is on topic for the question of whether things should be moved to > > flags such as those while they do exist. > > It is on topic because there doesn't seem to be anything in the > arguments brought up for this current proposal that couldn't be > brought up in favor of removing -fpermissive. There are no guiding > principles being uttered which allow the current proposal, but will > disallow the removal of -fpermissive. "Let's change a default and add an option to get the old default" is really not the disaster you're making it out to be. You're becoming a laughing stock at this point. The same "let's be more popular > and forthcoming to newbies, and more like Clang" PR-style stuff can > justify both. > It's not about popularity. If that's your takeaway then you're not paying attention, whatever you claim about reading everything in the thread. It's about helping people write correct code, first time, without some of the avoidable traps that C presents. The C ecosystem has a shockingly bad reputation when it comes to security and "just don't write bugs" is naive and ineffective. Maybe you're good enough for that to work, but then you should also be able to cope with a change in defaults. It's time for some defaults to change so that modern C is preferred, and "implicit everything, hope the programmer got it right" requires explicit action, *but it's still possible to do* for the 1970s nostalgia fans. If you want to believe that's the start of a slippery slope, that's your choice. The nostalgia club can always fork gcc if necessary, that's one of the great things about free software. > > We might as well assume that the GCC developers are honest and truthful > > people, otherwise it is *definitely* a waste of time asking them about > > this change in the first place. > > This is not about honesty. No one is questioning the honesty of GCC > developers. What is being questioned are the overriding principles > that should be applied when backward-incompatible changes are > proposed. Are there such principles in GCC development, and if there > are, where are they documented? Or are such discussions just some > ad-hoc disputes, and the results are determined by which party is at > that time more vocal? > GCC has always taken backwards compatibility seriously. That doesn't mean it is the prime directive and can never be violated, but it's absolutely always considered. In this case, changing the default seems appropriate to many people, including those who actually maintain gcc and deal with the consequences of the current defaults. Do you have anything new to add other than repeating the same arguments? We've heard them now, thanks. --00000000000031159705fb7a0cb1--