[1/2] Whitespace terminates keywords in the linespec parser.

  This patch changes the linespec lexer so that any keyword seen
in the input stream is only a keyword if the next character is
whitespace (as opposed to a non-identifier character).

As a result, the lexer and find_condition_and_thread will both
share the same keyword-terminal behavior.

gdb/ChangeLog

	* linespec.c (linespec_lexer_lex_keyword): According to
	find_condition_and_thread, keywords must be followed by
	whitespace.  Follow that requirement here.
---
 gdb/linespec.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
  

Hi Keith,

> This patch changes the linespec lexer so that any keyword seen
> in the input stream is only a keyword if the next character is
> whitespace (as opposed to a non-identifier character).
> 
> As a result, the lexer and find_condition_and_thread will both
> share the same keyword-terminal behavior.
> 
> gdb/ChangeLog
> 
> 	* linespec.c (linespec_lexer_lex_keyword): According to
> 	find_condition_and_thread, keywords must be followed by
> 	whitespace.  Follow that requirement here.

I think you know this code better than anyone, but what about
testing for the nul character as well? I'm guessing that, many times,
a keyword at the end of the linespec is going to result in an invalid
linespec, but it's still a keyword?

> ---
>  gdb/linespec.c |    5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/gdb/linespec.c b/gdb/linespec.c
> index 9ec4a5e..597df87 100644
> --- a/gdb/linespec.c
> +++ b/gdb/linespec.c
> @@ -433,10 +433,9 @@ linespec_lexer_lex_keyword (const char *p)
>  	  int len = strlen (linespec_keywords[i]);
>  
>  	  /* If P begins with one of the keywords and the next
> -	     character is not a valid identifier character,
> -	     we have found a keyword.  */
> +	     character is whitespace, we have found a keyword.  */
>  	  if (strncmp (p, linespec_keywords[i], len) == 0
> -	      && !(isalnum (p[len]) || p[len] == '_'))
> +	      && isspace (p[len]))
>  	    return linespec_keywords[i];
>  	}
>      }
  

On 03/19/2015 05:18 AM, Joel Brobecker wrote:

> I think you know this code better than anyone, but what about
> testing for the nul character as well? I'm guessing that, many times,
> a keyword at the end of the linespec is going to result in an invalid
> linespec, but it's still a keyword?

Right, but without getting too much further into this, I've elaborated 
this patch a whole lot to get better behavior.

So consider this more simplistic patch (and the test in #2) withdrawn. 
I've uncovered (and fixed) a bunch of keyword-related bugs/deficiencies.

Please see my follow-on patch, "Expand keyword lexing intelligence in 
the linespec parser."

Thank you for your review!

Keith