[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1457437382.3898.43.camel@etactica.com>
Date: Tue, 8 Mar 2016 11:43:03 +0000
From: Karl Pálsson <karlp@...ctica.com>
To: "dalias@...c.org" <dalias@...c.org>, "musl@...ts.openwall.com"
<musl@...ts.openwall.com>
CC: "karlp@...ak.net.au" <karlp@...ak.net.au>
Subject: Re: [PATCH] search: call user compare with "correct" order
params
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
