help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unexpected $undefined (raw characters don't make it from the lexer)


From: Hal
Subject: Re: unexpected $undefined (raw characters don't make it from the lexer)
Date: Tue, 17 Jan 2006 13:06:15 -0800

Thanks for your quick reply -- I don't think this can be the problem,
though. The lexer is returning the integer value 123, which is the correct
ASCII code for the character '{'. I did wonder whether there was an encoding
problem before, so I used the same editor that I wrote the flex and bison
specifications with to save a text file which I used as input to the bison
parser. The character still wasn't recognised. Also, it isn't only '{' which
causes the problem (that just happens to be the first literal character in
the language I'm parsing). Any literal character returned is reported as
"$undefined" and causes the same error.

Out of interest, which character is not ASCII?

Thanks!

Hal
--

On 1/17/06, Tommy Nordgren <address@hidden> wrote:
>
> I have checked your pattern in a large font. The pattern is question
> contains a non-ascii character
> You might have typed it instead of an X.
>
> On Jan 17, 2006, at 7:02 PM, Hal wrote:
>
> > Hi
> >
> > I'm using a C++ bison parser with a C++ flex lexer (thanks to Akim for
> > showing me that lex-param doesn't work until 2.1!)
> >
> > In my lexer, I have a single rule that returns character codes:
> >    [-=*/+!<>$~)(\]\[}{`]    return yytext[0];
> > as well as plenty of rules that return tokens defined in the header
> > generated by the bison grammar (-d option).
> >
> > The compiled parser runs fine as long as only the #defined tokens are
> > returned by the lexer; as soon as the lexer produces a single
> > character via
> > the above rule, the parser fails with the following message:
> >    1.0: syntax error, unexpected $undefined, expecting {
> > The "undefined" character in this case was indeed '{', and I've added
> > debugging output to the lexer to make sure that it really is
> > producing the
> > appropriate character code (123 in this case).
> >
> > Why would the parser be failing to understand the meaning of the
> > lexer's
> > return value when it is a character code, but managing fine when it
> > is a
> > predefined token?
> >
> > Thanks for your help!
> >
> > Hal
> > --
> > _______________________________________________
> > address@hidden http://lists.gnu.org/mailman/listinfo/help-bison
>
> -------------------------------------
> This sig is dedicated to the advancement of Nuclear Power
> Tommy Nordgren
> address@hidden
>
>
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]