From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Zack Weinberg <zack@owlfolio.org>, libc-alpha@sourceware.org
Subject: Re: glibc strerrorname_np
Date: Mon, 8 Nov 2021 10:56:44 -0300 [thread overview]
Message-ID: <6d5ad19c-ecc3-b760-a18c-d0736a81cc1d@linaro.org> (raw)
In-Reply-To: <0bee99f3-35c7-4ad0-845b-d2fcdde9761a@www.fastmail.com>
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).
next prev parent reply other threads:[~2021-11-08 13:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-04 20:23 Jonny Grant
2021-11-04 20:46 ` Adhemerval Zanella
2021-11-04 22:52 ` Jonny Grant
2021-11-04 23:28 ` Adhemerval Zanella
2021-11-05 11:51 ` Jonny Grant
2021-11-05 13:01 ` Adhemerval Zanella
2021-11-05 22:23 ` Jonny Grant
2021-11-06 12:51 ` Adhemerval Zanella
2021-11-07 17:37 ` Zack Weinberg
2021-11-08 13:56 ` Adhemerval Zanella [this message]
2021-11-08 18:42 ` Zack Weinberg
2021-11-08 18:52 ` Adhemerval Zanella
2021-11-08 19:56 ` Florian Weimer
2021-11-08 20:28 ` Adhemerval Zanella
2021-11-08 22:22 ` Jonny Grant
2021-11-09 12:30 ` Adhemerval Zanella
2021-11-09 23:01 ` Jonny Grant
2021-11-10 1:37 ` Adhemerval Zanella
2021-11-08 8:36 ` Florian Weimer
2021-11-08 13:36 ` Jonny Grant
2021-11-08 13:42 ` Florian Weimer
2021-11-08 22:14 ` Jonny Grant
2021-11-08 14:01 ` Adhemerval Zanella
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6d5ad19c-ecc3-b760-a18c-d0736a81cc1d@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=zack@owlfolio.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).