From: "Philip Oakley" <philipoak...@iee.org>
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
[...]
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 think I've confused myself between the patch
https://lkml.org/lkml/2010/11/24/429 which fixed a bug in memchr() and
the discussion in
http://lists.gnu.org/archive/html/bug-gnulib/2011-03/msg00273.html
(alternate link to marc.info) that discusses realloc() which has
"
we changed gnulib's test-memchr to
instead test memchr(zerosize_ptr(),a,0) rather than memchr(NULL,a,0).
However, once you can handle memchr(,0) on any other zero-size object,
most implementations also happen to do what you want for
memchr(NULL,a,0), even though it is technically undefined behavior."
ending with 'technically undefined behavior' which I misconstrued.
Apologies for the noise.
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,
...
--
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
