From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) by sourceware.org (Postfix) with ESMTPS id 54CD43858D20 for ; Thu, 10 Nov 2022 17:52:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 54CD43858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=draconx.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=draconx.ca Received: by mail-vk1-xa2d.google.com with SMTP id b81so743967vkf.1 for ; Thu, 10 Nov 2022 09:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=draconx-ca.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vDY5kk7bceOVOHUz16QSe4hH7gJWxG5r8t2el3t89CU=; b=NuH1s3EHPHrqebO//ZKvZbW8xpr4x02/n9nrQ5MXqRjhxzW2ZQBlvW5T9jZ4OIqaE/ XSLjRdZJFoKNH0JHOzorTbDRO53VuHThShDRzHIbMT4BLvwf5OaUouHmDK46/B9YJ99M jjHcidrAV9OH4WBR+abS1gYv+Don1LpZ46na6DwBaGSDsHKvHMpAUMBUkShReS2L0zc4 D68XSVY0l2YIK0flHRSnktwawaELrSP7bO92Nzs2Ql5cKmnL48j4UGhO2xQOC3pzLwFc T9ob8BCWAeoxnuZoMxVdRKCYGRi+hhwo4/6wEorjtaVj6uDKN70Tu3OQPfi8v4BOte/5 KaWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vDY5kk7bceOVOHUz16QSe4hH7gJWxG5r8t2el3t89CU=; b=2LjAczxenNZPImvG1iaRQ8N4oFNyXri0fEznHiIK9CiB38oVrjOrltxxyylS00tGNB TIolKBeeKSNBCtwi/X0BkIcuY0c8S/lGtezDUmcvzStzBhD0nPlrTkiwL0P6Me7VwTqd cRDEDagj+iCFRvYQn3KhbGzoeYCMuclvTtgVN6sWBlqsbUjVyQUluIXDS/KDHKsVGboO cKKe5iTTwMsfkTJs0+jboWxwjI6r/eWUgKKOwwZqKP2ihUO2KbaQKvPosK1QiCeTvarY VcNyJGIMgmCSBXjQ0SCJFVvFsvlIuzkcAh6tQ7TAsenlU8bhRI3Zjg2MG9s4KRZ8kEkz A8+Q== X-Gm-Message-State: ACrzQf1snpqo5dKAbGUTo5jAB3CFmaZGcKEcBj/rtqK/vL8MvmP8S+x3 YXME19Av7+Wp+nKj8hFBQbmUGX/0pklSQo2QslH0Mg== X-Google-Smtp-Source: AMsMyM5nMq86iSuzp5WWkX8Wf/FVePlofnuk/g6o9Mi1ubD8xb/rIbmxHeMqP/y+/ZlgZeRwLteQmD1K59dGKGxWvoU= X-Received: by 2002:a1f:3892:0:b0:3b7:69d0:13ed with SMTP id f140-20020a1f3892000000b003b769d013edmr16055897vka.14.1668102724464; Thu, 10 Nov 2022 09:52:04 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ab0:1526:0:b0:411:7409:106d with HTTP; Thu, 10 Nov 2022 09:52:03 -0800 (PST) X-Originating-IP: [24.53.241.20] In-Reply-To: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> From: Nick Bowler Date: Thu, 10 Nov 2022 12:52:03 -0500 Message-ID: Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? To: Zack Weinberg Cc: c-std-porting@lists.linux.dev, autoconf@gnu.org, gcc@gcc.gnu.org, cfe-commits@lists.llvm.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE 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: On 2022-11-10, 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 probing= for > as =E2=80=98char NAME (void)=E2=80=99, and asks the compiler to call it w= ith no > arguments, regardless of what its prototype actually is. It is not > clear to me whether this will still work with the planned changes to > the compilers. Both GCC 12 and Clang 14 have on-by-default warnings > triggered by =E2=80=98extern char memcpy(void);=E2=80=99 (or any other st= andard > library function whose prototype is coded into the compiler) and this > already causes problems for people who run configure scripts with > CC=3D'cc -Werror'. Unfortunately this is very hard to fix =E2=80=94 we w= ould > have to build a comprehensive list of library functions into Autoconf, > mapping each to either its documented prototype or to a header where > it ought to be declared; in the latter case we would also have to make > e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h > sys/socket.h netdb.h]) which might mess up configure scripts that > aren=E2=80=99t expecting headers to be probed at that point. > > How important do you think it is for this to be fixed? My gut feeling is that Autoconf should just determine the necessary options to get compatible behaviour out of these modern compilers, at least for the purpose of running configure tests. For example, Autoconf should probably build the AC_CHECK_FUNC programs using gcc's -fno-builtin option, which should avoid problems with gcc complaining about memcpy (and may also improve test accuracy, since gcc won't use its knowledge of C library behaviour to possibly elide the call to memcpy). It saddens me to see so much breakage happening in "modern C", a language that has (until now) a long history of new language features being carefully introduced to avoid these sort of problems. The fact that even the C standard authors don't even seem to care about existing codebases is a concerning change in direction. Nobody has learned anything from the Python 3 debacle, I guess. > p.s. GCC and Clang folks: As long as you=E2=80=99re changing the defaults= out > from under people, can you please also remove the last few predefined > user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the > -std=3DgnuXX modes? Meh, even though these macros are a small thing I don't accept the "things are breaking anyway so let's break even more things" attitude. This was something that many library authors did during the python 3 transition and that just made the problems orders of magnitude more horrible. Cheers, Nick