From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:470:142:3::e]) by sourceware.org (Postfix) with ESMTPS id 377933858439 for ; Wed, 10 May 2023 12:35:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 377933858439 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2eVQ3/m+C2Q3tStSAvHyi+fpcKOIuJTAPUAz+pInwaY=; b=cerIYTC/Nh7l wQy5O2hMPg0TubeUOPLracCTSOKbiArrQ48PJL2YnMZ0Dyw8GJX0SyiwaycIUVClMly8X/NpFI5Mj yOBJikm351uZjvRCf3/CcwSBbRt3IE2FEYiZQKf3Jrd5MAc6wlK2MbtCRSai3dyHx/jO6aiVhnOy/ 46/eOQ4uLHofjEHaYFlXdDOKgtTBZRdljAiOYesA0Wcr7g2K64fneaNBn+ViXIFVIMUSxM1MLnE4J l+OFUccrUAUxc191s6HGPdjfyReLZf0sPJl/b6ZcoFcpzzvlaJzWKDLcpx+EO7rg7O4LyI6u5s0Yc TJUNm6wRThmNd1sbs8g0Ug==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwj2t-0008Vt-Fb; Wed, 10 May 2023 08:35:51 -0400 Date: Wed, 10 May 2023 15:36:56 +0300 Message-Id: <83o7ms8is7.fsf@gnu.org> From: Eli Zaretskii To: Jakub Jelinek Cc: jwakely.gcc@gmail.com, fweimer@redhat.com, gcc@gcc.gnu.org, arsen@aarsen.me In-Reply-To: (message from Jakub Jelinek on Wed, 10 May 2023 14:03:01 +0200) Subject: Re: More C type errors by default for GCC 14 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> X-Spam-Status: No, score=2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > 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. > 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.