From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9530 Path: news.gmane.org!not-for-mail From: "dalias@libc.org" Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] search: call user compare with "correct" order params Date: Tue, 8 Mar 2016 12:24:05 -0500 Message-ID: <20160308172405.GD9349@brightrain.aerifal.cx> References: <1456315949-16347-1-git-send-email-karlp@tweak.net.au> <20160224174126.GR9349@brightrain.aerifal.cx> <1457437382.3898.43.camel@etactica.com> 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 1457457868 10932 80.91.229.3 (8 Mar 2016 17:24:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Mar 2016 17:24:28 +0000 (UTC) Cc: "musl@lists.openwall.com" , "karlp@tweak.net.au" To: Karl =?utf-8?Q?P=C3=A1lsson?= Original-X-From: musl-return-9543-gllmg-musl=m.gmane.org@lists.openwall.com Tue Mar 08 18:24:27 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1adLMw-0005NE-Mi for gllmg-musl@m.gmane.org; Tue, 08 Mar 2016 18:24:26 +0100 Original-Received: (qmail 5674 invoked by uid 550); 8 Mar 2016 17:24:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5649 invoked from network); 8 Mar 2016 17:24:21 -0000 Content-Disposition: inline In-Reply-To: <1457437382.3898.43.camel@etactica.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9530 Archived-At: On Tue, Mar 08, 2016 at 11:43:03AM +0000, Karl Pálsson wrote: > On Wed, 2016-02-24 at 12:41 -0500, Rich Felker wrote: > > > I've read some of the scrollback from the discussion of this on IRC, > > and I think: > > > > 1. Regardless of whether the patch is accepted or not, applications > > using this interface in non-portable ways should be fixed. > > > > 2. As you said, lfind/lsearch are useless functions. Aside from the > > order of the arguments being unspecified (which doesn't hurt code > > using them in the intended way), they're just going to be a lot > > slower than inlining the comparison in your own for loop. > > > > Is there existing software that's affected by this issue for which > > it's hard to get a fix upstream? > > Given that musl has two choices: > > a) compliant with POSIX > b) compliant with POSIX, uclibc, glibc, bsdlibc > > I find it rather disappointing that the first response is "your > application is wrong" rather than, "yeah, option (b) does sound better" > > Given how vague the actual posix docs are on these functions, yes, it's > a bad idea to ever use them. However, given how vague the actual posix > docs are, I think it's hard to say whether the way I was using lfind > was actually not allowed. (lsearch, sure, it has to insert) > Regardless, I have "fixed" my application. Maybe you could "fix" musl > to be as equally compliant as ever before, and completely cut off > anyone else ever having to even have this discussion again? I'm not rejecting it; I'm just backlogged with lots of things and was waiting for feedback from the community on this. Adding new contracts beyond the specified contract for an interface is a big deal and sometimes has unforseen consequences. This is probably not such a case, but we've been bitten by it before -- adding a nonstandard behavior only to find out later that properly supporting it imposes costly constraints elsewhere. It wasn't my intent with the previous reply to be hostile, just to express that the portable solution is already better for multiple reasons (especially, performance and simplicity in the caller). Rich