Re: [PATCH] Gracefully handle incompatible locale data

["Carlos O'Donell" <carlos@redhat.com>]

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.

https://sourceware.org/glibc/wiki/Style_and_Conventions#Error_Handling

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
assert.

Cheers,
Carlos.