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

["Karl Pálsson" <karlp@etactica.com>]

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?

Sincerely,
Karl Palsson