This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Gracefully handle incompatible locale data
- From: ludo at gnu dot org (Ludovic CourtÃs)
- To: Allan McRae <allan at archlinux dot org>
- Cc: Carlos O'Donell <carlos at redhat dot com>, 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, 13 Oct 2015 11:50:39 +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> <561C5525 dot 40501 at archlinux dot org>
Allan McRae <allan@archlinux.org> skribis:
> On 29/09/15 06:54, Carlos O'Donell wrote:
>> 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? Do they get a non-zero exit code from
>> `localedef --list-archive` along with an error written out to stderr?
>>
>> 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.
>>
>> You need not change any of the other cases you've found that return EINVAL,
>> we can update those incrementally, but for this one change you're making
>> we should fix it as best we can.
>>
>
> If I am reading this correctly, the change to from an abort to EINVAL
> would be fine if it is accompanied by a change to localedef
> --list-archive. Is that correct?
My understanding is that no such change is needed, but Iâm waiting for
confirmation or clarification:
https://sourceware.org/ml/libc-alpha/2015-09/msg00727.html
> A solution to this would be great given we now run into this assert with
> locale archives built with different glibc builds along the 2.22 release
> branch.
Iâm glad you value the practical benefits. ;-)
Ludoâ.