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 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

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