From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) by sourceware.org (Postfix) with ESMTPS id 8A2493858439 for ; Thu, 10 Nov 2022 18:19:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8A2493858439 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=aaronballman.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=aaronballman.com Received: by mail-qt1-x82a.google.com with SMTP id w4so1435110qts.0 for ; Thu, 10 Nov 2022 10:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aaronballman.com; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dxZ4Sah36vnXrWVB+WyyWX+I6WbY+WNxBYEykhmKs3I=; b=JG1hmVfd2AfuqWQx5PYdhhq8s/ClCVpCb4DtCX5t+Y8Jf+/SP+71+/2X01RfriPtTh RMoNsk+ix0MGhzxG50gyMiYXCZMM5AucRVRFLDi8ap5LU1TgKVWgalAQMJDaplalOPiz boNLzt0M5mfnpZ2nSY21R0ytxDAkh+mKQFm6AXJtGD5ik7puOqIRq7HR/oR4hen/zF9V 1yy7ywE69zUfvOhf/ZQH+kn0GV2xNyNbsw6WoWXEBOe3qH9Jim40q3CBe4tpBrNTJlNx N0gafk4VvwOmli0BHqntHQgILtB+DwiixLVUOPtO+hrVe1lHo1Ay0x6RW1enO1egBdfK 3mOQ== 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 :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dxZ4Sah36vnXrWVB+WyyWX+I6WbY+WNxBYEykhmKs3I=; b=jq2JpCkgP7Y4FhJ8udD79dynGCeVfhjmk0fIFaTBv+Klwb3ak+CRIDhy1M1hhiaNU3 Ke4ov5USQ7rvydyTMoE/7q+xACNbUggHsJTW5Pxo9l5c3AVjcjFVnnq9/JvhQmO2z7lB spMMrchx+etCpijdLBGW1/AcYHltgqFFAym+9Ve67qX/7198L+stSEmwrVxKl4r+/vK9 araSKp8G4BDSsBa+jASMzwQeVTZFZZ4RUV6HG1TcF52l09YR7xaG2/yYOAecEIH9bhY/ bz1qfKze0ppGVOKE6VF5ol0uSaMJUk6Xdj2hkAhrY6cE/5gJBAt+varH5ObA72fVExPL 6HOg== X-Gm-Message-State: ACrzQf0mI8w6vG6wUqTAjYnB/Cq4XZ0O5UIPMEentutYqE123jYM+xc/ At25dw2LmVJrxnejJqnUKyyIEbQrhkbYvT+I X-Google-Smtp-Source: AMsMyM6ZSFYjI5ZsSCjxmOv9fmQHnGtwwDheeoAZ5if2rimZbb63mVFJMndciCwsdpt1KuD6eLF5HA== X-Received: by 2002:ac8:43cc:0:b0:3a5:2d50:692f with SMTP id w12-20020ac843cc000000b003a52d50692fmr1612481qtn.42.1668104363632; Thu, 10 Nov 2022 10:19:23 -0800 (PST) Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com. [209.85.219.174]) by smtp.gmail.com with ESMTPSA id u12-20020a05620a084c00b006bc192d277csm17099qku.10.2022.11.10.10.19.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Nov 2022 10:19:22 -0800 (PST) Received: by mail-yb1-f174.google.com with SMTP id o70so3274833yba.7 for ; Thu, 10 Nov 2022 10:19:22 -0800 (PST) X-Received: by 2002:a25:e6d8:0:b0:6cb:72c:d06f with SMTP id d207-20020a25e6d8000000b006cb072cd06fmr61009006ybh.389.1668104362189; Thu, 10 Nov 2022 10:19:22 -0800 (PST) MIME-Version: 1.0 References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> In-Reply-To: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> From: Aaron Ballman Date: Thu, 10 Nov 2022 13:19:10 -0500 X-Gmail-Original-Message-ID: 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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: On Thu, Nov 10, 2022 at 12:16 PM Zack Weinberg via cfe-commits wrote: > > I=E2=80=99m the closest thing Autoconf has to a lead maintainer at presen= t. > > It=E2=80=99s come to my attention (via https://lwn.net/Articles/913505/ a= nd > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and > Clang both plan to disable several =E2=80=9Clegacy=E2=80=9D C language fe= atures by > default in a near-future release (GCC 14, Clang 16) (see the Fedora > wiki link for a list). I understand that this change potentially > breaks a lot of old dusty code, and in particular that > Autoconf-generated configure scripts use constructs that may *silently > give the wrong answer to a probe* when a stricter compiler is in use. > > Nobody has a whole lot of time to work on Autoconf at present, but I > would like to ask, anyway, what Autoconf could potentially do to make > this transition easier. I=E2=80=99m already aware that the test code Aut= oconf > 2.71 uses to probe for C89/C99/C11 support is broken; this has been > fixed in development trunk to the extent it is possible for me to test > it with GCC 12 (commit: > ). > Several other places using K&R function definitions and/or > unprototyped function declarations (including the ubiquitously used > AC_CHECK_FUNC) have also been fixed on trunk, > . > Changes to handle C23 built-in =E2=80=98bool=E2=80=99 better are under de= velopment but > the design has not yet been finalized. Thank you for all of your efforts in modernizing autoconf in response to all these changes, it's greatly appreciated! > 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. In terms of the Clang side of things, I don't think we've formed any sort of official stance on how to handle that yet. It's UB (you can declare the C standard library interface without UB but calling any function with a mismatched signature is UB) and that UB has some amount of security implications associated with it, so I would say there's a potential we might want to upgrade the diagnostic severity, but it's not assured. FWIW, we're working on improving communication about potentially disruptive changes to Clang, so you might want to consider either subscribing to the clang-vendors code review group at https://reviews.llvm.org/project/members/113/ (if you want to be involved in code review before things land) or the Announcements discourse channel at https://discourse.llvm.org/c/announce/ (if you want to be notified after something lands but before Clang ships). > How important do you think it is for this to be fixed? > > Are there any other changes you would like to see in a near-future > Autoconf 2.72 in order to make this transition easier? I don't have a specific list, but as a general request: moving away from deprecated facilities of C or reliance on UB is a very pragmatic idea given that the C committee is recapturing some of that design space (like what happened with K&R C signatures) and implementers are trying to improve the security posture for C. > zw > > 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? If we can do so without breaking the world, I personally think it would be nice to remove them. ~Aaron > _______________________________________________ > cfe-commits mailing list > cfe-commits@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits