On Fri, 24 Apr 2009, James Cloos wrote:
> It turns out that the off by one is intentional.
>
> >From upload-pack.c:
>
> /* Data ready; we keep the last byte to ourselves
> * in case we detect broken rev-list, so that we
> * can leave the stream corrupted. This is
> * unfortunate -- unpack-objects would happily
> * accept a valid packdata with trailing garbage,
> * so appending garbage after we pass all the
> * pack data is not good enough to signal
> * breakage to downstream.
> */
>
> Upload-pack uses a buffer of 8193 octets, which is why it is always
> the second xread() that returns 0xFFF. It first sends 8191 octets,
> then n chunks of 8192 and then the final chunk.
>
> It seems to only way to fix the progress annoyance -- and it is most
> annoying -- would be to round correctly in progress.c.
>
> (The .99 comes from 1023/1024, which is .999 and therefor ought to
> round up to 1.00, not down to 0.99.)
>
> Will a patch which does round-to-nearest (instead of the current
> round-to-zero) be accepted?
Sure. What about this (untested):
diff --git a/progress.c b/progress.c
index 55a8687..621c34e 100644
--- a/progress.c
+++ b/progress.c
@@ -121,13 +121,13 @@ static void throughput_string(struct throughput *tp, off_t total,
(int)(total >> 30),
(int)(total & ((1 << 30) - 1)) / 10737419);
} else if (total > 1 << 20) {
+ int x = total + 5243; /* for rounding */
l -= snprintf(tp->display, l, ", %u.%2.2u MiB",
- (int)(total >> 20),
- ((int)(total & ((1 << 20) - 1)) * 100) >> 20);
+ x >> 20, ((x & ((1 << 20) - 1)) * 100) >> 20);
} else if (total > 1 << 10) {
+ int x = total + 5; /* for rounding */
l -= snprintf(tp->display, l, ", %u.%2.2u KiB",
- (int)(total >> 10),
- ((int)(total & ((1 << 10) - 1)) * 100) >> 10);
+ x >> 10, ((x & ((1 << 10) - 1)) * 100) >> 10);
} else {
l -= snprintf(tp->display, l, ", %u bytes", (int)total);
}
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html