From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by sourceware.org (Postfix) with ESMTPS id 57A043858417 for ; Mon, 8 Nov 2021 18:43:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 57A043858417 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id D7C303201EF4; Mon, 8 Nov 2021 13:43:28 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute5.internal (MEProxy); Mon, 08 Nov 2021 13:43:29 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddvgdduudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdgkrggt khcuhggvihhnsggvrhhgfdcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenucggtf frrghtthgvrhhnpefhuefhveeuffetfffgjeetgfekkeehfedtfeelgfehffffveehkeel fefgheffudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpeiirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4E8EC24A0074; Mon, 8 Nov 2021 13:43:28 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1369-gd055fb5e7c-fm-20211018.002-gd055fb5e Mime-Version: 1.0 Message-Id: <533fd451-35c9-4e8d-9ba9-41059de44ed0@www.fastmail.com> In-Reply-To: <6d5ad19c-ecc3-b760-a18c-d0736a81cc1d@linaro.org> References: <98556e3e-2869-64f0-574e-7a64503185c2@linaro.org> <9613b21a-3ab0-3303-9321-7bf4e36ce7ed@jguk.org> <77e058e8-2f54-46a5-2180-9784f23040e7@linaro.org> <4f5422c1-d6ea-1ea5-eeea-db61f8b95bc8@jguk.org> <66a2e472-d4e2-96bb-d1a5-8bafa795083f@linaro.org> <4c43eab7-2ca8-1b90-5fb9-c84e26a96ef0@linaro.org> <0bee99f3-35c7-4ad0-845b-d2fcdde9761a@www.fastmail.com> <6d5ad19c-ecc3-b760-a18c-d0736a81cc1d@linaro.org> Date: Mon, 08 Nov 2021 13:42:52 -0500 From: "Zack Weinberg" To: "Adhemerval Zanella" Cc: libc-alpha@sourceware.org Subject: Re: glibc strerrorname_np Content-Type: text/plain X-Spam-Status: No, score=-2.9 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_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 18:43:34 -0000 On Mon, Nov 8, 2021, at 8:56 AM, Adhemerval Zanella wrote: > On 07/11/2021 14:37, Zack Weinberg via Libc-alpha wrote: >> On Sat, Nov 6, 2021, at 8:51 AM, Adhemerval Zanella via Libc-alpha wrote: >>> On 05/11/2021 19:23, Jonny Grant wrote: >>>> On 05/11/2021 13:01, Adhemerval Zanella wrote: >>>>> On 05/11/2021 08:51, Jonny Grant wrote: >>>>>> Thank you for your reply. Personally I understood an ABI break would be >>>>>> the return type, the name, or the parameters. But the proposed change is >>>>>> not so. Changing to return a string, should be fine. >>>>> >>>>> It is still an ABI break, code that checks NULL for invalid input will >>>>> stop to work. >> ... >>> As I said before it is an ABI break, since users that check for invalid >>> errno against NULL will start to fail. For such change we *do need* all >>> the trouble of adding a compat symbol with current semantic. >> >> A compat symbol doesn't do any good here, though. As soon as the program is recompiled it will start getting the new semantics, and since that doesn't cause a compile-time error, the break will go unnoticed -- particularly in this case, since this is likely to affect only error-handling paths that test suites tend not to exercise. >> >> If we want to preserve backward compatibility we need a whole new function name. > > This is the burden of any semantic change on exported symbols: new users > will need to adapt to it, since the idea is to keep older programs > expecting the new semantic (since either rebuilding is not possible or > troublesome). I think you misunderstand. I'm saying that a compat symbol is *not enough* backward compatibility, since it only protects old binaries, not old sources that have been recompiled with a newer libc. Compat symbols, in my view, are only sufficient when either a recompilation will fix whatever the problem was (e.g. changing the size of a FILE) or when old code will not *compile* until corrected for the new semantics. I know we have done compat symbols as the only backward compatibility net for runtime-only semantic changes in the past, but I think that was wrong and we shouldn't do it anymore. zw