Re: getting a copy of all characters flex has processed

Rainer Gerhards <[email protected]>
Newsgroups gmane.comp.parsers.bison.general
Message-ID <CADk+mPDaYbjNxjuLqxEOEWeHfuPg=dJU4LqnK9P9cj3ty65juQ@mail.gmail.com>
Thanks for the answers! I was obviously thinking to complicated ;-) I
have now added a function to the start of processing for each and
every token. That function conditionally (depending on command line
option settings) outputs a version of everything including "include
files" to the specified file. Does the trick rather nicely, albeit at
the price of adding ~80 function calls. But that's in a very
infrequently changing area, so it doesn't really matter.

I'll probably try out YY_USER_ACTION now that the immediate need is
solved. Sounds like a more elegant solution.

Thanks again for the quick help!

Rainer

El vie., 26 abr. 2019 a las 20:22, Jannick (<[email protected]>) escribió:
>
> On Fri, 26 Apr 2019 11:26:49 +0200, Rainer Gerhards wrote:
>
> > I would like to generate that output file during regular configuration
> > processing. So in short I need a capability to see each character that
> flex
> > processes at exactly the time it processes the character. I did not find a
> > documented override to do this.
> >
> > Is there any way to handle this with flex?
>
> Add 'ECHO;' to the flex rule whose token (yytext) you want to write to
> stdout.  You might want to check the first example in
> https://westes.github.io/flex/manual/Multiple-Input-Buffers.html#Multiple-In
> put-Buffers which could be pretty close to what you currently have, but
> using flex only, not bison.
>
> Alternatively, 'gcc -E' could be a starting point which ships the nested
> include feature if the keyword 'include' was replaced by '#include'.  This
> requires the end user to have 'gcc' available, but that should not be an
> issue when dealing with 'config.h' I guess.
>
> Best,
> J.
>

_______________________________________________
[email protected] https://lists.gnu.org/mailman/listinfo/help-bison
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.