Re: [PATCH] Gracefully handle incompatible locale data

[Ondřej Bílka]

On Wed, Sep 23, 2015 at 11:45:52PM +0200, Ludovic Courtès wrote:
> Ondřej Bílka <address@hidden> skribis:
> 
> > On Tue, Sep 22, 2015 at 11:22:40PM +0200, Ludovic Courtès wrote:
> >> Ondřej Bílka <address@hidden> 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.
>
But my point is that this assert doesn't do that reliably. There could
be incompatible change that doesn't trigger that assert.
 
> > 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.)
>
Its better to keep it simple, you couldn't use locale data between
versions period. There could be also changes of algorithm so its harder
to tell if it will work or not.
 
> In addition, there is no errno value to report this specific
> version-mismatch diagnostic.
> 
We could also reject your patch based on this as you dont report
specific value for assert so this doesn't matter.