Re: [PATCH] search: call user compare with "correct" order params

["dalias@libc.org" <dalias@libc.org>]

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