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

[Adhemerval Zanella]

On 28/05/2020 08:41, Florian Weimer wrote:
>> diff --git a/string/strerror.c b/string/strerror.c
>> index 283ab70f91..35c749016e 100644
>> --- a/string/strerror.c
>> +++ b/string/strerror.c
>> @@ -15,29 +15,11 @@
>>     License along with the GNU C Library; if not, see
>>     <https://www.gnu.org/licenses/>.  */
>>  
>> -#include <libintl.h>
>> -#include <stdio.h>
>>  #include <string.h>
>> -#include <errno.h>
>> -
>> -/* Return a string describing the errno code in ERRNUM.
>> -   The storage is good only until the next call to strerror.
>> -   Writing to the storage causes undefined behavior.  */
>> -libc_freeres_ptr (static char *buf);
>> +#include <locale/localeinfo.h>
>>  
>>  char *
>>  strerror (int errnum)
>>  {
>> -  char *ret = __strerror_r (errnum, NULL, 0);
>> -  int saved_errno;
>> -
>> -  if (__glibc_likely (ret != NULL))
>> -    return ret;
>> -  saved_errno = errno;
>> -  if (buf == NULL)
>> -    buf = malloc (1024);
>> -  __set_errno (saved_errno);
>> -  if (buf == NULL)
>> -    return _("Unknown error");
>> -  return __strerror_r (errnum, buf, 1024);
>> +  return __strerror_l (errnum, __libc_tsd_get (locale_t, LOCALE));
>>  }
> 
> Why is it okay to share the buffer between strerror and strerror_l?
> POSIX is a bit unclear about this.  Practically speaking, it should be
> okay.  But perhaps there should be a NEWS entry.

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

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.  

> 
> Thanks,
> Florian
>