[PATCH 06/13] string: Implement strerror in terms of strerror_l

[Adhemerval Zanella]

On 03/06/2020 05:24, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> POSIX states the strerror buffer *might* be overwritten by a subsequent
>> call to strerror *or* strerror_l (as an extension to the ISO C). So my
>> understanding is an implementation has the freedom to implement strerror
>> on top of strerror_l and share its internal buffer (bionic and musl seem
>> to share this understanding was well).
> 
> My recollection is that the wording in POSIX is asymmetric (one
> invalidates the other, but not the other direction).  I don't think that
> matters, it's probably just an unfortunate wording.

Ack.

> 
>> What about  add this NEWS entry at deprecated and removed features:
>>
>>   * Both strerror and strerror_l now share the same internal buffer, meaning                             
>>     that the returned string pointer might be invalidated or contents might                              
>>     be overwritten in subsequent calls of any symbol.  
> 
> s/any symbol/either function/?

Ack.
 
> There are some weird spaces before the line break.

Yeah, I have explicit added them (it is not intended for the NEWS
file itself).

> 
> Thanks,
> Florian
>