This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strxfrm output stability

On Tue, 8 Sep 2015, Paul Eggert wrote:

> > The manual suggests to store the strxfrm output and use it for sorting.
> >  I expect that some applications put it into on-disk database indexes as
> > a result.  This will lead to subtle breakage on glibc updates.
> I'll go out on a limb and say that no sane application uses strxfrm, either on
> disk or off.  As far as I can tell, strxfrm is an invention of the C
> standardization committee and is useless in real-world applications.  So as a
> practical matter it is not a big deal as to how stable it is.

I've used strxfrm (and the ICU equivalent) in Python code, because Python 
3 requires key functions rather than comparison functions (cf. 
<>: "Because the cmp= parameter is 
removed in Python 3, sorting Unicode with locale.strcoll no longer works. 
In Python 3 you can use locale.strxfrm instead. ... [functools.cmp_to_key 
on strcoll is] much slower ...").  I've not used strxfrm in any context 
other than in-memory comparisons within a single process.

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]