From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 52A063858D28 for ; Mon, 8 Jan 2024 12:16:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 52A063858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 52A063858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704716175; cv=none; b=VYwjGnWWlGhZAN9j0nAr9Keu7Ew0shU6RwkwV8ZQC6jlz/Bhm436RepJb/3kOqYC/Tldqu7N94OkhL+1O/fUKVDQVkm15KIsY5tepWEo6w4pBTBBacQ0zmEM+U2ml+6P387dYC3Z6SdOXO+kJpWndrfLJ6NSltbOv9McBD7lbXg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704716175; c=relaxed/simple; bh=CYgZnW0RROMyXpP2vuHKzM3YDOw4jNByjzMZjBmNhOw=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=aHDeRM41tS7YbP5XTHQPXJvVF0WVfujqa1Zxan/K6WJdnj34B7KU3mOWmsq82M2Cdc2L/5ImsfRoGDAApDtiPUpoy6P7o0HpJAQS/c6cvx4Lgs/a1hikbGGnOqC8xpiFEGiAGDcvL18OUydTwzA7jrnTDmY1KiFkQnkvXgLDVd8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1704716172; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jpT/d3GOOnw5bgrz86fszEtGDq5ar+Lqk8bG+38v4f8=; b=Ux77gT4XQSVlGyDFsqw5MhtvByaez1xWBZajX9Q7f7LJwKYFtZgCyy3bU76L1xveVRPSpx ZYAn3GKdrvectNK24c0GKZjqdw9FELfSdkaXGN5padUdhPSh0vgZOKbvvNoLcja2mrRgCa p32RVvvTnM5phfkOfgrybh0tCbrZ50g= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-625-wEl7nNrnPmq5-YfaZGtyRg-1; Mon, 08 Jan 2024 07:16:11 -0500 X-MC-Unique: wEl7nNrnPmq5-YfaZGtyRg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 13BF2386A0BA; Mon, 8 Jan 2024 12:16:11 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.39.195.34]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E1B7CC15A0C; Mon, 8 Jan 2024 12:16:10 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id D177EA808A0; Mon, 8 Jan 2024 13:16:09 +0100 (CET) Date: Mon, 8 Jan 2024 13:16:09 +0100 From: Corinna Vinschen To: Brian Inglis Cc: newlib@sourceware.org Subject: Re: strverscmp is buggy in newlib 4.4.0 (was Cygwin 3.4.6) Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: Brian Inglis , newlib@sourceware.org References: <13421190.uLZWGnKmhe@nimes> <1f182ad0-bf0d-4cf7-9829-8b7e7cbd6b43@SystematicSW.ab.ca> <53a5a442-6871-4227-a565-ae8d11dc2a58@SystematicSW.ab.ca> MIME-Version: 1.0 In-Reply-To: <53a5a442-6871-4227-a565-ae8d11dc2a58@SystematicSW.ab.ca> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Brian, the patch doesn't apply cleanly because it refers to a non-existant file. Can you please provide the patch in a version suitable for newlib-cygwin? Thanks, Corinna On Jan 4 05:28, Brian Inglis wrote: > On 2024-01-02 10:36, Brian Inglis via Cygwin wrote: > > On 2024-01-02 03:23, Bruno Haible via Cygwin wrote: > > > Here's a test case of strverscmp, from Dmitry Bogatov [1] > > > #include > > > int main () > > > { > > >    return strverscmp ("UNKNOWN", "2.2.0") <= 0; > > > } > > > It succeeds on glibc and musl libc 1.2.4, but fails on musl libc 1.2.3 > > > and Cygwin 2.9.0 and 3.4.6. > > > The cause is apparently that Cygwin's strverscmp implementation was > > > borrowed from musl libc (Cygwin commit 59e09b6419cdf400be3c73b61ac9c22560dc397e) > > > at a time when musl libc's implementation was buggy. In musl libc, it is > > > meanwhile fixed, through > > > https://git.musl-libc.org/cgit/musl/commit/src/string/strverscmp.c?id=b50eb8c36c20f967bd0ed70c0b0db38a450886ba > > > [1] https://lists.gnu.org/archive/html/bug-gnulib/2024-01/msg00002.html > > > > Issue is in newlib (x-post and followups set): > > https://sourceware.org/cgit/newlib-cygwin/tree/newlib/libc/string/strverscmp.c > > > > patch with git log msg: > > https://git.musl-libc.org/cgit/musl/patch/src/string/strverscmp.c?id=b50eb8c36c20f967bd0ed70c0b0db38a450886ba > > This musl patch applies cleanly to newlib (patch offsets) and is attached. > > > Gnulib discussion: > > https://lists.gnu.org/archive/html/bug-gnulib/2024-01/msg00002.html > > > > Musl thread starts: > > https://www.openwall.com/lists/musl/2022/11/06/1 > > > > bare patch without git log msg attached to: > > https://www.openwall.com/lists/musl/2022/11/08/1 > -- > Take care. Thanks, Brian Inglis Calgary, Alberta, Canada > > La perfection est atteinte Perfection is achieved > non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add > mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut > -- Antoine de Saint-Exupéry > From b50eb8c36c20f967bd0ed70c0b0db38a450886ba Mon Sep 17 00:00:00 2001 > From: Rich Felker > Date: Mon, 7 Nov 2022 22:17:55 -0500 > Subject: fix strverscmp comparison of digit sequence with non-digits > > the rule that longest digit sequence not beginning with a zero is > greater only applies when both sequences being compared are > non-degenerate. this is spelled out explicitly in the man page, which > may be deemed authoritative for this nonstandard function: "If one or > both of these is empty, then return what strcmp(3) would have > returned..." > > we were wrongly treating any sequence of digits not beginning with a > zero as greater than a non-digit in the other string. > --- > src/string/strverscmp.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > (limited to 'src/string/strverscmp.c') > > diff --git a/src/string/strverscmp.c b/src/string/strverscmp.c > index 4daf276d..16c1da22 100644 > --- a/src/string/strverscmp.c > +++ b/src/string/strverscmp.c > @@ -18,9 +18,9 @@ int strverscmp(const char *l0, const char *r0) > else if (c!='0') z=0; > } > > - if (l[dp]!='0' && r[dp]!='0') { > - /* If we're not looking at a digit sequence that began > - * with a zero, longest digit string is greater. */ > + if (l[dp]-'1'<9U && r[dp]-'1'<9U) { > + /* If we're looking at non-degenerate digit sequences starting > + * with nonzero digits, longest digit string is greater. */ > for (j=i; isdigit(l[j]); j++) > if (!isdigit(r[j])) return 1; > if (isdigit(r[j])) return -1; > -- > cgit v1.2.1 >