This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: strxfrm output stability
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 9 Sep 2015 13:47:52 +0200
- Subject: Re: strxfrm output stability
- Authentication-results: sourceware.org; auth=none
- References: <55EF4F95 dot 4020703 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1509082115520 dot 24360 at digraph dot polyomino dot org dot uk>
On 09/08/2015 11:33 PM, Joseph Myers wrote:
> On Tue, 8 Sep 2015, Florian Weimer wrote:
>
>> Why is it acceptable to change the strxfrm output between glibc
>> releases, as implied by several bug reports (e.g. bug 18927)? Doesn't
>> this break backwards compatibility in a major way?
>
> I think strxfrm output is much like the layout of lots of internal types -
> it's valid within a process (as long as LC_COLLATE is the same at both
> calls), but not necessarily stable over time (type sizes, alignment,
> offsets of public fields etc. need to be stable, but the internal layout
> of an opaque type need not be). It's inevitable that fixing incorrect
> collation, updating collation for new national and international standards
> and for new Unicode characters, etc. will involve changing the output.
Okay, fair enough. Can we put this into the documentation?
> Cf. <https://sourceware.org/ml/libc-help/2015-07/msg00001.html> (regarding
> strcoll being used for on-disk database indexes). This seems like
> something to document for distributors: when a glibc upgrade to a new
> release is installed, the upgrade process should automatically reindex
> affected databases. (I don't know if distributions already do this, but
> central documentation of such things for distributors seems like a good
> idea anyway.)
That could be documented as well.
--
Florian Weimer / Red Hat Product Security