From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by sourceware.org (Postfix) with ESMTPS id EC0783858D3C for ; Mon, 8 Nov 2021 18:52:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EC0783858D3C Received: by mail-qt1-x82f.google.com with SMTP id z9so3106233qtj.9 for ; Mon, 08 Nov 2021 10:52:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=L6dPcUz6G1XUx2Wcr5uYCGv433i5ozw5y7+SsUT/EAM=; b=Y3e8+li485t78HmLDPqgIzmxWGTjr2Oo6APvyKXxV8nP2lbPy8nddLMc2RnJUD38Q0 F8nvVdKkiXkB1kNKsbp5Qiu2bsxCsc4HuG2WpM+z89rsDE1JM9bDlizQLFJwn+I2HbI+ 4142pNCRk7kUIdmKP89FGfjW3re34rm15ILu9k0s3PVC98kbRPj4+2UtHhyqGqn/qvGU WzyyvQ6wCA/sMH1VHIBsbmqnGaCKCMXX4aqKMkCAj/jQiI0dZ9Lz+Q91XmU0T0rwyyfn ezUbqHr+IiUu/cYFDJXImE+yDW2KBEfrwNcQQBRHOHl7RJO97CHK6hAInUSY8XXXag+Y di6g== X-Gm-Message-State: AOAM530tERHGJNSx4YvQEKNV7EMTATKdBGesMy0Ia9AxOn5pa9jq07iF 0bwgIL+hMmWw51Z6DDHyWFw3r+cpLpOqRg== X-Google-Smtp-Source: ABdhPJyOAzWGJtE4oFzwtniQQdHdysHW8m6pyRSxCPuvo5imdjBsJaY/XvFY+H1VJ7yXVraya++k+A== X-Received: by 2002:ac8:4156:: with SMTP id e22mr1959033qtm.14.1636397527507; Mon, 08 Nov 2021 10:52:07 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:55a:c067:29b:4c08:be99? ([2804:431:c7cb:55a:c067:29b:4c08:be99]) by smtp.gmail.com with ESMTPSA id j15sm11667921qtx.67.2021.11.08.10.52.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 10:52:06 -0800 (PST) Message-ID: <22181691-105a-ae32-4dde-482783dcdb6e@linaro.org> Date: Mon, 8 Nov 2021 15:52:04 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Subject: Re: glibc strerrorname_np Content-Language: en-US To: Zack Weinberg Cc: libc-alpha@sourceware.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> <533fd451-35c9-4e8d-9ba9-41059de44ed0@www.fastmail.com> From: Adhemerval Zanella In-Reply-To: <533fd451-35c9-4e8d-9ba9-41059de44ed0@www.fastmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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:52:09 -0000 On 08/11/2021 15:42, Zack Weinberg wrote: > 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. Well, compat symbols is meant to keep old binaries running without introducing regression that would require a redeploy, it is not meant to fix old sources that might not rebuild against newer libc (since it is an GNU extension). For such cases we do need some code fixes (as it is constantly done on gnulib, for instance). But I do agree with you that at least keeping old buggy behavior for the sake of 'compatibility' is not a practice that I think help improve the whole ecosystem as whole (although it does help close-source and/or binary one system where recompile is an issue).