mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Quentin Rameau <>
To: Pablo Correa Gomez <>
Subject: Re: [musl] newlocale: Segmentation fault when locale input is NULL
Date: Wed, 6 Oct 2021 14:31:39 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <AM5P192MB00812237500EA1FEBEB2C7ABC7B09@AM5P192MB0081.EURP192.PROD.OUTLOOK.COM>

On Wed, 06 Oct 2021 11:31:29 +0200
Pablo Correa Gomez <> 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:
>     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

      parent reply	other threads:[~2021-10-06 12:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-06  9:31 Pablo Correa Gomez
2021-10-06 12:29 ` Rich Felker
2021-10-06 12:57   ` Pablo Correa Gomez
2021-10-06 12:31 ` Quentin Rameau [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).