From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B99B538582AB for ; Wed, 10 May 2023 13:57:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B99B538582AB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683727039; 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=pB6zWdTJM9hYAmH32Cwhz0aFusPV/1ArecEGwbfXDBo=; b=dkevto1/bFeKr0rOyIfW8FF6cZE7wExS+ygsEZdJdD0G9lQccZVgouNqxO6IqbgLyiOOsB /EHp4o29rUo0+eAvOg95OyMUWAdvIVCSTaRi3jKJXvNtHd6pBCClD+7ro6WuREtVSV5bLC mjUaWEnOb1haxeBYL/TWYBF5BeU8vpM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-295-grZNYaNNNeuLO9J2MjvNMg-1; Wed, 10 May 2023 09:57:16 -0400 X-MC-Unique: grZNYaNNNeuLO9J2MjvNMg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C52E089C7F0; Wed, 10 May 2023 13:57:15 +0000 (UTC) Received: from oldenburg3.str.redhat.com (unknown [10.39.195.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1290048FB11; Wed, 10 May 2023 13:57:13 +0000 (UTC) From: Florian Weimer To: Thomas Koenig via Gcc Cc: Thomas Koenig Subject: Re: More C type errors by default for GCC 14 References: <877cth66qb.fsf@oldenburg.str.redhat.com> <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net> <87r0rp5uf8.fsf@aarsen.me> <83ttwla1ep.fsf@gnu.org> <83lehx9vix.fsf@gnu.org> <83fs859unu.fsf@gnu.org> <8e51f57b-a1e0-508a-a69f-d5efdeaf814e@netcologne.de> Date: Wed, 10 May 2023 15:57:11 +0200 In-Reply-To: <8e51f57b-a1e0-508a-a69f-d5efdeaf814e@netcologne.de> (Thomas Koenig via Gcc's message of "Tue, 9 May 2023 23:00:56 +0200") Message-ID: <87ild0p9vs.fsf@oldenburg3.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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: * Thomas Koenig via Gcc: > So... using an error message as a crowbar to change people's behavior > failed, at least partially. And you only hear from the people who > complain, not from those who are glad that they found errors that they > would otherwise have missed. Thank you for sharing the Fortran perspective. I think the C changes are a bit different. Most of these fixes are of a localized nature, and there is always an ugly escape hatch for missing function declarations (write a prototype declaration right next to the call site). Most packages we fixed required a small number of changes, and where maintainers reacted, they weren't opposed to making the changes (maybe with one exception). These changes do not create an ongoing maintenance burden. Admittedly, there are some packages where the sheer number of issues makes patchings things up difficult, or the state (and presumed lack of use) of a program may make creating patches look like a waste of time. But in the Fedora corpus, these cases are quite rare. Popular packages for which we do not have a migration story yet are ksh, procmail, unzip, zip. For the latter three, part of the problem is that it's not clear to what extent legacy systems (pre-C89, maybe even pre-K&R, without or ) still need to be supported. These cases are the exception, though. In those cases, there could be a strong incentive to make as few changes as possible (so telling the compiler to keep accepting these obsolete constructs). Thanks, Florian