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: Wed, 23 Sep 2015 23:45:52 +0200
Message-ID: <8737y4hkrz.fsf@gnu.org>
References: <876132lbic.fsf@gnu.org> <20150922191804.GA13637@domone>
	<877fnijgin.fsf@gnu.org> <20150922215022.GA27201@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]:40986)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1Zes16-0001Fy-73
	for guix-devel@gnu.org; Wed, 23 Sep 2015 17:56:11 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1Zes10-0003d4-B3
	for guix-devel@gnu.org; Wed, 23 Sep 2015 17:55:55 -0400
In-Reply-To: <20150922215022.GA27201@domone> (=?utf-8?Q?=22Ond=C5=99ej_B?=
	=?utf-8?Q?=C3=ADlka=22's?= message of
	"Tue, 22 Sep 2015 23:50:22 +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 11:22:40PM +0200, Ludovic Court=C3=A8s wrote:
>> Ond=C5=99ej B=C3=ADlka <neleai@seznam.cz> skribis:
>>=20
>> > 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 versio=
n,
>> >> but they learn it the hard way:
>> >>=20
>> >>   loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof =
(_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' faile=
d.
>> >>=20
>> >> This patch changes such conditions to return EINVAL instead of aborti=
ng.
>> >>=20
>> >> WDYT?
>> >>=20
>> > While that assert is quite cryptic I dont see why just returning EINVA=
L is
>> > better. How do you distinguish that its wrong locale version versus not
>> > installed?
>>=20
>> The rest of this function already returns EINVAL when something is
>> fishy.  This patch makes the behavior more consistent.
>>=20
> 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.

> 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.)

In addition, there is no errno value to report this specific
version-mismatch diagnostic.

Ludo=E2=80=99.