Re: glibc strerrorname_np

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

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).