From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by sourceware.org (Postfix) with ESMTPS id 93C4F384F011 for ; Sat, 12 Nov 2022 14:10:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 93C4F384F011 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 compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E846B5C0090; Sat, 12 Nov 2022 09:10:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 12 Nov 2022 09:10:32 -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=1668262232; x= 1668348632; bh=qsMsWuS6ffNJ2O/ErZsmvb+zfmZFRfXcEUyGPiO1AmM=; b=O 8hP4gJImQlD9sjh3EdIupial3BGFV+luQtfRGfg5RncA5+Hn9jR+u9X7vyBU2eLR 1XJDM4JFfmeqeY2/ImLopenaNImUR5WFnOka3Yzm1nHrza/zgqZn7tlW5/TWVWdN gn0b1ap/jK6W+RSaOWF0Qmu3s2rp1kdioVMfm9jKO4JCbtXl0qOaIyye7z5/Zvks Jho2rcGP3YdFqeKrd3koeVLGnAeIXdmEM4OAZDqw4NQWCNFDCU2L58VqPvq2NHvN xjJQZ1MXCxm7C8LmJdP4/AjhbP61hw7eO8r0V1ZtzRJq67zQFzItVqag94KKEZt0 xrsVJwtJvp1MOFIa4KiQQ== 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=1668262232; x= 1668348632; bh=qsMsWuS6ffNJ2O/ErZsmvb+zfmZFRfXcEUyGPiO1AmM=; b=f S/45PhRc2+dKn/8DHIgE75AX+N14EwAmDSv3iHf4yywgBC3iWJjF6q3RSneaelnx qwud/55mo7r4pLvb7E+5WU/RcOFJOiXnATL7CnY+Tc76R/Ygj6DczM5mHYkYQ2tC n3Bre4nmvOzGr4MR4hT2B9gXu+Nlv0zSVHI9jCjSLI3riEkshHth4cOqi9dYDE2d rpsxMpSGk+o34sWgDxF5DI5ZO6UBfU6WTj14w2J5CfHh9aim8qV0TrhhkwV9gCea Vw/majU6V+Km2b0Y4oHGasypeWaRdHks3AXurSSbAcCzd4NUXpudw1qEkMHhqpWJ cyXg/SIJHBLNTfEvc+PVA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfeekgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufgjfhgffffkgggtgfesthhqofdttderjeenucfhrhhomhepkggrtghk ucghvghinhgsvghrghcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenucggtffrrg htthgvrhhnpeetheetgedvgfevieduheffudeujeehhedvheejgeevveefffffuedtudej vdeiffenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpeiirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Nov 2022 09:10:32 -0500 (EST) From: Zack Weinberg To: Paul Eggert Cc: Sam James , Michael Orlitzky , Autoconf Development , c-std-porting@lists.linux.dev, GCC Development Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? In-Reply-To: (Paul Eggert's message of "Fri, 11 Nov 2022 01:02:20 -0800") References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> <1d3109aa-c810-4c20-bcb9-d9d059d530a6@app.fastmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Date: Sat, 12 Nov 2022 09:09:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,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: Paul Eggert writes: > On 2022-11-10 19:33, Zack Weinberg wrote: > >> It would be relatively easy for me to take a couple hours this >> weekend and put out a 2.72 release with everything that's already in >> trunk and nothing else. Anyone have reasons I _shouldn't_ do that? > > I don't have anything other than some doc updates, which I just now > installed (see attached). couple of notes below >>> Note that in autoconf git, we've also got >>> https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=3Df6657256a37= da44c987c04bf9cd75575dfca3b60 >>> which is going to affect time_t efforts too >> I have not been following the y2038 work closely. Is it going to >> affect things in a good way or a bad way?? > > Both. [=E2=80=A6] (let=E2=80=99s leave this discussion to the other thread) > - and =E2=80=98false=E2=80=99 work anyway. This is for compatibility wi= th C 2023 and > + and =E2=80=98false=E2=80=99 work anyway. This is for compatibility wi= th C23 and Why are you changing four-digit years to two-digit years? I know you=E2=80= =99re old enough to remember Y2K :-) > All other headers, including all headers > from later revisions of the C standard, need to be tested for > +if your program is intended to be portable to C89 > (@pxref{Header Files}). I don=E2=80=99t understand what this addition is supposed to mean. Not all =E2=80=9Cmodern=E2=80=9D systems supply all of the C99 headers, even now. > -The C standard says a call @code{malloc (0)} is implementation > +The C standard says a successful call @code{malloc (0)} is implementation > dependent. It can return either @code{NULL} or a new non-null pointer. Style nit: how can a _call_ be implementation dependent? Suggest something like =E2=80=9CThe C standard says that _the result of_ a successf= ul call _to_ @code{malloc (0)} is implementation dependent.=E2=80=9D (undersco= res just to mark additions, not part of suggested text) zw