From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id 5C6243856240 for ; Fri, 12 May 2023 13:25:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5C6243856240 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-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-3f4271185daso58009275e9.2 for ; Fri, 12 May 2023 06:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683897922; x=1686489922; 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=ybaWgRovAv8SCNPJiV1i/XKQgLHhxdX8P6qF0NkPCO8=; b=szDe8DAyLNhF9I0X7fmM2yHqVxECOglOr0W+pDBREtuihBTNwSwy2sfj7+++4/Mlsv 8jMy0friOtg2XV29b5K5NAp9mmdv533NUDQoZ//7PZb7NrKvVYEdDU7yigbehXC/zA56 wjVvL043qO/eYiS/wPxPrOUA5Bo+LWch2CsdYCG9mYxFc4p5/dKYHBTfBTDPyKTaft/p KjuX1MdpATZpH+cZ+MlVCzzrx0Jhvp/dUn26TcmBb2ZZzJX8g9B1L9bgObjwYCHF47V4 j0usT0s1cXpEpUeJ0JpqCGix/vrnZEXTv1UPr3Gm+/jcgzTqsyvV4ISAXuRLWs34kGRK eCVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683897922; x=1686489922; 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=ybaWgRovAv8SCNPJiV1i/XKQgLHhxdX8P6qF0NkPCO8=; b=dUaFtguBj9ViMm27+ezrYJEaXBCJ1nQI/Tk2ozfYCYlkK2gxfdgGDy8fkr3DnpuuUg k4XV4fFE6EQDc8yBwU051ejwkisPRXNJdf+wSB1AaJoxSVQVzBzsXhWLcODKYvusM4Pu NWy/nHugCM1KjL7genstgWmMqoT7We1eUpQiaonuvwkfv1B+02RP1o/E7kGMYt92z/i4 sQCR2rDFl5DeGg8MFNZ4YPkq2U2oiKYvq+LbdIn3j6hXzyExqco5IRKooJIDP0LwnOKR irU07cPItkxuTbY+QIsf6SHfPooq8fmiCGsU24jbuatyZzgJP3bMbWTfHHMhHcEFD1NI p55g== X-Gm-Message-State: AC+VfDzCsZRwNbg/8ncJ7lUmXO/lQamlLD8DJy8YaohIDki71ngc4n92 0HQef1IfIHz/aH+Zft0Y3HG502W/sA+SEw== X-Google-Smtp-Source: ACHHUZ5TK84cM6bKTkTub9sDqqckxvzaF+noAyqe3S0Gxrxx1pZRvCp0ztzA9fsPvMUQBQyWtGfBgg== X-Received: by 2002:a7b:cd85:0:b0:3f4:f8c0:8a48 with SMTP id y5-20020a7bcd85000000b003f4f8c08a48mr1047078wmj.24.1683897921794; Fri, 12 May 2023 06:25:21 -0700 (PDT) Received: from [10.31.0.11] ([194.126.177.88]) by smtp.gmail.com with ESMTPSA id f8-20020a7bcd08000000b003f42894ebe2sm12876829wmj.23.2023.05.12.06.25.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 May 2023 06:25:21 -0700 (PDT) Message-ID: <1cb56b16-1ee0-e233-30f2-464c30d19fd4@gmail.com> Date: Fri, 12 May 2023 15:25:20 +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: Po Lu , Jonathan Wakely Cc: Eli Zaretskii , Eli Schwartz , "gcc@gcc.gnu.org" 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> From: Gabriel Ravier In-Reply-To: <87sfc18z66.fsf@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.3 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/12/23 15:19, Po Lu via Gcc wrote: > Jonathan Wakely writes: > >> 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. > Right, and how many percent of those came from implicit function > declarations? Implicit int? Extern declarations in function scope > being applied at file scope? Arithmetic between floats being done as > doubles? Narrow-type promotion to unsigned int? > >> 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. > It is impossible for implicit int to lead to bugs. ...You're joking, right ? You can't possibly be seriously arguing this, you have to be kidding... right ? > >> 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. > I am not part of a nostalgia club, so you might as well stop using this > label. In courtrooms, the plantiffs may be precluded from using > terminology that can mislead the jury. This is more or less equivalent. > >> 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. > What consequences? Really? > >> Do you have anything new to add other than repeating the same >> arguments? We've heard them now, thanks. > Yes, just these quotes from a former GCC maintainer: > > 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: > > You are arguing for a position that rejects the very idea of making an > effort to keep old code working. Your arguments support a general > conclusion that "If code is not unambiguously valid, it is better to > break the code than to keep it working." > > This is not just a harsh policy, it is an explicit policy of being > harsh. That is, it says, "Be harsh! Choose the alternative that is > harsh!" This is the opposite of the way we should treat our users. > > I understand that your views are not based on sadism or cruelty; you > think that treating users harshly is better for them. But your > motivation, like my motivation, is not the issue anyway. To adopt a > policy of harshness towards people--no matter what justification is > offered for it--is treating them badly. That is the wrong way to > treat the users. We must not make GCC decisions based on a policy of > harshness. > > I would like future GCC decisions to be based on the policy that > keeping old code working is a good thing to do, when it is practical > of course. > > So if any argument leads to the conclusion that one should be harsh to > the users, please recognize where the argument is taking you, and > reject it on the grounds that it is a disguised policy of harshness. > > In particular, if it is argued that a policy of kindness has a > disadvantage, and it turns out that the disadvantage is a consequence > of the fact that the users have been treated kindly, it is really a > disguised policy of harshness. > > It is sad that this mature attitude no longer seems to be prevalent > among the current maintainership.