strxfrm output stability
Joseph Myers
joseph@codesourcery.com
Tue Sep 8 21:33:00 GMT 2015
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
idea anyway.)
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list