This is the mail archive of the
mailing list for the glibc project.
Re: strxfrm output stability
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 8 Sep 2015 21:33:07 +0000
- Subject: Re: strxfrm output stability
- Authentication-results: sourceware.org; auth=none
- References: <55EF4F95 dot 4020703 at redhat dot com>
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.
It may be useful for different processes on the same system (including
32-bit / 64-bit processes) to have compatible strxfrm output - as long as
they are using the same glibc version and LC_COLLATE.
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
Joseph S. Myers