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: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Florian Weimer <fweimer at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 8 Sep 2015 22:14:50 +0000
- Subject: Re: strxfrm output stability
- Authentication-results: sourceware.org; auth=none
- References: <55EF4F95 dot 4020703 at redhat dot com> <20150908211805 dot 36E5E2C3A73 at topped-with-meat dot com> <55EF529E dot 7070108 at redhat dot com> <55EF5494 dot 8030506 at cs dot ucla dot edu>
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.
<http://python3porting.com/problems.html>: "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