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 470753858D28 for ; Thu, 10 Nov 2022 21:44:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 470753858D28 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=1668116696; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eyeKqcJ3W6H7GJzeJ3UDflqecQgnbShJdwv+P2Yh4OY=; b=L7+efDSASvdvzUuiyPH4i/XvsFb7+JmvmGLZpOgbmrFdLDq1+aAkjD8Q/IYuyTLDZEESsS dSOw4YUplSe8bZzkIWoc3YBoi1IilMe8XS0rk+oHrOSTIDM0uqwezmS572QZv5Weao6zdu zU2DJkmeN87yH+hUPUjxQ4LlGGJZis4= 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-83-b46RJJTCPUyd0EIApPCn_g-1; Thu, 10 Nov 2022 16:44:54 -0500 X-MC-Unique: b46RJJTCPUyd0EIApPCn_g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6089B811E7A; Thu, 10 Nov 2022 21:44:54 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 117482024CC6; Thu, 10 Nov 2022 21:44:52 +0000 (UTC) From: Florian Weimer To: Rich Felker Cc: Zack Weinberg , c-std-porting@lists.linux.dev, autoconf@gnu.org, gcc@gcc.gnu.org, cfe-commits@lists.llvm.org Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> <20221110180458.GA7026@brightrain.aerifal.cx> Date: Thu, 10 Nov 2022 22:44:51 +0100 In-Reply-To: <20221110180458.GA7026@brightrain.aerifal.cx> (Rich Felker's message of "Thu, 10 Nov 2022 13:05:01 -0500") Message-ID: <87k042qyb0.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP 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: * Rich Felker: > I've been writing/complaining about autoconf doing this wrong for > decades, with the best writeup around 9 years ago at > https://ewontfix.com/13/. Part of the reason is that this has bitten > musl libc users over and over again due to configure finding symbols > that were intended only as ABI-compat and trying to use them (without > declarations) at the source level, leading to various messes, some of > which we're only just extricating ourselves from now: > > https://git.musl-libc.org/cgit/musl/commit/?id=3D246f1c811448f37a44b41cd8= df8d0ef9736d95f4 > https://git.musl-libc.org/cgit/musl/commit/?id=3D25e6fee27f4a293728dd15b6= 59170e7b9c7db9bc glibc and autoconf use a __stub_ macro handshake to achieve this. It allows you declare and define functions and still have the corresponding autoconf test fail. This facility does not depend on GNU-style symbol versioning. > But aside from issues like this, just the fact that autoconf was > precluding making -Werror=3Dimplicit-function-declaration default must > have wasted tens if not hundreds of thousands of human hours debugging > broken builds. > > What I'd like to see happen is complete deprecation of the autoconf > link-only tests -- only keeping them for use by legacy unmaintained > projects in the form where they actually implicitly include the right > header and test compile and link using that. It may be technically the right thing to do, but for tests that check for more than just symbol presence, we might need something that has a third failure mode=E2=80=94=E2=80=9Ccannot tell=E2=80=9D=E2=80=94beyond =E2= =80=9Cfeature is there=E2=80=9D and =E2=80=9Cfeature is missing=E2=80=9D. With a binary approach, it is just too easy to produc= e a broken test that fails for the wrong reasons. With compile-time testing, such unexpected failures become more likely. Maybe something like =E2=80=9Cif strerror_r exists, it must be usable like this, or usable = like that, but not neither or both at the same time=E2=80=9D. Doing this proper= ly probably needs toolchain support (which is more likely to become generally available in C++ than in C). Thanks, Florian