From mboxrd@z Thu Jan  1 00:00:00 1970
From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Subject: Re: [PATCH] Gracefully handle incompatible locale data
Date: Tue, 22 Sep 2015 23:22:40 +0200
Message-ID: <877fnijgin.fsf@gnu.org>
References: <876132lbic.fsf@gnu.org> <20150922191804.GA13637@domone>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55792)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1ZeV1S-0000WK-EW
	for guix-devel@gnu.org; Tue, 22 Sep 2015 17:22:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1ZeV1P-0005y2-SM
	for guix-devel@gnu.org; Tue, 22 Sep 2015 17:22:46 -0400
In-Reply-To: <20150922191804.GA13637@domone> (=?utf-8?Q?=22Ond=C5=99ej_B?=
	=?utf-8?Q?=C3=ADlka=22's?= message of
	"Tue, 22 Sep 2015 21:18:04 +0200")
List-Id: "Development of GNU Guix and the GNU System distribution."
	<guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/guix-devel>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
To: =?utf-8?B?T25kxZllaiBCw61sa2E=?= <neleai@seznam.cz>
Cc: guix-devel@gnu.org, libc-alpha@sourceware.org

Ond=C5=99ej B=C3=ADlka <neleai@seznam.cz> skribis:

> On Tue, Sep 22, 2015 at 05:27:55PM +0200, Ludovic Court=C3=A8s 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:
>>=20
>>   loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_n=
l_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed.
>>=20
>> This patch changes such conditions to return EINVAL instead of aborting.
>>=20
>> WDYT?
>>=20
> 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.

Ludo=E2=80=99.
c