bison-patches
[Top][All Lists]
Advanced

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

Re: scanner_cursor and yylloc


From: Paul Eggert
Subject: Re: scanner_cursor and yylloc
Date: 12 May 2003 11:44:27 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

[Bringing up an old conversation -- my am I behind in email!]

> From: Akim Demaille <address@hidden>
> Date: Mon, 31 Mar 2003 11:34:11 +0200

> Actually, I never quite understood why you add the missing
> terminator, I usually do this:
> 
> <STATE_STRING>{ /* Handling of the strings.  Initial " is eaten. */
>      \" {
>        BEGIN INITIAL;
>        return STRING;
>      }
> 
> // [...]
>      <<EOF>> {
>        std::cerr
>        << *yylloc << ": unexpected end of file in a string" << std::endl;
>        exit_set (exit_scan);
> 
>        BEGIN INITIAL;
>        return STRING;
>      }
> }
> 
> I don't see what rescanning brings.

In the actual parser, the shared code was more complicated than "BEGIN
INITIAL; return STRING;" and the two almost-copies got out of sync.  I
wanted to avoid code duplication, so I had the <<EOF>> case unput the
missing terminator in order to fall through to the \" case.

Unfortunately, as Peter Muir noted, unput was not portable, so in
<http://mail.gnu.org/archive/html/bison-patches/2003-04/msg00005.html>
I reverted to the method that you suggested above -- except that I
merely had the EOF case do "BEGIN INITIAL;" (without the other part of
the almost-copied code) so that the unfinished string is not reported
back to the parser.

This issue is discussed in my April 26 letter
<http://mail.gnu.org/archive/html/bison-patches/2003-04/msg00014.html>
where you suggested returning the token anyway (as above) but I
plumped for the easier-to-maintain approach of merely discarding the
unfinished string.  I don't think the change in behavior matters to
users, as we're merely talking about exactly which diagnostics are
issued for invalid Bison programs.




reply via email to

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