This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Gracefully handle incompatible locale data


"Carlos O'Donell" <carlos@redhat.com> skribis:

> Despite Roland saying "LGTM", I think this is not a good change.
>
> Firstly, it's not the community consensus as Ondrej is pointing out.
>
> https://sourceware.org/glibc/wiki/Style_and_Conventions#Error_Handling

âAssertions are for internal consistency checking only.â  I would argue
that what this patch changes is not an internal consistency check.

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.

So it is not clear to me that the patch would be a violation of these
rules.  WDYT?

> It is a fundamental system misconfiguration issue not to have upgraded
> the binary locale data from one release to another.

I would not call it âmisconfiguration.â  With GNU Guix, unprivileged
users can install packages in their âprofileâ and they are free to
choose whether and when to upgrade those packages.  Consequently, they
might be using a libc version different from the one the system
administrator used to build the system-wide locale data.

Currently, the assertion failure greatly penalizes this use case:

  https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00717.html

Returning EINVAL instead of aborting would make things easier.

But itâs not perfect.  IMO, a discussion on improving the coexistence of
different libc/locale versions on the same system is in order.  But itâs
beyond the scope of this two-line patch.

Thanks,
Ludoâ.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]