All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: git@vger.kernel.org, "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: [PATCH v2 4/5] wildmatch: use char instead of uchar
Date: Mon, 27 Feb 2023 12:07:13 -0800	[thread overview]
Message-ID: <xmqqh6v6swi6.fsf@gitster.g> (raw)
In-Reply-To: <20230226115021.1681834-5-masahiroy@kernel.org> (Masahiro Yamada's message of "Sun, 26 Feb 2023 20:50:20 +0900")

Masahiro Yamada <masahiroy@kernel.org> writes:

> GIT has its own implementations, so the behavior is clear.
>
> In fact, commit 4546738b58a0 ("Unlocalized isspace and friends")
> says one of the motivations is "we want the right signed behaviour".
>
> sane_istest() casts the given character to (unsigned char) anyway
> before sane_ctype[] table lookup, so dowild() can use 'char'.

Use of values taken from a char/uchar in sane_istest() is designed
to be safe, and between using char*/uchar* to scan pieces of memory
would not make much difference, so changes like ...

>  		case '*':
>  			if (*++p == '*') {
> -				const uchar *prev_p = p - 2;
> +				const char *prev_p = p - 2;

... this is safe, and so is ...

> -				const char *slash = strchr((char*)text, '/');
> +				const char *slash = strchr(text, '/');

... this.

But does the comparison between t_ch_upper and prev_ch behave the
same with and without this patch?

> -						uchar t_ch_upper = toupper(t_ch);
> +						char t_ch_upper = toupper(t_ch);
>  						if (t_ch_upper <= p_ch && t_ch_upper >= prev_ch)

Here t_ch is already known to pass islower(), so t_ch_upper would be
within a reasonable range and "char" should be able to store it
safely without its value wrapping around to negative.  Do we have a
similar guarantee on prev_ch, or can it be more than 128, which
would have caused the original to say "t_ch_upper is smaller than
prev_ch" but now because prev_ch can wrap around to a negative
value, leading the conditional to behave differently, or something?

>  							matched = 1;
>  					}
>  					p_ch = 0; /* This makes "prev_ch" get set to 0. */
>  				} else if (p_ch == '[' && p[1] == ':') {
> -					const uchar *s;
> +					const char *s;
>  					int i;
>  					for (s = p += 2; (p_ch = *p) && p_ch != ']'; p++) {} /*SHARED ITERATOR*/
>  					if (!p_ch)
> @@ -237,5 +235,5 @@ static int dowild(const uchar *p, const uchar *text, unsigned int flags)
>  /* Match the "pattern" against the "text" string. */
>  int wildmatch(const char *pattern, const char *text, unsigned int flags)
>  {
> -	return dowild((const uchar*)pattern, (const uchar*)text, flags);
> +	return dowild(pattern, text, flags);
>  }

  reply	other threads:[~2023-02-27 20:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-26 11:50 [PATCH v2 0/5] Clean up wildmatch.c Masahiro Yamada
2023-02-26 11:50 ` [PATCH v2 1/5] git-compat-util: add isblank() and isgraph() Masahiro Yamada
2023-02-26 18:45   ` René Scharfe
2023-02-27 19:39     ` Junio C Hamano
2023-02-26 11:50 ` [PATCH v2 2/5] wildmatch: remove IS*() macros Masahiro Yamada
2023-02-26 11:50 ` [PATCH v2 3/5] wildmatch: remove NEGATE_CLASS(2) macros with trivial refactoring Masahiro Yamada
2023-02-26 11:50 ` [PATCH v2 4/5] wildmatch: use char instead of uchar Masahiro Yamada
2023-02-27 20:07   ` Junio C Hamano [this message]
2023-02-26 11:50 ` [PATCH v2 5/5] wildmatch: more cleanups after killing uchar Masahiro Yamada

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=xmqqh6v6swi6.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=pclouds@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.