Re: [musl] newlocale: Segmentation fault when locale input is NULL

[Quentin Rameau <quinq@fifth.space>]

On Wed, 06 Oct 2021 11:31:29 +0200
Pablo Correa Gomez <ablocorrea@hotmail.com> wrote:

> Dear musl maintainers,

Hi Pablo,

> newlocale(LC_CTYPE, NULL, (locale_t)0);
> 
> In this case, "name" is passed to __get_locale in
> src/locale/newlocale.c:27 and then dereferenced in
> src/locale/locale_map.c:43, causing a segmentation fault.
> 
> In the case of glibc, this is not an issue, as per the documentation[3]
> they consider it an error:
> 
>        EINVAL locale is NULL.
> 
> Unfortunately, this is a difference in the implementation between glibc
> and musl, maybe due to the fact that the standard[4] in not clear in
> this point:
> 
> 
> The newlocale() function may fail if:
> 
> [EINVAL]
>     The locale argument is not a valid string pointer. 
> 
> 
> My personal believe is that adding a NULL pointer check in musl is very
> simple and might help not only GNOME desktop, but maybe also other
> projects in the future.

I think the opposite, the standard is quite clear to the developper who
intends to write portable application, newlocale() may fail with an
invalid locale argument pointer. So check your pointer before calling
that function.

While changing musl behaviour would “fix” the GNOME issue, this will not
help GNOME developpers, or other projects, writing better portable code.

Just my two cents, not answering if musl behaviour should be changed or
not.