On Wed, 5 Dec 2012 14:35:21 -0500 Rich Felker 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