[Top][All Lists]

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

Re: [PATCH] Gracefully handle incompatible locale data

From: Carlos O'Donell
Subject: Re: [PATCH] Gracefully handle incompatible locale data
Date: Fri, 25 Sep 2015 17:20:13 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

On 09/24/2015 12:12 PM, Ludovic Courtès wrote:
> Ondřej, I think we have been miscommunicating.
> I noticed that a program linked against 2.21 or earlier would abort with
> an assertion failure when it stumbles upon 2.22 locale data.
> All the patch tries to do is change the abort to EINVAL (and skip locale
> data) when that happens.
> I’m not claiming this is perfect, and I agree with you on that point.
> I’m just saying that ignoring the faulty locale data and returning
> EINVAL (which the application can choose to take into account or not) is
> preferable to aborting.
> Does that make sense?

Despite Roland saying "LGTM", I think this is not a good change.

Firstly, it's not the community consensus as Ondrej is pointing out.

It is a fundamental system misconfiguration issue not to have upgraded
the binary locale data from one release to another.

The community consensus was that user errors like this should fail
immediately, but in ways which the user understands the failure, and
fixes the system.

Returning an error code simply leads to the user ignoring the serious
configuration issue. Worse is that in a locale archive file we now
skip such bad binary archives (_nl_load_locale_from_archive), and
this hides the problem. Worse we might also skip locale files in
directories like /usr/lib/locale/C.utf8, which we might want to always
be loaded as a default UTF-8 locale. I'd rather see an error message
in Fedora than allow that to continue by skipping that locale with
no error given.

We should abort, but the abort error message should be much clearer
about what's going wrong. Therefore I would accept a patch that gives
a clearer error message in this case, but not one that removes the


reply via email to

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