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

[Florian Weimer]

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

> 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/?

There are some weird spaces before the line break.

Thanks,
Florian