public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Corinna Vinschen <vinschen@redhat.com>
To: Brian Inglis <Brian.Inglis@systematicsw.ab.ca>
Cc: newlib@sourceware.org
Subject: Re: strverscmp is buggy in newlib 4.4.0 (was Cygwin 3.4.6)
Date: Mon, 8 Jan 2024 13:16:09 +0100	[thread overview]
Message-ID: <ZZvniVEZFxbxEEnT@calimero.vinschen.de> (raw)
In-Reply-To: <53a5a442-6871-4227-a565-ae8d11dc2a58@SystematicSW.ab.ca>

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 <string.h>
> > > 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 <dalias@aerifal.cx>
> 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
> 


  reply	other threads:[~2024-01-08 12:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <13421190.uLZWGnKmhe@nimes>
2024-01-02 17:36 ` strverscmp is buggy in newlib 4.4.0 (was: " Brian Inglis
2024-01-04 12:28   ` strverscmp is buggy in newlib 4.4.0 (was " Brian Inglis
2024-01-08 12:16     ` Corinna Vinschen [this message]
     [not found] ` <1052086998.4232956.1704227350804@mail.yahoo.com>
2024-01-02 21:28   ` strverscmp is buggy in newlib 4.4.0 (was: " Brian Inglis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZZvniVEZFxbxEEnT@calimero.vinschen.de \
    --to=vinschen@redhat.com \
    --cc=Brian.Inglis@systematicsw.ab.ca \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).