[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] YYLTYPE, yy[gs]et_lloc, -P
From: |
John Millaway |
Subject: |
Re: [PATCH] YYLTYPE, yy[gs]et_lloc, -P |
Date: |
Wed, 3 Jul 2002 09:17:38 -0700 (PDT) |
--- "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