[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Gracefully handle incompatible locale data
From: |
Allan McRae |
Subject: |
Re: [PATCH] Gracefully handle incompatible locale data |
Date: |
Tue, 13 Oct 2015 10:49:41 +1000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
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?
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.
Allan