This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: strxfrm output stability
- From: Florian Weimer <fweimer at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, Roland McGrath <roland at hack dot frob dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 9 Sep 2015 13:45:32 +0200
- 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 09/08/2015 11:35 PM, Paul Eggert wrote:
> Florian Weimer wrote:
>> I don't see this documented anywhere
>
> Exactly. Because the behavior is undocumented, applications cannot rely
> on strxfrm calls being stable from one process to the next.
Well, the same is true for reading files written by another program.
The C standard does not guarantee you'll get the bytes as written by the
other program (only by an execution of the same program, subject to a
few additional tweaks), and yet programmers have a reasonable
expectation that what program A writes to a file can be read back by
program B.
>> 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.
PostgreSQL uses it to avoid calling strcoll on strings which have
distinctly ordered prefixes in their strxfrm output.
--
Florian Weimer / Red Hat Product Security