Re: strxfrm output stability

[Joseph Myers <joseph at codesourcery 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 
idea anyway.)

-- 
Joseph S. Myers
joseph@codesourcery.com