From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3089 invoked from network); 8 Nov 2022 03:08:44 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 8 Nov 2022 03:08:44 -0000 Received: (qmail 27759 invoked by uid 550); 8 Nov 2022 03:08:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 27724 invoked from network); 8 Nov 2022 03:08:40 -0000 Date: Mon, 7 Nov 2022 22:08:25 -0500 From: Rich Felker To: Dmitry Bogatov Cc: bug-gsasl@gnu.org, musl@lists.openwall.com Message-ID: <20221108030824.GG29905@brightrain.aerifal.cx> References: <20221106233904.GE29905@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="zqjkMoGlbUJ91oFe" Content-Disposition: inline In-Reply-To: <20221106233904.GE29905@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Behaviour of strverscmp(3) --zqjkMoGlbUJ91oFe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Nov 06, 2022 at 06:39:04PM -0500, Rich Felker wrote: > On Sun, Nov 06, 2022 at 06:18:22PM -0500, Dmitry Bogatov wrote: > > Hello. > > > > While trying to building gsasl statically with musl library as part of > > Nixpkgs distribution, I noticed that test built from tests/version.c > > fails when built with musl library. After a bit of troubleshooting, I > > can pinpoint the reason -- different behaviour of "strverscmp" from > > glibc and musl. > > > > Example code: > > > > #include > > #include > > > > int main() > > { > > int value = strverscmp("UNKNOWN", "2.2.0"); > > printf("%d\n", value); > > return 0; > > } > > > > Under glibc value "35" is printed (positive), under musl value "-1" is > > printed (negative). Not sure what is the correct solution for the > > issue, so I cross-post into two lists. > > > > For now I plan to patch-out this particular test. Thank you. > > It looks like we're neglecting to honor the exception case to "longer > digit sequence is greater" when one of the sequences is degenerate (no > digits). I think the attached patch fixes it in the most non-invasive way that's most clear in avoiding other unwanted side effects. It basically says "only apply the longest-digit-sequence" rule if there is a common nonzero length [[:digit:]]+ match (dp is the position where digit sequence starts, j is the test position). I think this code should be reviewed for additional bugs though. Rich --zqjkMoGlbUJ91oFe Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="strverscmp.diff" diff --git a/src/string/strverscmp.c b/src/string/strverscmp.c index 4daf276d..9e35422a 100644 --- a/src/string/strverscmp.c +++ b/src/string/strverscmp.c @@ -22,8 +22,8 @@ int strverscmp(const char *l0, const char *r0) /* If we're not looking at a digit sequence that began * with a zero, longest digit string is greater. */ for (j=i; isdigit(l[j]); j++) - if (!isdigit(r[j])) return 1; - if (isdigit(r[j])) return -1; + if (dp