Re: Not getting parse error

[Rich Yonts]

Hans,

I was expecting that the invalid token (.) would cause an error since it
doesn't fit in with my grammar at all.  I don't care if there are any
reductions since I'm not doing anything with the input except validating
it.  The problem that I'm solving is to syntax check an input that is
pseudo-SQL.  The input may contain only fields (one or more) or a
conditional section followed by fields (one or more).  Eventually the
pseudo-SQL will be transformed into real SQL, but I didn't want to do this
unless the input passed a syntax check (why create bad SQL?).

Let me give you the whole grammar:

%token AND CONDITIONALOP FIELD LITERAL NOT OR

%left OR
%left AND

%%

Query :
    Conditional ',' FieldList {
          return(0);
      } |
    FieldList {
          return(0);
      }
    ;

Conditional :
    Conditional AND Conditional |
    Conditional OR Conditional |
    NOT '(' Conditional ')' {} |
    '(' Conditional ')' |
    Expression
    ;

Expression :
    FIELD CONDITIONALOP LITERAL {}
    ;

FieldList :
    FIELD ',' FieldList {} |
    FIELD {}
    ;

%%

When good input is checked:

sessiontype = 'RFC' & NOT(status = 'ERROR' | status = 'PENDING'), sessionid
, status

I get an expected success since this is acceptable according to my
expectation of the grammar.  However, when the invalid input comes in:

sessiontype = 'RFC' & NOT(status = 'ERROR' | status = 'PENDING'), sessionid
. status

I am expecting that the invalid token (.) would cause a failure in the
start symbol rule since not all the input fit the rule.  My understanding
is likely mistaken given your reply.  Is there any way that I can ensure a
failure in checking given my grammar?  Am I simply way off base in my (very
limited) understanding of Bison?

I appreciate your taking time to help,

Rich Yonts
address@hidden


To: Rich Yonts/Tucson/address@hidden
cc: address@hidden
From: Hans Aberg <address@hidden>
Subject: Re: Not getting parse error



At 14:46 -0700 2002/02/01, Rich Yonts wrote:
>  The debug output shows that it detects an invalid
>token:
>
>Reading a token: Next token is 259 (FIELD)
>Shifting token 259 (FIELD), Entering state 22
>Reducing via rule 9 (line 44), FieldList ',' FIELD
>state stack now 0
>Entering state 6
>Reading a token: Next token is 46 ($undefined.)
>Reducing via rule 2 (line 26), FieldList  -> Query
>
>The parser returns a good condition, but shouldn't.  Can you direct me to
>some help or documentation that explains why invalid input can be
>tolerated?

Are you saying that you did not get any error at all, or are you bothered
over the reduction?

If you got an error after a couple of reductions:

Bison (currently) uses LALR(1) (only): In pure LR(1) an error is detected
immediately with no further shifts or reductions. Under LALR and some types
of table compressed LR(1), some additional reductions may be applied (but
no shifts), before the error is detected. See for example Aho et. al.,
"Compilers...", sec. 4.7.

  Hans Aberg