From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 4C2BB3856DE5 for ; Wed, 10 May 2023 12:41:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4C2BB3856DE5 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-ej1-x62e.google.com with SMTP id a640c23a62f3a-965d2749e2eso1005816566b.1 for ; Wed, 10 May 2023 05:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683722490; x=1686314490; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=j2mpjISGI9QkBI/Ap2LINKpDGLEiqp9xKbVXmMFpBXM=; b=DhUpzBTerunrfOnN2FVFBab3jwpwssQuBrp4xHU2tSsr7wIBXsZF//rGSITWzpM9OY CY4/2jYq3SwZcS2HYrfdJNmxh28PzDhCNSyeW87iYKsUFAq/XcQTJPP6PrIhr0G65kOv fifN3VUwLqRVeoY+Ktb0I58S3YYHsUJmYOKK1fFZpflwI3cUJrtBhfKGdjYlLMl8RG3B GaCg2llOQktfnSIp/O7m/ZYvLqT+IMoPDWKhb/huJCJz5AiQ/LEYekw0kKeYncTm8xrU YMlUu98SZxtEE/773m34WuGoS5ybUnN61aD4gFaA8kCVS2ryX6a87i7/5VmO61ZpjJC6 gEKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683722490; x=1686314490; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=j2mpjISGI9QkBI/Ap2LINKpDGLEiqp9xKbVXmMFpBXM=; b=dTp2Yu7BWLcEr9U073Ud9DTpmONXMgA5rQsWumQ7T5UJFTpxcCJco1DtENxF+9Ehy4 lYGpvsRq9qUe0KialU+A7zj4mt08fI+TlkXUq1fCN5mign44iqdcxPMD1W26PzZJnCNU QMp7gsikNRfUU6JZ4i5KDkj4OZvgazTYyoK+kZya+nmewGxkTLzPv0rUpe1PMloXeHce YO67I7DgWP4vV2fmNUYXlikzgk9oIJ8ii7b93/bfT5rFKZDP5maZ4Zw2viQ19ZMb2n2c hpyTahgevT375eI2K8TVuiuY7KRugVpmUqOWvRpVyh+EaF/1YyChaalloMdNMQ47Ekfx Jw+g== X-Gm-Message-State: AC+VfDwnRM0xoJlzLOWB9nopRICIJScfrkbgzvUBZVXOf1Yg1X82TaaP vtN05911rsQ0wq482UMsiMw= X-Google-Smtp-Source: ACHHUZ7uZlSgTgvhRTDU7UYeW6rLkHWop2HGKbFKYNLlqvDZ52RMypvj2gK+npJr21hfzWHzOxqK2w== X-Received: by 2002:a17:907:3203:b0:94a:8f3a:1a77 with SMTP id xg3-20020a170907320300b0094a8f3a1a77mr15413826ejb.8.1683722489833; Wed, 10 May 2023 05:41:29 -0700 (PDT) Received: from [10.39.0.3] ([194.126.177.53]) by smtp.gmail.com with ESMTPSA id mm30-20020a170906cc5e00b0096595cc87cesm2632858ejb.132.2023.05.10.05.41.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 May 2023 05:41:29 -0700 (PDT) Message-ID: <2ffbf210-1b58-737b-888c-4f84c5cc5e0f@gmail.com> Date: Wed, 10 May 2023 14:41:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: More C type errors by default for GCC 14 Content-Language: en-US To: Eli Zaretskii , Jakub Jelinek Cc: jwakely.gcc@gmail.com, fweimer@redhat.com, gcc@gcc.gnu.org, arsen@aarsen.me References: <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> <831qjoa0g0.fsf@gnu.org> <83o7ms8is7.fsf@gnu.org> From: Gabriel Ravier In-Reply-To: <83o7ms8is7.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 5/10/23 14:36, Eli Zaretskii via Gcc wrote: >> Date: Wed, 10 May 2023 14:03:01 +0200 >> From: Jakub Jelinek >> Cc: Jonathan Wakely , fweimer@redhat.com, >> gcc@gcc.gnu.org, arsen@aarsen.me >> >>>> Why should this compile? >>> Because GCC is capable of compiling it. >> That is not a good argument. GCC is capable of compiling any code in all >> the reported accepts-invalid bugs on which it doesn't ICE. That doesn't >> mean those bugs shouldn't be fixed. > Fixing those bugs, if they are bugs, is not the job of the compiler. > It's the job of the programmer, who is the one that knows what the > code was supposed to do. If there's a significant risk that the code > is a mistake or might behave in problematic ways, a warning to that > effect is more than enough. Are you seriously saying that no accepts-invalid bug should ever be fixed under any circumstances on the basis that some programmers might rely on code exploiting that bug ?? >> C99 for the above says: > I know what the standard says, but since when do we in the GNU project > accept standards as a dictate? We do what we consider to be best for > our users, and follow the standards when that doesn't contradict what > we think is best for the users. GCC has, for example, -std=gnu99 > etc. precisely for that purpose. > >> The proposal is essentially to stop accepting this as a GNU extension >> which was added for K&R compatibility I assume and do that only for C99 and >> later. > I understand. I'm saying that there's no reason to make this an > error, because it will break builds that have good reasons for keeping > such code. > >> Note, this isn't valid even in C89 and is already rejected with >> -pedantic-errors for years. > Terrific! Rejecting such code given a non-default option is _exactly_ > what should be done. But we here are discussing the default behavior. > >>> It compiles today with a warning, so that whoever is interested to fix >>> the code, can do that already. The issue at hand is not whether to >>> flag the code as highly suspicious, the issue at hand is whether >>> upgrade the warning to errors. So let's talk about the issue at hand, >>> not about something else, okay? >> We do such changes several times a year, where we reject something that has >> been previously accepted in older standards, admittedly mostly in C++. > And that is a Good Thing? I don't think so. Maybe for C++ it's > inevitable, I'm not an expert on that. But making breaking changes is > inherently BAD and should be avoided. > >> Yes, it is done far less in C, but still, as the above is invalid already in >> C89, users had over 3 decades to fix their code, and in many cases they >> didn't and without this move they will never bother. > Please consider those cases where the code cannot be "fixed", in > practice. I described one such situation in a previous message. > >> A lot of such broken code has been even written in those 3 decades, doesn't >> predate it, but because the compiler just warned on it, it still appeared in >> the code bases. If we wait with this change another 2 decades, nothing will >> change and we'll have the same problem then. > GCC is not responsible for the existence of that code. So GCC > shouldn't change its decades-long behavior just because that code is > there. there must be a much more serious reason for such changes, > something that affects GCC itself.