From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BULK_RE_SUSP_NTLD,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FROM_SUSPICIOUS_NTLD,MAILING_LIST_MULTI, PDS_OTHER_BAD_TLD,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 20514 invoked from network); 6 Oct 2021 12:31:58 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 6 Oct 2021 12:31:58 -0000 Received: (qmail 24438 invoked by uid 550); 6 Oct 2021 12:31:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24420 invoked from network); 6 Oct 2021 12:31:56 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=fifth.space; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=20190812; bh=VRNI48C6 zbPJ029D6MNGGINdlxg=; b=A/ZOowYiOLZJc+vnlu/jtqhaJ7iKbqfZB3RmXEAt H2aQzZ2pve/ZnDpgF9MqkVPYv1XApmvfJcRDazqiO9DlOnYUdaN+7hCqDAb/EKo6 r1zNNaUh5pfxtDjlI7RCQnK9oZ1J/a1DidTsIR9AFH3K/IJt9OtkL2VT8EMGom86 h9Fd59VVqjpbbUdaVLf8z1dGL8o6jB53zF+BXcmzofJlp3IWdz8Oz9iChME1XM7/ 3jckXQuQXnpkVujeNpStbaaLqu2tn11e4H/IdvUvrLqnlmUzW6de6H4jwNSgQpjX SpfqD6cmoY4oT+PGULVCQ4yLSZSRAwRenQa+/WInYm+IQA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=fifth.space; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=20190812; b=d1 mcqj4BIbSvWlEQKN6tFtDbMjS4Ub0Rxt2DV5gM8DWN4hZcWTnjveRwnoyfdap+jG dW0FfSlGCaGRywe5nImddCrMwBwSeu80wTVJ4iVrBAZSuTFPmvzIp/rmAlCFKSnY CxcQe+GdFNyg4bvUktenXo9TB6Umq9IWIXRk6Lyx7IyFbXwUeqOICW5j6zo44U7Y 5+e6uGc4SdfjEEBE1LuoCE0cdxiscHknWQ2VpYuvzIyjonehdcJbQHxDJXLGDjzf pxt0EbvDVQLzo28oIVBkEJ3WWEBtMX4i91LUsO/5yEpNv1DXsRcCNuQvcgPbZQdJ o+X8mGWIYSnkyr8Oz5mg== Date: Wed, 6 Oct 2021 14:31:39 +0200 From: Quentin Rameau To: Pablo Correa Gomez Cc: musl@lists.openwall.com Message-ID: <20211006143139.443e977f@tpx.quinq.eu.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] newlocale: Segmentation fault when locale input is NULL 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); >=20 > 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. >=20 > In the case of glibc, this is not an issue, as per the documentation[3] > they consider it an error: >=20 > EINVAL locale is NULL. >=20 > 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: >=20 >=20 > The newlocale() function may fail if: >=20 > [EINVAL] > The locale argument is not a valid string pointer.=20 >=20 >=20 > 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 =E2=80=9Cfix=E2=80=9D 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.