From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 184103C17 for ; Wed, 19 Apr 2023 12:06:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681905969; 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=NVkSshTR9QuJEht+3LluR24ojWHKl6beDdD16UGm5rc=; b=da9SnVeVz+7VlFDEXtiPrGx7RbpNMN4a4HIaLewclnnjEh8s3xUhFPYPAHZnI2s5MicveZ hsrwSW0O+9m0r18is66bFpf+73yL04BozzCKQUrfgHVrXanIkEQ66idqaGinBPNowN6fXe W/oSUnJjF7dqgchhq4aZtduzxIGwV5A= 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-190-ZqCcVdIRN7a93k2W17vJNw-1; Wed, 19 Apr 2023 08:06:05 -0400 X-MC-Unique: ZqCcVdIRN7a93k2W17vJNw-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 4F38385A5A3; Wed, 19 Apr 2023 12:06:05 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.50]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8ECF2492B05; Wed, 19 Apr 2023 12:06:04 +0000 (UTC) From: Florian Weimer To: "G. Branden Robinson" Cc: debian-devel@lists.debian.org, debian-gcc@lists.debian.org, c-std-porting@lists.linux.dev Subject: Re: RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.) References: <87y1mpe11q.fsf@oldenburg.str.redhat.com> <20230418225420.qoedd6vam4pkobin@illithid> Date: Wed, 19 Apr 2023 14:06:03 +0200 In-Reply-To: <20230418225420.qoedd6vam4pkobin@illithid> (G. Branden Robinson's message of "Tue, 18 Apr 2023 17:54:20 -0500") Message-ID: <87a5z42i1g.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Precedence: bulk X-Mailing-List: c-std-porting@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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 * G. Branden Robinson: > Perhaps the thing to do here is have, , yet another command-line > option for GCC. The Ada language did something similar a couple of > decades ago to tighten up the language for hard real-time demands, with > what it called the "Ravenscar profile".[1] That proved successful (as > successful as anything was in poor neglected Ada). The C++ front end calls this -fpermissive, which would probably match here as well. > Whatever its name, some advantages to this approach are that > distributors could opt-in to such a thing, make it a clear matter of > policy, and more easily track adoption and progress. You could also > version the contour much like the C standard itself. I'm not sure if we need this fine level of control. Either you want to compile at all costs, or you are willing to make the effort to clean up the sources. At a package level, the required changes are almost always minor (but of course there are packages that are different), so fixing everything in one go (and the implied commitment to keep up with future cleanups_ is not very onerous. For one package, that is. I'm not sure if opt-in is that easy because packages drop build flags all the time. Compiler wrapper scripts might be required. The instrumented compiler we use in Fedora sometimes reveals things that go unnoticed with other approaches. Thanks, Florian