Re: [PATCH] Gracefully handle incompatible locale data

[ludo at gnu dot org (Ludovic CourtÃs)]

OndÅej BÃlka <neleai@seznam.cz> skribis:

> On Tue, Sep 22, 2015 at 11:22:40PM +0200, Ludovic CourtÃs wrote:
>> OndÅej BÃlka <neleai@seznam.cz> skribis:
>> 
>> > On Tue, Sep 22, 2015 at 05:27:55PM +0200, Ludovic CourtÃs wrote:
>> >> With libc 2.22 people are starting to realize that libc does not
>> >> guarantee that it can load locale data built with another libc version,
>> >> but they learn it the hard way:
>> >> 
>> >>   loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed.
>> >> 
>> >> This patch changes such conditions to return EINVAL instead of aborting.
>> >> 
>> >> WDYT?
>> >> 
>> > While that assert is quite cryptic I dont see why just returning EINVAL is
>> > better. How do you distinguish that its wrong locale version versus not
>> > installed?
>> 
>> The rest of this function already returns EINVAL when something is
>> fishy.  This patch makes the behavior more consistent.
>> 
> Then I take that back. But I don't see how this is reliable assertion to
> detect different libc version.

The goal is not to detect a different libc version, but rather to
gracefully handle the situation where incompatible (or broken) locale
data is found.

> So could you as followup patch add version field and check that
> instead this assert?

It would be inaccurate since sometimes different libc versions produce
and consume the same binary data (typically when no locale category
elements are added, as was the case between ~2.19 to 2.21.)

In addition, there is no errno value to report this specific
version-mismatch diagnostic.

Ludoâ.