This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Gracefully handle incompatible locale data
- From: ludo at gnu dot org (Ludovic CourtÃs)
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, libc-alpha at sourceware dot org, guix-devel at gnu dot org, Roland McGrath <roland at hack dot frob dot com>
- Date: Tue, 29 Sep 2015 10:08:53 +0200
- Subject: Re: [PATCH] Gracefully handle incompatible locale data
- Authentication-results: sourceware.org; auth=none
- References: <876132lbic dot fsf at gnu dot org> <20150922191804 dot GA13637 at domone> <877fnijgin dot fsf at gnu dot org> <20150922215022 dot GA27201 at domone> <8737y4hkrz dot fsf at gnu dot org> <20150924082755 dot GA4767 at domone> <87h9mjeqyy dot fsf at gnu dot org> <5605BA8D dot 40907 at redhat dot com> <87h9mh5vgn dot fsf at gnu dot org> <5609A8E9 dot 7050201 at redhat dot com>
"Carlos O'Donell" <firstname.lastname@example.org> skribis:
> On 09/26/2015 06:24 AM, Ludovic CourtÃs wrote:
>> Furthermore, the function in question returns EINVAL in other similar
>> casesâe.g., when libc 2.22 loads LC_COLLATE data from libc 2.21.
> If you change this particular case to EINVAL, what does the user see
> as a result of this change?
The user-visible change is that, if incompatible or broken locale data
is found, a call like:
setlocale (LC_ALL, "");
returns EINVAL instead of aborting.
> Do they get a non-zero exit code from `localedef --list-archive` along
> with an error written out to stderr?
âlocaledefâ starts with:
setlocale (LC_MESSAGES, "");
setlocale (LC_CTYPE, "");
so it will no longer abort when invalid locale data is found (although
in the 2.21 â 2.22 transition, only the LC_COLLATE data format differs
Apart from that, âlocaledef --list-archiveâ simply opens the locale
archive (typically /usr/lib/locale/locale-archive, regardless of the
âLOCPATHâ environment variable value), so its behavior is unchanged.
Am I overlooking something?
> This is the kind of change I'm expecting. If we are removing an assertion,
> we should be replacing it with something meaningful and verifying that
> meaningful change.
The function that is changed, â_nl_intern_locale_dataâ, has only two
callers in libc, and both check whether it returns NULL. So it seems to
me that the code is not introducing anything new in the API contract.