From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9378 Path: news.gmane.org!not-for-mail From: Karl Palsson Newsgroups: gmane.linux.lib.musl.general Subject: [PATCH] search: call user compare with "correct" order params Date: Wed, 24 Feb 2016 12:12:29 +0000 Message-ID: <1456315949-16347-1-git-send-email-karlp@tweak.net.au> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1456316310 7373 80.91.229.3 (24 Feb 2016 12:18:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Feb 2016 12:18:30 +0000 (UTC) Cc: Karl Palsson , Karl Palsson To: musl@lists.openwall.com Original-X-From: musl-return-9391-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 24 13:18:30 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 1aYYOi-0005Vk-QG for gllmg-musl@m.gmane.org; Wed, 24 Feb 2016 13:18:28 +0100 Original-Received: (qmail 3868 invoked by uid 550); 24 Feb 2016 12:18:26 -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 28577 invoked from network); 24 Feb 2016 12:12:41 -0000 X-Mailer: git-send-email 1.7.9.5 Xref: news.gmane.org gmane.linux.lib.musl.general:9378 Archived-At: From: Karl Palsson IEEE Std 1003.1, 2013 Edition only defines the two params to the user callback as, "The compar argument points to a comparison function which the application shall supply (for example, strcmp()). It is called with two arguments that point to the elements being compared." Both uclibc and glibc provide the arguments as, " The comparison function referenced by compar is expected to have two arguments which point to the key object and to an array member, in that order " Musl currently provides the arguments as array member, then key object. While this is strictly compliant with the standard, it's equally compliant to have the parameters in the other order. If you are using lfind to search a list of complex structures where the key is not the same type as each entry, having these parameters arrive in unexpectd order can/will result in segfaults. => Swap the order of the arguments to the user function, maintaining equal compatibility with the standard, and gaining compatibility with uclibc and glibc. Signed-off-by: Karl Palsson --- src/search/lsearch.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Please CC me on replies, I'm not (currently) a subscriber diff --git a/src/search/lsearch.c b/src/search/lsearch.c index 63f3192..5eb5cc2 100644 --- a/src/search/lsearch.c +++ b/src/search/lsearch.c @@ -9,7 +9,7 @@ void *lsearch(const void *key, void *base, size_t *nelp, size_t width, size_t i; for (i = 0; i < n; i++) - if (compar(p[i], key) == 0) + if (compar(key, p[i]) == 0) return p[i]; *nelp = n+1; return memcpy(p[n], key, width); @@ -23,7 +23,7 @@ void *lfind(const void *key, const void *base, size_t *nelp, size_t i; for (i = 0; i < n; i++) - if (compar(p[i], key) == 0) + if (compar(key, p[i]) == 0) return p[i]; return 0; } -- 2.4.3