[PATCH] packfile: use extra variable to clarify code in use_pack()

[PATCH] packfile: use extra variable to clarify code in use_pack()

[Ramsay Jones]

From: Jeff King <peff@peff.net>

We use the "offset" variable for two purposes. It's the offset into
the packfile that the caller provides us (which is rightly an off_t,
since we might have a packfile much larger than memory). But later we
also use it as the offset within a given mmap'd window, and that
window cannot be larger than a size_t.

For the second use, the fact that we have an off_t leads to some
confusion when we assign it to the "left" variable, which is a size_t.
It is in fact correct (because our earlier "offset -= win->offset" means
we must be within the pack window), but using a separate variable of the
right type makes that much more obvious.

Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
---

Hi Junio,

As promised, I am forwarding a 'saved' patch from Jeff, which was
a by-product of a long-ago discussion regarding commit 5efde212fc
("zlib.c: use size_t for size", 2018-10-14).

I have tested this patch on 'pu' (@6fd68134c8) and directly on top
of commit 5efde212fc. (see branch 'mk/use-size-t-in-zlib').

However, whilst I have been waiting for the tests to finish, I have
been looking at the code and concluded that this does not _have_ to
be applied on top of commit 5efde212fc. (I haven't done it, but just
tweak the context line to read 'unsigned long *left)' rather than
'size_t *left)' and this should apply cleanly to 'master'. Also, it
would have _exactly_ the same effect as the current code! ;-) ).

So, dunno.

ATB,
Ramsay Jones


 packfile.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/packfile.c b/packfile.c
index b0efe8cb3d..0e59f929c5 100644
--- a/packfile.c
+++ b/packfile.c
@@ -622,6 +622,7 @@ unsigned char *use_pack(struct packed_git *p,
 		size_t *left)
 {
 	struct pack_window *win = *w_cursor;
+	size_t offset_in_window;
 
 	/* Since packfiles end in a hash of their content and it's
 	 * pointless to ask for an offset into the middle of that
@@ -683,10 +684,14 @@ unsigned char *use_pack(struct packed_git *p,
 		win->inuse_cnt++;
 		*w_cursor = win;
 	}
-	offset -= win->offset;
+	/*
+	 * We know this difference will fit in a size_t, because our mmap
+	 * window by definition can be no larger than a size_t.
+	 */
+	offset_in_window = xsize_t(offset - win->offset);
 	if (left)
-		*left = win->len - xsize_t(offset);
-	return win->base + offset;
+		*left = win->len - offset_in_window;
+	return win->base + offset_in_window;
 }
 
 void unuse_pack(struct pack_window **w_cursor)
-- 
2.21.0

Re: [PATCH] packfile: use extra variable to clarify code in use_pack()

[Ramsay Jones]

On 13/03/2019 21:49, Ramsay Jones wrote:
> From: Jeff King <peff@peff.net>
> 
> We use the "offset" variable for two purposes. It's the offset into
> the packfile that the caller provides us (which is rightly an off_t,
> since we might have a packfile much larger than memory). But later we
> also use it as the offset within a given mmap'd window, and that
> window cannot be larger than a size_t.
> 
> For the second use, the fact that we have an off_t leads to some
> confusion when we assign it to the "left" variable, which is a size_t.
> It is in fact correct (because our earlier "offset -= win->offset" means
> we must be within the pack window), but using a separate variable of the
> right type makes that much more obvious.
> 
> Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
> ---
> 
> Hi Junio,
> 
> As promised, I am forwarding a 'saved' patch from Jeff, which was
> a by-product of a long-ago discussion regarding commit 5efde212fc
> ("zlib.c: use size_t for size", 2018-10-14).
> 
> I have tested this patch on 'pu' (@6fd68134c8) and directly on top
> of commit 5efde212fc. (see branch 'mk/use-size-t-in-zlib').
> 
> However, whilst I have been waiting for the tests to finish, I have
> been looking at the code and concluded that this does not _have_ to
> be applied on top of commit 5efde212fc. (I haven't done it, but just
> tweak the context line to read 'unsigned long *left)' rather than
> 'size_t *left)' and this should apply cleanly to 'master'. Also, it
> would have _exactly_ the same effect as the current code! ;-) ).

