Re: [Flex-devel] Questions about functionality

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

On Oct 21, 2008, at 9:23 AM, Joe Krahn wrote:

> Aaron Stone wrote:
>> 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.
> The problem is that location of section 1 code is ill-defined. It  
> was created mainly to include headers, prototypes and macros needed  
> in the actions. Those declarations should all include their own  
> prerequisite headers. For that reason, section 1 could be inserted  
> at the very top, which would avoid the need for %top{}. In fact,  
> that makes the most sense to me, because Flex documentation never  
> claims to make anything available to section 1 code, and is also how  
> Flex's internal scanner source is written. But, that would surely  
> break a lot of scanners, which are usually built by trial-and-error.
>
> Other people may have different opinions that certain CPP  
> definitions should be available, even if undocumented, based on  
> experience with Flex. Even if the current plan is to just avoid  
> changes that can break scanners, we should come up with a more  
> precise definition of where section 1 code is inserted. My thinking  
> is that section 1 code should really not depend on anything from  
> Flex, except perhaps the version macros and standard I/O headers.

The right thing to do is clearly define where the section 1 code goes  
in the output and revolve around that.

I am in favor of section 1 being in the absolute top of the scanner.  
If the user wants to put scanner-definition-dependent code in section  
1, they can generate a matching header file and include it, then add  
their own stuff. If we set up the include guards correctly, an early- 
inclusion / double-inclusion of the generated header will have no ill  
effect.

Aaron