[Crash-utility] [PATCH] Fix parse_line when expression is followed by a character that is not token-terminating

[Dave Wysochanski]

Commit e082c372c7f1a782b058ec359dfbbbee0f0b6aad reworked parse_line to
make a single expression encompassed by a set of parenthesis into a
single argument.  In the process it changed parse_line to improperly
handle lines like the following:
p (struct task_struct *)0xffff881813c40aa0

It could still properly handle lines with a space after the expression:
p (struct task_struct *) 0xffff881813c40aa0

The reason it failed with the former is that once exiting the expression
loop when seeing the terminating ')' and expression == 0, it would then
start the next token at the next character after the terminating ')' but
there was no place for a terminating NULL char.  As a result, the call
to parse_line would return 3 instead of two, and an error would result:
crash> p (struct task_struct *)0xffff881813c40aa0
A syntax error in expression, near `0xffff881813c40aa0'.
p: gdb request failed: p (struct task_struct *)0xffff881813c40aa0 0xffff881813c40aa0

The fix is fairly straightforward.  Just 'continue' the loop once we
exit the expression code.  That way we retain the same behavior as before
when an address follows directly an expression without a space.

Signed-off-by: Dave Wysochanski <dwysocha at redhat.com>
---
 tools.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools.c b/tools.c
index eceea90..2d95c3a 100644
--- a/tools.c
+++ b/tools.c
@@ -246,8 +246,10 @@ next:
 					break;
 				}
 			}
-			if (expression == 0)
+			if (expression == 0) {
 				i++;
+				continue;
+			}
 		    }
 
 	            if (str[i] != NULLCHAR && str[i] != '\n') {
-- 
1.7.1