Re: [PATCH] YYLTYPE, yy[gs]et_lloc, -P

[John Millaway]

--- "Ralf S. Engelschall" <address@hidden> wrote:
> [the following was already reported in November 2001 for Flex
> 2.5.6-developer-2001-11-01, but the bug is still present in Flex 2.5.8]
> 
> Just a little thing I've recognized while hacking on a scanner which is
> generated by flex-2.5.8: Although I used "flex ... -Pl2_spec_ ..." the
> generated object file still has two "yy"-prefixed symbols:
> 
> | :> nm -g l2_spec_scan.o  | grep yy
> | 00000c04 T yyget_lloc
> | 00000c10 T yyset_lloc
> 
> This is because at the top of the generated l2_spec_scan.c there is:
> 
> | #ifdef YYLTYPE
> | #define yyget_lloc l2_spec_get_lloc
> | #define yyset_lloc l2_spec_set_lloc
> | #endif
> 
> Unfortunately the YYLTYPE will _never_ be defined at this point, because
> it is defined by the parser and the parsers' include file can be included
> only in %{ ..%} sections, which in turn are inserted in the generated
> code always _after_ the above sequence.
> 
> It certainly is not correct to change the position of inserting
> the %{...%} sections, of course. But we can just leave out the
> #ifdef..#endif, because even if YYLTYPE is not used (no location
> tracking is used) or not defined, the extra namespace-preserving
> definitions of yy[gs]et_lloc will not hurt.
> 
> So, I recommend to apply the following patch to Flex 2.5.8 and hope it
> is finally considered for inclusion into forthcoming versions:
> 
> =================================================================
> --- main.c.orig       Wed Jun 19 15:26:44 2002
> +++ main.c    Wed Jul  3 10:12:43 2002
> @@ -384,10 +384,8 @@
>              outn( "#ifdef YY_REENTRANT_BISON_PURE" );
>              GEN_PREFIX( "get_lval" );
>              GEN_PREFIX( "set_lval" );
> -            outn( "#ifdef YYLTYPE" );
>              GEN_PREFIX( "get_lloc" );
>              GEN_PREFIX( "set_lloc" );
> -            outn( "#endif" );
>              outn( "#endif" );
> 
>              if ( do_yylineno && reentrant)
> =================================================================

Thanks! This is a great solution. I'll patch it and run it through the tests/.

This bug part of a larger problem. As you mentioned, flex parses (and buffers)
the entire user section 1, before writing any output. The problem is that both
the user code and the flex-generated code (i.e., triggered by %options) all go
into the same buffer. Eventually, we'd like to split the buffer, thereby
gaining some lookahead on the %options before writing any user code. The output
would be rearranged, and I haven't taken the time to find an arrangement that
is backwards compatible with existing scanners.



__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com