I have now done:

  $ diff 0001-packfile-use-extra-variable-to-clarify-code-in-use_p.patch ttt.patch
  28c28
  <  		size_t *left)
  ---
  >  		unsigned long *left)
  $ 

... this and it applies cleanly to 'master', builds and passes tests.

Just FYI. ;-)

ATB,
Ramsay Jones

Re: [PATCH] packfile: use extra variable to clarify code in use_pack()

[Jeff King]

On Wed, Mar 13, 2019 at 09:49:58PM +0000, Ramsay Jones wrote:

> From: Jeff King <peff@peff.net>
> [...]
> Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>

Signed-off-by: Jeff King <peff@peff.net>

Naturally. :)

> As promised, I am forwarding a 'saved' patch from Jeff, which was
> a by-product of a long-ago discussion regarding commit 5efde212fc
> ("zlib.c: use size_t for size", 2018-10-14).
> 
> I have tested this patch on 'pu' (@6fd68134c8) and directly on top
> of commit 5efde212fc. (see branch 'mk/use-size-t-in-zlib').
> 
> However, whilst I have been waiting for the tests to finish, I have
> been looking at the code and concluded that this does not _have_ to
> be applied on top of commit 5efde212fc. (I haven't done it, but just
> tweak the context line to read 'unsigned long *left)' rather than
> 'size_t *left)' and this should apply cleanly to 'master'. Also, it
> would have _exactly_ the same effect as the current code! ;-) ).

I think it does apply, though the reasoning in the commit message of
"this is OK because 'left' is large enough" becomes a lot more
hand-wavy. The patch is not making anything _worse_, certainly, but the
fact of the matter is that "left" still might not be big enough, if it
is not a size_t.

-Peff

Re: [PATCH] packfile: use extra variable to clarify code in use_pack()

[Ramsay Jones]

On 14/03/2019 00:19, Jeff King wrote:
> On Wed, Mar 13, 2019 at 09:49:58PM +0000, Ramsay Jones wrote:
> 
>> From: Jeff King <peff@peff.net>
>> [...]
>> Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
> 
> Signed-off-by: Jeff King <peff@peff.net>
> 
> Naturally. :)
> 
>> As promised, I am forwarding a 'saved' patch from Jeff, which was
>> a by-product of a long-ago discussion regarding commit 5efde212fc
>> ("zlib.c: use size_t for size", 2018-10-14).
>>
>> I have tested this patch on 'pu' (@6fd68134c8) and directly on top
>> of commit 5efde212fc. (see branch 'mk/use-size-t-in-zlib').
>>
>> However, whilst I have been waiting for the tests to finish, I have
>> been looking at the code and concluded that this does not _have_ to
>> be applied on top of commit 5efde212fc. (I haven't done it, but just
>> tweak the context line to read 'unsigned long *left)' rather than
>> 'size_t *left)' and this should apply cleanly to 'master'. Also, it
>> would have _exactly_ the same effect as the current code! ;-) ).
> 
> I think it does apply, though the reasoning in the commit message of
> "this is OK because 'left' is large enough" becomes a lot more
> hand-wavy. The patch is not making anything _worse_, certainly, but the
> fact of the matter is that "left" still might not be big enough, if it
> is not a size_t.

Yep, the commit message would have to change (it says 'left' is
a size_t), but I think the patch is _still_ an improvement on
the existing code, even without s/unsigned long *left/size_t *left/.
(ie the code is still 'clarified'). :-D

Anyway, it was just an idle FYI while waiting. ;-)

ATB,
Ramsay Jones

Re: [PATCH] packfile: use extra variable to clarify code in use_pack()

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I think it does apply, though the reasoning in the commit message of
> "this is OK because 'left' is large enough" becomes a lot more
> hand-wavy. The patch is not making anything _worse_, certainly, but the
> fact of the matter is that "left" still might not be big enough, if it
> is not a size_t.

True; it does not make much sense without the actual size_t
conversion, I would think.