Re: bug report: symbolic-ref --short command echos the wrong text while use Chinese language

From

Jeff King <peff@peff.net>

Date

Feb 14, 2023, 01:39 UTC

Message-ID

<Y+rmNvfjIA/u81em@coredump.intra.peff.net>

In-Reply-To

<CAPig+cQ9f0aW0TcP9A5WrKmYcQsEZvPOiPrgmzsy1frWkHd34w@mail.gmail.com>

On Mon, Feb 13, 2023 at 05:58:06PM -0500, Eric Sunshine wrote:

> I am able to reproduce the broken behavior on maOS 10.13.

That's helpful.

> > Are your on-disk bytes different?
> 
> I get the exact same results (on HFS+) as you show:

If you do something like the patch below:

diff --git a/refs.c b/refs.c
index e31dbcda59..2fa53fef7f 100644
--- a/refs.c
+++ b/refs.c
@@ -1350,7 +1350,8 @@ char *refs_shorten_unambiguous_ref(struct ref_store *refs,
 		return xstrdup(refname);
 
 	/* buffer for scanf result, at most refname must fit */
-	short_name = xstrdup(refname);
+	warning("strlen(refname) = %d", (int)strlen(refname));
+	short_name = xcalloc(1, 2*strlen(refname));
 
 	/* skip first rule, it will always match */
 	for (i = nr_rules - 1; i > 0 ; --i) {
@@ -1362,6 +1363,7 @@ char *refs_shorten_unambiguous_ref(struct ref_store *refs,
 			continue;
 
 		short_name_len = strlen(short_name);
+		warning("strlen(short_name) = %d", (int)short_name_len);
 
 		/*
 		 * in strict mode, all (except the matched one) rules

Does it help at all? And if so, is short_name_len longer than we might
expect it to be (I get 39 for the full refname and 28 for the scanf'd
name).  I'm having trouble coming up with a reason that the scanf value
_would_ be unexpectedly long, but just trying to rule things out.

-Peff