strxfrm output stability

[Florian Weimer]

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