From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= Subject: Re: [PATCH] Gracefully handle incompatible locale data Date: Tue, 22 Sep 2015 23:50:22 +0200 Message-ID: <20150922215022.GA27201@domone> References: <876132lbic.fsf@gnu.org> <20150922191804.GA13637@domone> <877fnijgin.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Content-Disposition: inline In-Reply-To: <877fnijgin.fsf@gnu.org> To: Ludovic =?iso-8859-1?Q?Court=E8s?= Cc: libc-alpha@sourceware.org, guix-devel@gnu.org List-Id: guix-devel.gnu.org On Tue, Sep 22, 2015 at 11:22:40PM +0200, Ludovic Courtès wrote: > Ondřej Bílka 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?