From: "Carlos O'Donell" <carlos@redhat.com>
To: "Allan McRae" <allan@archlinux.org>, "Ludovic Courtès" <ludo@gnu.org>
Cc: "Ondřej Bílka" <neleai@seznam.cz>,
libc-alpha@sourceware.org, guix-devel@gnu.org,
"Roland McGrath" <roland@hack.frob.com>
Subject: Re: [PATCH] Gracefully handle incompatible locale data
Date: Tue, 13 Oct 2015 09:31:49 -0400 [thread overview]
Message-ID: <561D07C5.6000604@redhat.com> (raw)
In-Reply-To: <561C5525.40501@archlinux.org>
On 10/12/2015 08:49 PM, Allan McRae wrote:
> On 29/09/15 06:54, Carlos O'Donell wrote:
>> 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.
>>
>
> If I am reading this correctly, the change to from an abort to EINVAL
> would be fine if it is accompanied by a change to localedef
> --list-archive. Is that correct?
>
> A solution to this would be great given we now run into this assert with
> locale archives built with different glibc builds along the 2.22 release
> branch.
Yes.
I'll make some general comments in the thread you started about the patch,
rather than here.
Cheers,
Carlos.
next prev parent reply other threads:[~2015-10-13 13:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 15:27 [PATCH] Gracefully handle incompatible locale data Ludovic Courtès
2015-09-22 18:26 ` Roland McGrath
2015-09-22 19:18 ` Ondřej Bílka
2015-09-22 21:22 ` Ludovic Courtès
2015-09-22 21:50 ` Ondřej Bílka
2015-09-23 21:45 ` Ludovic Courtès
2015-09-24 8:27 ` Ondřej Bílka
2015-09-24 16:12 ` Ludovic Courtès
2015-09-25 21:20 ` Carlos O'Donell
2015-09-26 10:24 ` Ludovic Courtès
2015-09-28 20:54 ` Carlos O'Donell
2015-09-29 8:08 ` Ludovic Courtès
2015-10-08 10:31 ` Ludovic Courtès
2015-10-13 13:30 ` Carlos O'Donell
2015-10-13 14:45 ` Ludovic Courtès
2015-10-28 5:38 ` Carlos O'Donell
2015-10-13 0:49 ` Allan McRae
2015-10-13 9:50 ` Ludovic Courtès
2015-10-13 13:31 ` Carlos O'Donell [this message]
2015-09-23 6:59 ` Andreas Schwab
2015-09-23 7:03 ` Andreas Schwab
2015-09-24 2:15 ` Mark H Weaver
2015-09-24 19:32 ` Ludovic Courtès
2015-10-27 15:30 ` Samuel Thibault
2015-10-27 15:57 ` Ludovic Courtès
2015-10-28 6:19 ` Carlos O'Donell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=561D07C5.6000604@redhat.com \
--to=carlos@redhat.com \
--cc=allan@archlinux.org \
--cc=guix-devel@gnu.org \
--cc=libc-alpha@sourceware.org \
--cc=ludo@gnu.org \
--cc=neleai@seznam.cz \
--cc=roland@hack.frob.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.