From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6304 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: wrong behaviour of 'strverscmp' Date: Mon, 13 Oct 2014 18:20:51 -0400 Message-ID: <20141013222051.GI32028@brightrain.aerifal.cx> References: <543B5BE2.6020104@i-soft.com.cn> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1413238873 31074 80.91.229.3 (13 Oct 2014 22:21:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Oct 2014 22:21:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6317-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 14 00:21:07 2014 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 1XdnzF-0008EB-RV for gllmg-musl@plane.gmane.org; Tue, 14 Oct 2014 00:21:05 +0200 Original-Received: (qmail 28575 invoked by uid 550); 13 Oct 2014 22:21:03 -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 28566 invoked from network); 13 Oct 2014 22:21:03 -0000 Content-Disposition: inline In-Reply-To: <543B5BE2.6020104@i-soft.com.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6304 Archived-At: On Mon, Oct 13, 2014 at 12:58:10PM +0800, 黄建忠 wrote: > Hi, > > When I try to run some testcases, I found 'strverscmp' do not work like > expected. > > According to man page, 'Thus, the ordering is 000, 00, 01, 010, 09, 0, > 1, 9, 10.'. > > So the return value of strverscmp('000', '00) should less than zero, but > musl return '0'-0(*l - *r), that is 48. Confirmed that musl's strverscmp mismatches your expectations. Myself and others think the expected behavior is ridiculous, but it's the documented behavior and it's not very useful to provide an implementation of a nonstandard function that doesn't match the one present on systems that defined it, so this should be changed. Of course we cannot use code from gnulib, though. I'll put fixing this on the agenda and hopefully we can get it in the next release after the upcoming 1.1.5 release. Thanks for the report. Rich