Date: Wed, 6 Oct 2021 14:31:39 +0200 From: Quentin Rameau <quinq@...th.space> To: Pablo Correa Gomez <ablocorrea@...mail.com> Cc: musl@...ts.openwall.com Subject: Re: newlocale: Segmentation fault when locale input is NULL On Wed, 06 Oct 2021 11:31:29 +0200 Pablo Correa Gomez <ablocorrea@...mail.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 > 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 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.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.