From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Carlos O'Donell" Subject: Re: [PATCH] Gracefully handle incompatible locale data Date: Mon, 28 Sep 2015 16:54:01 -0400 Message-ID: <5609A8E9.7050201@redhat.com> References: <876132lbic.fsf@gnu.org> <20150922191804.GA13637@domone> <877fnijgin.fsf@gnu.org> <20150922215022.GA27201@domone> <8737y4hkrz.fsf@gnu.org> <20150924082755.GA4767@domone> <87h9mjeqyy.fsf@gnu.org> <5605BA8D.40907@redhat.com> <87h9mh5vgn.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 In-Reply-To: <87h9mh5vgn.fsf@gnu.org> To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= Cc: =?UTF-8?B?T25kxZllaiBCw61sa2E=?= , libc-alpha@sourceware.org, guix-devel@gnu.org, Roland McGrath List-Id: guix-devel.gnu.org On 09/26/2015 06:24 AM, Ludovic Courtès wrote: > Furthermore, the function in question returns EINVAL in other similar > cases–e.g., when libc 2.22 loads LC_COLLATE data from libc 2.21. If you change this particular case to EINVAL, what does the user see as a result of this change? Do they get a non-zero exit code from `localedef --list-archive` along with an error written out to stderr? This is the kind of change I'm expecting. If we are removing an assertion, we should be replacing it with something meaningful and verifying that meaningful change. You need not change any of the other cases you've found that return EINVAL, we can update those incrementally, but for this one change you're making we should fix it as best we can. Cheers, Carlos.