Re: [Flex-devel] Questions about functionality

[Aaron S. <aa...@se...>]

On Oct 14, 2008, at 8:45 AM, Joe Krahn wrote:

> What part of the generated code is supposed to be visible to user code
> from section 1? My understanding is that section 1 is meant for
> including extra headers, and inserting cpp #defines to modify cpp- 
> based
> options. However, it apparently does not come early enough in the
> generated code, because somebody added the %top{} feature.
>
> My first guess is just to avoid moving any code to the other side of  
> the
> current section 1 code insertion, to avoid breaking things. But, there
> should be some specific rules. In any case, the %top{} feature is  
> useful
> because it gets written to the public header.

Huh, ok. I seem to recall that stuff in the top section came very  
nearly the beginning, if not actually the beginning, of the output  
file. I wonder if there are assumptions of this in many scanners.

>
> Why does the yylineno macro point to the buffer stack bs_lineno only  
> in
> the reentrant scanner? Also, why not support yycolumn for the
> non-reentrant scanner?

I don't know the details on this.

>
> Does anybody think that M4 macros should be accessible in user code?  
> My
> version of the skeleton disables all m4 processing of user code. This
> fixes at least one bug in the bug tracker, but breaks some of the test
> scanners. To work around this, my skeleton also generates cpp macros  
> to
> replace some of the M4 macros. This allows code with M4 macros to  
> work,
> but avoids possible side-effects of m4 processing. Should these be
> enabled only for internal testing, or are some users writing scanners
> that use these? My idea is to add an option flag, but state that it is
> mainly intended for internal testing.

I believe there should be absolutely no M4 processing of user code. No  
good can come of it. If the tests are using this, we should fix them.

Aaron