From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 2ACA32DCBC for ; Sat, 31 Aug 2024 02:32:15 +0200 (CEST) Received: (qmail 7548 invoked by uid 550); 31 Aug 2024 00:32:10 -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 7516 invoked from network); 31 Aug 2024 00:32:09 -0000 Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ayaya.dev; s=key1; t=1725064322; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to; bh=Kg9sq7x0SlJvatQD75gv5X3nBrqXjsxJaP48ZimO8sU=; b=bG2gUXjArctgO/c2pi0a/PZsfLCDRYlLshvOjkVwLCiX+cdkbQ9BSLNtCSGUzSTHlcXXar WY7KrWafOnT74NJc2LuYCFAQeRP9YEPEo1Vba6NisZK0/YDxWOF9CKwN+mHdMG8N2Me1OM 5pmeFmi0tbgZYz7BK3tL5rw34UM7VqQ= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 31 Aug 2024 02:31:58 +0200 Message-Id: Cc: X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "alice" To: In-Reply-To: <20161230222237.GR1555@brightrain.aerifal.cx> X-Migadu-Flow: FLOW_OUT Subject: [musl] Re: [PATCH] bind_textdomain_codeset: don't return failure unless encoding isn't UTF-8 > On Fri, Dec 30, 2016 at 04:13:44PM -0600, Laine Gholson wrote: > > option 1 is the only sane choice, and I don't see how something > > could break unless they constantly check for the GNU behavior and > > break if it isn't the GNU behavior, in which case it is the > > program's fault anyways. >=20 > Does the attached patch look reasonable? The "UTF8" alternative could > be added separately if needed; did you find software that's passing > the string without the '-'? >=20 > I think the main functional difference from your patch is that "UTF-8" > is returned in the case where the codeset argument is null. >=20 > Rich >=20 >=20 > > On 12/29/16 21:14, Rich Felker wrote: > > >On Fri, Dec 16, 2016 at 10:59:54PM -0500, Rich Felker wrote: > > >>On Sat, Dec 03, 2016 at 09:04:42PM -0600, Laine Gholson wrote: > > >>>returning null broke a vlc media player built with gettext support > > >> > > >>>>From 2f79aa294db5d9230ad71298e3de4b5561b441be Mon Sep 17 00:00:00 2= 001 > > >>>From: Laine Gholson > > >>>Date: Wed, 9 Nov 2016 20:19:00 -0600 > > >>>Subject: [PATCH] bind_textdomain_codeset: don't return failure unles= s encoding isn't UTF-8 > > >>> > > >>>VLC isn't happy when bind_textdomain_codeset returns NULL > > >>>--- > > >>> src/locale/bind_textdomain_codeset.c | 4 +++- > > >>> 1 file changed, 3 insertions(+), 1 deletion(-) > > >>> > > >>>diff --git a/src/locale/bind_textdomain_codeset.c b/src/locale/bind_= textdomain_codeset.c > > >>>index 5ebfd5e..e5f3f52 100644 > > >>>--- a/src/locale/bind_textdomain_codeset.c > > >>>+++ b/src/locale/bind_textdomain_codeset.c > > >>>@@ -5,7 +5,9 @@ > > >>> III > > >>> char *bind_textdomain_codeset(const char *domainname, const char *c= odeset) > > >>> { > > >>>- if (codeset && strcasecmp(codeset, "UTF-8")) > > >>>+ if (codeset && ((strcasecmp(codeset, "UTF-8") =3D=3D 0) || (strcas= ecmp(codeset, "UTF8") =3D=3D 0))) { > > >>>+ return "UTF-8"; > > >>>+ } else if (codeset) > > >>> errno =3D EINVAL; > > >>> return NULL; > > >>> } > > >>>-- > > >>>2.10.2 > > >> > > >>I think this needs some more thought. The documentation of the API is > > >>that a null pointer argument/result means "the locale's character > > >>encoding", and that the default is null; presumably even when the > > >>locale's codeset is "foo", null (default) and "foo" are still > > >>different states. > > >> > > >>I don't actually like that, and don't think we should copy it -- > > >>especially since, now that we also have a C locale with "ASCII" as th= e > > >>codeset, we _can't_ provide a codeset matching the locale in all case= s > > >>-- but I also don't think it's right for the return value (null or > > >>"UTF-8") to depend on the argument rather than on the "previous state= " > > >>like it's documented to. > > >> > > >>There seem to be two possible reasonable behaviors: > > >> > > >>1. Diverge from the GNU behavior and treat textdomains as always-boun= d > > >> to "UTF-8", regardless of whether bind_textdomain_codeset has been > > >> called. The function would then return a null pointer with EINVAL > > >> set for strings other than "UTF-8"/"UTF8", and would return "UTF-8= " > > >> for a valid or null-pointer argument. > > >> > > >>2. Keep a 1-bit state for each textdomain reflecting whether its > > >> nominally in "default" mode or "UTF-8" mode. Either way the > > >> original UTF-8 string would be returned; the only point of the > > >> state would be providing a return value for bind_textdomain_codese= t > > >> that reflects how it was previously called. > > >> > > >>Being that 2 is gratuitous complexity to do something stupid and > > >>meaningless, I'd lean towards 1, but I don't want to break anything > > >>that works. Does this seem safe to do? > > > > > >Ping. Anyone else have thoughts on this? > > > > > >Rich > > > ping :) the patch attached to that old email looks fine, and fixes a runtime i cras= h i ran into with an application getting confused with the incorrect NULL retur= n in subsequent logic handling. i guess it might've just been forgotten in 2016.