From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by sourceware.org (Postfix) with ESMTPS id 45587384F032 for ; Sat, 12 Nov 2022 03:23:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 45587384F032 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1A4F05C0127; Fri, 11 Nov 2022 22:23:58 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 11 Nov 2022 22:23:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1668223438; x= 1668309838; bh=GB+WM3wS4WdxHjLxnFHp1BWh1TxS5aDksAR3+zvmPns=; b=d ZBK09NZaR6JNmcxleIi4agOxmf6r3c4sqSuNU4vfJ6FgJD6tNzg/Aan3ty3RbOKx eKDaS8gnZ/Zht3mLfRvXdN+4U3jPsSdpIAcyNrdBfdLe+DH72jBbSNvA9XC2pyYs BncaK488EVR1yJmrfZttA8ph7n84ypeWhqVkCMxkYJJUYRqWhCY+t1uxdfPrjXVy FS0PtgRW7tGt+ZXWsKwrUlf8GxNexpsvd7OA3fBTYasQQRY4E1DtXVVRymRM5nWW dk6XGHItI5yXzCSjU35mEBEUU2PGHY29js0lRM0SgY/kT5g7Y/p6QGIT5VA6rc2Q DZ2bJGA6suS0BGO012xdw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1668223438; x= 1668309838; bh=GB+WM3wS4WdxHjLxnFHp1BWh1TxS5aDksAR3+zvmPns=; b=h h4zTc7+WblAyiBDyks0wxnSkY6luzGgB1jgu7t34YsOLxhIhr/3xepZkir4VdLaS fhHmzTTGX47LyQuCUrT6IHUdaYmeSvcpdgu3fa+3wxanD3eBLJSjFnHtCIHjpQU+ NWmV1i380BoFe2rUsoBTXH1bfDU5r42ldtr21jGIG06DQwK1TFgQhjjo1wAQPtmg rs8WI6CvibPwEQndJVAscPTDZEhORIBgf+sPwYhfyl3nVG8IHLpfEOs/jD3LHve3 EV/jmb0ygJo3R40JEvLcCMgq2nNXQBJp3PZNPnlYiclaC0uftA5tOI3EB/Nz5+7W 7oMOJ87Z0Dz8b4MttVXxw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfeejgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvvefufhffjgfkfgggtgfgsehtqh ertddtreejnecuhfhrohhmpegkrggtkhcuhggvihhnsggvrhhguceoiigrtghksehofihl fhholhhiohdrohhrgheqnecuggftrfgrthhtvghrnhepvdetkeeugffhudfgvdeiffevff fgieekfeetheffjeeigedufeeuveekkeetledvnecuffhomhgrihhnpegvfihonhhtfhhi gidrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpeiirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 11 Nov 2022 22:23:57 -0500 (EST) From: Zack Weinberg To: Rich Felker Cc: c-std-porting@lists.linux.dev, autoconf@gnu.org, gcc@gcc.gnu.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: Fri, 11 Nov 2022 22:22:39 -0500 In-Reply-To: <20221110180458.GA7026@brightrain.aerifal.cx> (Rich Felker's message of "Thu, 10 Nov 2022 13:05:01 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,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 writes: > On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote: >> The biggest remaining (potential) problem, that I=E2=80=99m aware of, is= that >> AC_CHECK_FUNC unconditionally declares the function we=E2=80=99re probin= g for >> as =E2=80=98char NAME (void)=E2=80=99, and asks the compiler to call it = with no >> arguments, regardless of what its prototype actually is. =E2=80=A6 > Thanks for bringing this up. It is very important and I am very much > in favor of making these changes and doing it in a way that existing > broken and unmaintained software can be made to work just by > re-generating configure scripts with up-to-date autoconf, even if that > means hard-coding a list of headers needed to get the right > declarations and automatically pulling them in. Right. In principle, I think AC_CHECK_FUNCS([symbol]), where =E2=80=98symb= ol=E2=80=99 is in either ISO C or in XSI, could be made to do a check of the form you suggest at the end of https://ewontfix.com/13/ #include #include int main() { double (*p)(const char *, char **, locale_t) =3D strtod_l; } It=E2=80=99s =E2=80=9Cjust=E2=80=9D a matter of compiling that big list of = headers and expected function signatures. I=E2=80=99d also want to do something to ensure that = this assignment is not optimized out, so the linker has to process an undefined reference to the symbol. For symbols that are not covered by the built-in list, we could require people to indicate the necessary headers and signature somehow. Hypothetical notation AC_CHECK_FUNCS([ [argp_parse, [argp.h], [error_t], [const struct argp *, int, char **, unsigned int, int *, void *]] ]) Note that this still isn=E2=80=99t perfect; if some system provides a funct= ion with an identical type signature, but different *semantics*, to the one the application wants, no compilation test can detect that. Autoconf=E2=80= =99s not going to step away from its =E2=80=9Cavoid compile-and-run tests, that breaks cross compilation=E2=80=9D stance. > 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 I vaguely recall some cases where this bit glibc and Apple=E2=80=99s libc as well. In principle, you=E2=80=99re supposed to be able to declare some ISO C func= tions yourself, e.g. extern int printf(const char *, ...); int main(void) { printf("hello world\n"); } is strictly conforming per C99, but this bypasses any symbol renaming applied by stdio.h. > What I'd like to see happen is complete deprecation of the autoconf > link-only tests Do you have a concrete list of documented Autoconf macros that you would like to see deprecated for this reason? zw