I'll write this to the grep list, since it arose from a valgrind alert
against one of grep's regression tests, but it's mainly to say that
this is *not* a problem with grep/regexec/memmove.
On F17/x86_64, I ran these commands:
s=$(printf '\304\215y\304\215')
On 03/15/2012 05:04 AM, Jim Meyering wrote:
I.e., can valgrind be taught that when a
memmove call appears to read a few bytes beyond end of the source buffer,
that it is ok, as long the overrun is consistent with the alignment of
the source pointer?
Sure, just fix valgrind; this should be
Paul Eggert wrote:
On 03/15/2012 05:04 AM, Jim Meyering wrote:
I.e., can valgrind be taught that when a
memmove call appears to read a few bytes beyond end of the source buffer,
that it is ok, as long the overrun is consistent with the alignment of
the source pointer?
Sure, just fix
Follow-up Comment #5, patch #4354 (project grep):
I'm surprised that this need hasn't been satisfied for over 7 years since the
initial patch.
For your information, bug #17623 also deals with the same thing.
___
Reply to this item at:
Update of patch #4354 (project grep):
Status:None = Done
Open/Closed:Open = Closed
___
Follow-up Comment #6:
As it happens I
Update of bug #30868 (project grep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #3:
I fixed this, I think,
Update of bug #17623 (project grep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #7:
I installed a patch for
