From: Philip Oakley Date: Tue, 04 Feb 2014 22:45:11 GMT Subject: Re: [PATCH] blame.c: prepare_lines should not call xrealloc for every line Message-ID: <303363DDF4184D37A3D5A52147EE728B@PhilipOakley> In-Reply-To: <79CA69ED4EBA4271A40DE714AEEA5424@PhilipOakley> From: "Philip Oakley" > From: "David Kastrup" > To: "Junio C Hamano" > Cc: > 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 > --