|
Message-Id: <20121205164329.c5cd3a20.idunham@lavabit.com>
Date: Wed, 5 Dec 2012 16:43:29 -0800
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: Fix strverscmp
On Wed, 5 Dec 2012 14:35:21 -0500
Rich Felker <dalias@...ifal.cx> wrote:
> I'm not opposed to adding this, but the code has some bugs, most
> notably integer overflow. On filenames consisting of long digit
> strings, it will invoke undefined behavior. If the results are
> unpredictable, it might even cause qsort to invoke very bad undefined
> behavior.
The first I can see now (overflow -> l[-n]),
but I'm not understanding the second.
> It would also, for example, cause these two names to compare equal:
>
> - foobar-1.1.2
> - foobar-1.01.3
>
> just because the first component that differs textually compares equal
> numerically.
This should not be equal, but not for the reason I'd expected: a leading 0 is supposed to be interpreted as "0.0". Decimal points are not factored in...
>
> It also shares the same issues (which we should arguably duplicate
> anyway) with the original strverscmp, that names consisting of hex
> values get sorted in a ridiculous and harmful way.
Per the specification, hex is unsupported. It would be possible to support it, but it may be rather expensive in terms of size...
The attached is an attempt to figure out how it should work (more notes than final implementation).
It seems to get the right sign consistently, which is all that the manpage indicates can be counted on.
--
Isaac Dunham <idunham@...abit.com>
View attachment "strvers.c" of type "text/x-csrc" (1804 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.