Re: [Flex-devel] Questions about functionality

[Will E. <wl...@us...>]

This does seem like the right approach. Particularly when combined with
the notion that we want to unentangle C-generated and skeleton code.

On Tuesday, 21 October 2008, 11:04 am -0700, Aaron Stone <aa...@se...> wrote:

> 
> 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
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel
> 

-- 
Will Estes (wl...@us...)
Flex Project Maintainer
http://flex.sourceforge.net/