This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Gracefully handle incompatible locale data


On Wed, Sep 23, 2015 at 11:45:52PM +0200, Ludovic CourtÃs wrote:
> 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.
>
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]