This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Gracefully handle incompatible locale data
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Ludovic Courtès <ludo at gnu dot org>
- Cc: libc-alpha at sourceware dot org, guix-devel at gnu dot org
- Date: Tue, 22 Sep 2015 23:50:22 +0200
- Subject: Re: [PATCH] Gracefully handle incompatible locale data
- Authentication-results: sourceware.org; auth=none
- References: <876132lbic dot fsf at gnu dot org> <20150922191804 dot GA13637 at domone> <877fnijgin dot fsf at gnu dot org>
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. So could you as followup patch add
version field and check that instead this assert?