From: "David Kastrup" <d...@gnu.org>
To: "Junio C Hamano" <gits...@pobox.com>
Cc: <git@vger.kernel.org>
Sent: Tuesday, February 04, 2014 9:09 PM
Subject: Re: [PATCH] blame.c: prepare_lines should not call xrealloc for every line



Junio C Hamano <gits...@pobox.com> writes:

Junio C Hamano <gits...@pobox.com> writes:

David Kastrup <d...@gnu.org> writes:

Whitespace error in line 1778.  Should I be reposting?

Heh, let me try to clean it up first and then repost for your
review.

Thanks.

-- >8 --
From: David Kastrup <d...@gnu.org>

Making a single preparation run for counting the lines will avoid memory
fragmentation.  Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for sizeof(int *) < sizeof(int), admittedly unlikely.

Signed-off-by: David Kastrup <d...@gnu.org>
---

 One logic difference from what was posted is that sb->lineno[num]
 is filled with the length of the entire buffer when the file ends
 with a complete line.

Where's the difference?  This is exactly what will happen with my code
as well.  I _do_ rely on memchr(whatever, '\n', 0) to return NULL
without looking at any memory for that.  If there is a fear of memchr
not being able to deal with a count of 0, this code needs to be somewhat
more complex.

A bit of googling found http://marc.info/?l=gnulib-bug&m=130108029329021 which suggests that behaviour can't be relied upon, and that perhaps some code is 'buggy' relative to expectations (hence the patch it proposed).

It suggests that one can't properly reference a zero length object.


 I do not remember if the rest of the logic
 actually depends on it (I think I use lineno[n+1] - lineno[n] to
 find the end of line,

Well, you do it about _half_ the time. The other half, you scan for the
'\n' explicitly.

 The original code dates back to 2006 when the author of the code
 was not paid for doing anything for Git but was doing it as a
 weekend and evening hobby, so it may not be so surprising to find
 this kind of "what was I thinking when I wrote it" inefficiency in
 such a code with $0 monetary value ;-)

Oh, _this_ patch is not in the "I want to make money from it" range. If that were the case, I should not have bothered at all. This is just the "this code offends my sense of aesthetics" class. It's purely optional
to apply.  It's conceivable that it will make a performance difference
on non-glibc (or what it's called) platforms.

--
David Kastrup
--

Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to