|
Message-ID: <20231208235920.GE4163@brightrain.aerifal.cx> Date: Fri, 8 Dec 2023 18:59:21 -0500 From: Rich Felker <dalias@...c.org> To: Alastair Houghton <ahoughton@...le.com> Cc: musl@...ts.openwall.com Subject: Re: setlocale() again On Fri, Dec 08, 2023 at 10:46:15AM +0000, Alastair Houghton wrote: > On 5 Dec 2023, at 15:19, Alastair Houghton <ahoughton@...le.com> wrote: > > > >> Maybe I’ve missed a reply somewhere along the lines; here’s a tentative patch that just does the simple thing of making setlocale(LC_ALL, "") pick the C.UTF-8 locale if it’s unable to find the locale specified in the environment. > > > > [snip] > > > > Hah. So, testing that patch, having removed my hacks to avoid using Musl’s locale support, I find it doesn’t actually work (for two reasons; one, NULL doesn’t mean not found, it means “use ‘C’”; and two, there is some very odd code in setlocale.c that causes things to go wrong if the specified name is longer than LOCALE_NAME_MAX). > > > > I’ll come back with an updated patch in a bit. > > Updated patch: > > ==== Cut here ==== > diff --git a/src/locale/locale_map.c b/src/locale/locale_map.c > index da61f7fc..097da1ad 100644 > --- a/src/locale/locale_map.c > +++ b/src/locale/locale_map.c > @@ -31,7 +31,7 @@ static const char envvars[][12] = { > volatile int __locale_lock[1]; > volatile int *const __locale_lockptr = __locale_lock; > > -const struct __locale_map *__get_locale(int cat, const char *val) > +const struct __locale_map *__get_locale(int cat, const char *locale) > { > static void *volatile loc_head; > const struct __locale_map *p; > @@ -39,6 +39,7 @@ const struct __locale_map *__get_locale(int cat, const char *val) > const char *path = 0, *z; > char buf[256]; > size_t l, n; > + const char *val = locale; > > if (!*val) { > (val = getenv("LC_ALL")) && *val || > @@ -92,22 +93,18 @@ const struct __locale_map *__get_locale(int cat, const char *val) > } > } > > - /* If no locale definition was found, make a locale map > - * object anyway to store the name, which is kept for the > - * sake of being able to do message translations at the > - * application level. */ > - if (!new && (new = malloc(sizeof *new))) { > - new->map = __c_dot_utf8.map; > - new->map_size = __c_dot_utf8.map_size; > - memcpy(new->name, val, n); > - new->name[n] = 0; > - new->next = loc_head; > - loc_head = new; > - } > + /* If no locale definition was found, and we specified a > + * locale name of "", return the C.UTF-8 locale. */ > + if (!new && !*locale) new = (void *)&__c_dot_utf8; > > /* For LC_CTYPE, never return a null pointer unless the > * requested name was "C" or "POSIX". */ > if (!new && cat == LC_CTYPE) new = (void *)&__c_dot_utf8; > > + /* Returning NULL means "C locale"; if we get here and > + * there's no locale, return failure instead. */ > + if (!new) > + return LOC_MAP_FAILED; > + > return new; > } > diff --git a/src/locale/setlocale.c b/src/locale/setlocale.c > index 360c4437..9842d95d 100644 > --- a/src/locale/setlocale.c > +++ b/src/locale/setlocale.c > @@ -28,12 +28,14 @@ char *setlocale(int cat, const char *name) > const char *p = name; > for (i=0; i<LC_ALL; i++) { > const char *z = __strchrnul(p, ';'); > - if (z-p <= LOCALE_NAME_MAX) { > + if (z-p > LOCALE_NAME_MAX) > + lm = LOC_MAP_FAILED; > + else { > memcpy(part, p, z-p); > part[z-p] = 0; > if (*z) p = z+1; > + lm = __get_locale(i, part); > } > - lm = __get_locale(i, part); > if (lm == LOC_MAP_FAILED) { > UNLOCK(__locale_lock); > return 0; > ==== Cut here ==== Sorry to be late chiming in here. There's something I've been meaning to ask: back when this was first proposed, I recall there being two variants we considered: one where setlocale to "" where the env vars don't resolve to any real locale file produces as its implementation-defined result "C.UTF-8", and another where it produces a ghost locale with the requested name but the behavior of "C.UTF-8". Is there a reason you think the former is a better choice than the latter? The latter would avoid breaking things for users with application translations but no libc locale files. However it requires more complex logic for consistency I think, and I'm not sure we ever worked out if that could be done in a reasonable way. Another option that wasn't raised before but that might be worth considering is keeping the existing behavior if MUSL_LOCPATH is not set (all names are valid and are aliases for "C.UTF-8" but doing as in your patch if it's set. Rich
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.