From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2418 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: Fix strverscmp Date: Wed, 5 Dec 2012 18:21:01 -0800 Message-ID: <20121205182101.d997eb6e.idunham@lavabit.com> References: <20121205110959.87b6111a.idunham@lavabit.com> <20121205193520.GN20323@brightrain.aerifal.cx> <20121205164329.c5cd3a20.idunham@lavabit.com> <20121206010000.GO20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1354760479 7605 80.91.229.3 (6 Dec 2012 02:21:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2012 02:21:19 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2419-gllmg-musl=m.gmane.org@lists.openwall.com Thu Dec 06 03:21:32 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TgR5b-0005GN-UF for gllmg-musl@plane.gmane.org; Thu, 06 Dec 2012 03:21:28 +0100 Original-Received: (qmail 30297 invoked by uid 550); 6 Dec 2012 02:21:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 30289 invoked from network); 6 Dec 2012 02:21:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=F7BMmSFreBNAG/DFUyw4fmM5wed6JMvROE9gpnjX4uUqhDrehmBAy8mvF/YwHLaarMLbFnTl+/sfuHFgCgfN7yiftaB6LYAem/JRzvXo0yNhIKIgm3o6aPpI+oVb8RndJz7R76gwU6fSUQN6bu0UEW8BWV/MgMjV9bbjLmppwXs=; h=Date:From:To:Subject:Message-Id:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; In-Reply-To: <20121206010000.GO20323@brightrain.aerifal.cx> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; i486-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:2418 Archived-At: On Wed, 5 Dec 2012 20:00:00 -0500 Rich Felker wrote: > > 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... > > My understanding of the code is that, after it hits the first place > where the strings differ, it switches to reading a digit string as a > decimal number, and the result is the difference of those decimal > numbers. I just used the decimal point as an example because it > terminates the loop. More-or-less, except that if the character is a number, it is expected to backtrack to the start of the longest substring which is purely numeric (the specification is rather insane, I think) > I also don't understand what you mean about leading zero. If leading > zeros are not considered equal to the number without leading zeros, They are explicitly stated to be different in the man page: " What this function does is the following. If both strings are equal, return 0. Otherwise find the position between two bytes with the prop- erty that before it both strings are equal, while directly after it there is a difference. Find the largest consecutive digit strings con- taining (or starting at, or ending at) this position. If one or both of these is empty, then return what strcmp(3) would have returned (numerical ordering of byte values). Otherwise, compare both digit strings numerically, where digit strings with one or more leading zeros are interpreted as if they have a decimal point in front (so that in particular digit strings with more leading zeros come before digit strings with fewer leading zeros). Thus, the ordering is 000, 00, 01, 010, 09, 0, 1, 9, 10. " > then a simple algorithm would be to, on the first mismatching byte, > remember the difference, then count the number of consecutive digits > starting at that position in both strings. If this count is the same > (possibly zero) for both strings, return the saved byte difference. If > the count is different, consider the string with fewer digits to be > less than the one with more digits. This is trivial to implement with > no arithmetic, but I'm not sure it matches the original semantics. Hmm... I'm getting the idea that that may actually work...in which case my last version is unneeded. Except, it breaks here: 00123 001145 <-should be the lesser (the leading zeros) OTOH, it could be done by recording the zero while walking up the chain: /*NOT tested*/ while (*l && *r && l[0]==r[0]){ if (l[0]='0'){ nozero=1; } else if (!isdigit(l[0])) { nozero=0; } l++; r++; } if ((isdigit(l[0]) && isdigit(r[0]) && nozero) { //return the one with the longer substring of numbers } else { return (l[0] - r[0]); } -- Isaac Dunham