All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: git@vger.kernel.org, ps@pks.im, sunshine@sunshineco.com,
	"Sören Krecker" <soekkle@freenet.de>
Subject: Re: [PATCH v3 1/4] add-patch: Fix type conversion warnings from msvc
Date: Wed, 29 Jan 2025 11:52:49 -0800	[thread overview]
Message-ID: <xmqqsep1iei6.fsf@gitster.g> (raw)
In-Reply-To: <6a251603-25bc-415d-ab8c-ae698bd7977a@gmail.com> (Phillip Wood's message of "Wed, 29 Jan 2025 16:51:42 +0000")

Phillip Wood <phillip.wood123@gmail.com> writes:

> I'm afraid I'm still not convinced this is a good idea for the reasons
> I explained previously [1] together with an alternative approach to
> silencing these warnings. What makes "unsigned long" an incorrect
> choice when that's what "git diff" and "git apply" use?
>
> [1]
> https://lore.kernel.org/git/e396131c-1bd3-46d0-bae6-cd97ca9710d8@gmail.com

Ah, this patch still does that?  I was hoping that it got corrected
already after it was pointed out in the previous iterations.  I
agree with you that size_t is a dubious type to use for the line
numbers there.

diff.c defines "struct emit_callback" with lno_in_{pre,post}image
members that are of type "int", which is somewhat dubious, too, but
at least we don't run on 16-bit machines, and being limited to 2
billion lines is probably OK.  I am OK to upgrade that to long (if
we use negative values for some oob signal) or ulong, but that is
clearly outside of this topic.



>> Add macro str_to_size_t for converting a string to size_t.
>> Test if convertion fails with over or underflow.
>
> That is welcome, but the implementation needs tweaking. If you look at
> other uses of strtoul() in our code you'll see that (somewhat
> unusually) one needs to set errno to zero before calling strtoul() as
> one cannot tell from the return value whether there was an error or
> not. As errno may have been set by a previous function call it needs
> to be cleared before calling strtoul() so we can be sure the error
> came from strtoul().

Nice advice.

> Best Wishes
>
> Phillip

Thanks.


By the way, who is
<CAPig+cQ49Hdc_8=mRhhJDTny_Kqo6Wg6Nr98rsBN_YXmBrQ6kA@mail.gmail.com>
and why is such an apparently bogus e-mail address Cc'ed?



  reply	other threads:[~2025-01-29 19:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-26 12:56 [PATCH v3 0/4] Fix type conversion Warings from msvc Sören Krecker
2025-01-26 12:56 ` [PATCH v3 1/4] add-patch: Fix type conversion warnings " Sören Krecker
2025-01-27  7:26   ` Patrick Steinhardt
2025-01-27 16:10     ` Junio C Hamano
2025-01-29 16:51   ` Phillip Wood
2025-01-29 19:52     ` Junio C Hamano [this message]
2025-01-30 10:47       ` Phillip Wood
2025-01-30 19:24         ` Junio C Hamano
2025-01-27  7:26 ` [PATCH v3 0/4] Fix type conversion Warings " Patrick Steinhardt

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=xmqqsep1iei6.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood123@gmail.com \
    --cc=ps@pks.im \
    --cc=soekkle@freenet.de \
    --cc=sunshine@sunshineco.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.