From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= <neleai@seznam.cz>
Subject: Re: [PATCH] Gracefully handle incompatible locale data
Date: Tue, 22 Sep 2015 21:18:04 +0200
Message-ID: <20150922191804.GA13637@domone>
References: <876132lbic.fsf@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-path: <libc-alpha-return-63427-glibc-alpha=m.gmane.org@sourceware.org>
List-Unsubscribe: <mailto:libc-alpha-unsubscribe-glibc-alpha=m.gmane.org@sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Content-Disposition: inline
In-Reply-To: <876132lbic.fsf@gnu.org>
To: Ludovic =?iso-8859-1?Q?Court=E8s?= <ludo@gnu.org>
Cc: libc-alpha@sourceware.org, guix-devel@gnu.org
List-Id: guix-devel.gnu.org

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?