All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Tan <jonathantanmy@google.com>
To: Elijah Newren <newren@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 2/4] progress: fix progress meters when dealing with lots of work
Date: Mon, 13 Nov 2017 12:28:34 -0800	[thread overview]
Message-ID: <20171113122834.20a69d1e87defe95d6e0e8ed@google.com> (raw)
In-Reply-To: <20171113201600.24878-3-newren@gmail.com>

On Mon, 13 Nov 2017 12:15:58 -0800
Elijah Newren <newren@gmail.com> wrote:

> The possibility of setting merge.renameLimit beyond 2^16 raises the
> possibility that the values passed to progress can exceed 2^32.
> Use uint64_t, because it "ought to be enough for anybody".  :-)
> 
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
> This does imply 64-bit math for all progress operations.  Possible alternatives
> I could think of listed at
> https://public-inbox.org/git/CABPp-BH1Cpc9UfYpmBBAHWSqadg=QuD=28qx1oV29ZdvF4NbJw@mail.gmail.com/
> Opinions of others on whether 64-bit is okay, or preference for which alternative
> is picked?

I haven't looked into this in much detail, but another alternative to
consider is to use size_t everywhere. This also allows us to use st_add
and st_mult, which checks overflow for us.

Changing progress to use the size_t of the local machine makes sense to
me.

  reply	other threads:[~2017-11-13 20:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 20:15 [PATCH v2 0/4] Fix issues with rename detection limits Elijah Newren
2017-11-13 20:15 ` [PATCH v2 1/4] sequencer: warn when internal merge may be suboptimal due to renameLimit Elijah Newren
2017-11-13 20:15 ` [PATCH v2 2/4] progress: fix progress meters when dealing with lots of work Elijah Newren
2017-11-13 20:28   ` Jonathan Tan [this message]
2017-11-13 21:33   ` Jonathan Tan
2017-11-13 22:26     ` Elijah Newren
2017-11-13 20:15 ` [PATCH v2 3/4] Remove silent clamp of renameLimit Elijah Newren
2017-11-13 20:16 ` [PATCH v2 4/4] sequencer: show rename progress during cherry picks Elijah Newren

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=20171113122834.20a69d1e87defe95d6e0e8ed@google.com \
    --to=jonathantanmy@google.com \
    --cc=git@vger.kernel.org \
    --cc=newren@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.