All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: "Hardik Kumar" <hardikxk@gmail.com>,
	git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	"René Scharfe" <l.s.r@web.de>, "Patrick Steinhardt" <ps@pks.im>,
	"Pablo Sabater" <pabloosabaterr@gmail.com>
Subject: Re: [PATCH v4] utf8: replace utf8_strwidth todo with descriptive comment
Date: Tue, 28 Jul 2026 16:41:11 +0100	[thread overview]
Message-ID: <c8fb2eba-c1c8-4f59-b467-e6d4766623d8@gmail.com> (raw)
In-Reply-To: <20260727211520.84289-1-hardikxk@gmail.com>

Hi Hardik

On 27/07/2026 22:15, Hardik Kumar wrote:
> The `utf8_strwidth()` function is used in multiple places that all
> expect the function to return an int. The result is directly used for
> padding and width calculations and passed to `printf()` calls. All
> these operations expect the function to return an int value. Changing
> the return type here requires changing the types of all the callers and

s/requires/would require/

> other additional variables, that depend on the results from this
> function directly or indirectly, to avoid overflow by implicit
> conversions.
> 
> The comment precisely explains the reason why the explicit conversion is
> done.

I don't think this comment, or the lines below add anything useful to 
the message. It would be better to say something like

As we do not want to change the return type, update the comment to 
explain that and the need for the explicit cast.

> - Remove an old TODO that is no longer feasible.
> - Add a comment explaining the behaviour and reason of the allowed
> expression.
> 
> Signed-off-by: Hardik Kumar <hardikxk@gmail.com>
> ---
> changes in v4:
> - drop the todo implementation and remove from codebase.
> - replace the todo with a reasonable explanation for the current
> approach and why its not worth the change.
> 
>   utf8.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/utf8.c b/utf8.c
> index 96460cc..1b55bd4 100644
> --- a/utf8.c
> +++ b/utf8.c
> @@ -227,8 +227,9 @@ int utf8_strnwidth(const char *string, size_t len, int skip_ansi)
>   	}
>   
>   	/*
> -	 * TODO: fix the interface of this function and `utf8_strwidth()` to
> -	 * return `size_t` instead of `int`.
> +	 * The function is used in multiple locations where the callers
> +	 * expect the result to be a signed int value. We cast the
> +	 * result to an int to avoid changing signatures of all callers.

The last sentence does not really capture the reasons given in the 
message of the commit that added this comment. If you haven't done so 
already you should read it - see 937b71cc8b (utf8: fix overflow when 
returning string width, 2022-12-01). The fundamental reason to call 
cast_size_t_to_int(), rather than relying on an implicit conversion to 
the return type, is not about changing signatures, it is about avoiding 
an overflow that caused git to crash.

When you send a new version of the patch please CC everyone who 
commented on previous versions so they don't have to trawl the list to 
find it.

Thanks

Phillip



>   	 */
>   	return cast_size_t_to_int(string ? width : len);
>   }


  reply	other threads:[~2026-07-28 15:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-26 12:34 [PATCH] change utf8_strwidth() return type to size_t Hardik Kumar
2026-07-26 13:41 ` René Scharfe
2026-07-26 15:50   ` Hardik Kumar
2026-07-26 14:52 ` Pablo Sabater
2026-07-26 15:52   ` Hardik Kumar
2026-07-26 19:57   ` [PATCH v2] utf8: use size_t for string width methods and callee sites Hardik Kumar
2026-07-27  0:06     ` Junio C Hamano
2026-07-27  4:02       ` Junio C Hamano
2026-07-27  6:42         ` Hardik Kumar
2026-07-27  1:06     ` Pablo Sabater
2026-07-27  6:40       ` Hardik Kumar
2026-07-27  6:59 ` [PATCH v3] utf8: make utf8_strwidth() and utf8_strnwidth() return size_t Hardik Kumar
2026-07-27  7:04   ` Hardik Kumar
2026-07-27 12:51   ` Phillip Wood
2026-07-27 14:55     ` Junio C Hamano
2026-07-27 16:20       ` Hardik Kumar
2026-07-27 19:52         ` Junio C Hamano
2026-07-27 16:13     ` Hardik Kumar
2026-07-27 21:15 ` [PATCH v4] utf8: replace utf8_strwidth todo with descriptive comment Hardik Kumar
2026-07-28 15:41   ` Phillip Wood [this message]
2026-07-28 17:04     ` Hardik Kumar
2026-07-28 18:24     ` Junio C Hamano
2026-07-28 17:02 ` [PATCH v5] " Hardik Kumar

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=c8fb2eba-c1c8-4f59-b467-e6d4766623d8@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hardikxk@gmail.com \
    --cc=l.s.r@web.de \
    --cc=pabloosabaterr@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=ps@pks.im \
    /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.