From: Nicolas Pitre <hidden> Date: 2016-08-11 20:35:56
On the Linux kernel repository, doing "git shortlog v2.6.18.." works
fine. "git shortlog v2.6.17.." works fine. "git shortlog v2.6.16.." also
works fine. But "git shortlog v2.6.15.." dies with a segmentation
fault. Trying "git log v2.6.15.. | git shortlog" also produces the same
crash while "git log v2.6.16.. | git shortlog" works fine.
The old perl version doesn't have any such issue with those test cases,
not even with the whole kernel history.
From: Johannes Schindelin <hidden> Date: 2016-08-11 19:37:31
Hi,
On Sat, 9 Dec 2006, Jeff King wrote:
On Sun, Dec 10, 2006 at 12:21:03AM +0100, Johannes Schindelin wrote:
quoted
quoted
Instead, remove at most one space between name and address.
Why? We can fix it properly: Instead of
quoted
- while (isspace(bob[-1]))
+ if (isspace(bob[-1]))
do something like
while (bob - 1 != buffer + 7 &&
isspace(bob[-1]))
It doesn't look like there are ever extra spaces to get soaked up in the
kernel or git repositories, but if there is a reason to expect
Full Name <user@domain>
then we should probably replace my fix with yours.
This is exactly the kind of assumption which led to the bug to begin with.
Ciao,
Dscho
From: Nicolas Pitre <hidden> Date: 2016-08-11 20:09:15
On Fri, 8 Dec 2006, Jeff King wrote:
The old code looked backwards from the email address to parse the name,
allowing an arbitrary number of spaces between the two. However, in the case
of no name, we looked back too far to the 'author' (or 'Author:') header.
Instead, remove at most one space between name and address.
The bug was triggered by commit febf7ea4bed from linux-2.6.
Signed-off-by: Jeff King <redacted>
From: Jeff King <hidden> Date: 2016-08-11 20:30:00
On Sun, Dec 10, 2006 at 12:21:03AM +0100, Johannes Schindelin wrote:
quoted
Instead, remove at most one space between name and address.
Why? We can fix it properly: Instead of
quoted
- while (isspace(bob[-1]))
+ if (isspace(bob[-1]))
do something like
while (bob - 1 != buffer + 7 &&
isspace(bob[-1]))
It doesn't look like there are ever extra spaces to get soaked up in the
kernel or git repositories, but if there is a reason to expect
Full Name <user@domain>
then we should probably replace my fix with yours.
From: Jeff King <hidden> Date: 2016-08-11 20:36:41
The old code looked backwards from the email address to parse the name,
allowing an arbitrary number of spaces between the two. However, in the case
of no name, we looked back too far to the 'author' (or 'Author:') header.
Instead, remove at most one space between name and address.
The bug was triggered by commit febf7ea4bed from linux-2.6.
Signed-off-by: Jeff King <redacted>
---
builtin-shortlog.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--
1.4.4.2.g3528-dirty
On Fri, Dec 08, 2006 at 10:23:14PM -0500, Nicolas Pitre wrote:
> On the Linux kernel repository, doing "git shortlog v2.6.18.." works
> fine. "git shortlog v2.6.17.." works fine. "git shortlog v2.6.16.." also
> works fine. But "git shortlog v2.6.15.." dies with a segmentation
> fault. Trying "git log v2.6.15.. | git shortlog" also produces the same
> crash while "git log v2.6.16.. | git shortlog" works fine.
>
> The old perl version doesn't have any such issue with those test cases,
> not even with the whole kernel history.
>
>
> Nicolas
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:37:11
Hi,
On Fri, 8 Dec 2006, Nicolas Pitre wrote:
On the Linux kernel repository, doing "git shortlog v2.6.18.." works
fine. "git shortlog v2.6.17.." works fine. "git shortlog v2.6.16.." also
works fine. But "git shortlog v2.6.15.." dies with a segmentation
fault. Trying "git log v2.6.15.. | git shortlog" also produces the same
crash while "git log v2.6.16.. | git shortlog" works fine.
The old perl version doesn't have any such issue with those test cases,
not even with the whole kernel history.
Yeah, sorry. I assumed that there are enough sanity checks for the author
format, but evidently that is/was not the case here.
Ciao,
Dscho