bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: workaround against broken duplocale


From: Bruno Haible
Subject: Re: workaround against broken duplocale
Date: Tue, 15 Aug 2017 23:39:38 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-91-generic; KDE/5.18.0; x86_64; ; )

Hi Jörg,

Joerg Sonnenberger wrote:
> uselocale() is fundamentally broken from a design perspective. It can't
> be implemented without breaking ABIs.

Well, glibc did not break ABIs when it introduced uselocale() in 2002.
If you have not exposed too many internals of the locale set by setlocale(),
you shouldn't have any problems. And you have the __RENAME macro, to cope
with these cases.

> It breaks expectations of existing applications in funny ways

I would say, it breaks expectations of programmers who have not yet gotten
familiar with the API. But existing applications - that do not invoke
uselocale() - run without modifications and without change in behaviour.

> and it is highly undesirable from a performance spective.

Why? If the locale is a single __thread variable (or a set of 6 __thread
variables, if you prefer), it is just as fast as any __thread variable access.

> It is also by itself useless as building block as
> pretty much any higher level runtime like C++ STL wants to have explicit
> control over locales.

Before these functions were standardized, I would have agreed with you:
that a decent object-oriented API for locale_t objects was the way to go,
rather than these odd-to-use newlocale/duplocale APIs with non-extensible
locale_t objects. But now the standard exists, and you do people a favour
if you implement it.

> > And on top of that, in NetBSD 7.0,
> >   - strfmon_l is not implemented,
> 
> This one slipped through. I did a full audit for any locale-sensitive
> function, but that one I missed. Thanks for finding it :)

FYI, here's the list of symbols from a Mac OS X 10.5 systems that end in '_l':

asprintf_l
atof_l
atoi_l
atol_l
atoll_l
btowc_l
digittoint_l
fgetwc_l
fgetws_l
fprintf_l
fputwc_l
fputws_l
fscanf_l
fwprintf_l
fwscanf_l
getwc_l
getwchar_l
isalnum_l
isalpha_l
isblank_l
iscntrl_l
isdigit_l
isgraph_l
ishexnumber_l
isideogram_l
islower_l
isnumber_l
isphonogram_l
isprint_l
ispunct_l
isrune_l
isspace_l
isspecial_l
isupper_l
iswalnum_l
iswalpha_l
iswblank_l
iswcntrl_l
iswctype_l
iswdigit_l
iswgraph_l
iswhexnumber_l
iswideogram_l
iswlower_l
iswnumber_l
iswphonogram_l
iswprint_l
iswpunct_l
iswrune_l
iswspace_l
iswspecial_l
iswupper_l
iswxdigit_l
isxdigit_l
localeconv_l
mblen_l
mbrlen_l
mbrtowc_l
mbsinit_l
mbsnrtowcs_l
mbsrtowcs_l
mbstowcs_l
mbtowc_l
nextwctype_l
nl_langinfo_l
printf_l
putwc_l
putwchar_l
scanf_l
snprintf_l
sprintf_l
sscanf_l
strcasecmp_l
strcasestr_l
strcoll_l
strfmon_l
strftime_l
strncasecmp_l
strptime_l
strtod_l
strtof_l
strtoimax_l
strtol_l
strtold_l
strtoll_l
strtoq_l
strtoul_l
strtoull_l
strtoumax_l
strtouq_l
strxfrm_l
swprintf_l
swscanf_l
tolower_l
toupper_l
towctrans_l
towlower_l
towupper_l
ungetwc_l
vasprintf_l
vfprintf_l
vfscanf_l
vfwprintf_l
vfwscanf_l
vprintf_l
vscanf_l
vsnprintf_l
vsprintf_l
vsscanf_l
vswprintf_l
vswscanf_l
vwprintf_l
vwscanf_l
wcrtomb_l
wcscoll_l
wcsftime_l
wcsnrtombs_l
wcsrtombs_l
wcstod_l
wcstof_l
wcstoimax_l
wcstol_l
wcstold_l
wcstoll_l
wcstombs_l
wcstoul_l
wcstoull_l
wcstoumax_l
wcswidth_l
wcsxfrm_l
wctob_l
wctomb_l
wctrans_l
wctype_l
wcwidth_l
wprintf_l
wscanf_l

> >   - duplocale(LC_GLOBAL_LOCALE) is broken.
> 
> I think this is a completely unrelated bug where thousand groupers were
> handled incorrectly. Test certainly works on current.

I don't think it's the same as a thousand groupers bug:
  - The number the test exercises comes out as "3.5" where "3,5" is expected.
  - The month name comes out incorrectly as well.
  - In the debugger, when I looked at the memory representation of
    duplocale(LC_GLOBAL_LOCALE), I saw a pointer to some C locale data
    followed by many NULL pointers.

But I'm pleased to hear that it will be fixed in NetBSD 8.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]