[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: new version breaks some uses of unput()



Manoj Srivastava wrote:
> 	Joey, I am going to be presumtuous and assume you would not
>  mind this response going to a public list; I have condensed your
>  questions down to the technical details, and you did imply that you
>  considered filing a bug, so the email was not really personal and
>  private. The reason is that there were a number of questions on IRC
>  about similar topics. 

That's fine. Note that the disclaimer you cropped is that I don't claim
to know anything about lex. :-) Also that the code dates back to 1986..

>  > But before the code for the provided C functions is put in the C
>  > file, flex now includes a line that undefs yytext_ptr.
> 
> 	Yes, part of cleaning up after itself.
> 
>  > I can work around it easily enough, by either moving the functions
>  > to the top code block, or by making them explicitly call yyunput
>  > instead of the unput macro.
> 
> 	Putting it in the top code block won't work, since the yyunput
>  function is first implicitly declared, and then explicitly
>  declared static. yyunput is not an published asset; so may go away at
>  any time. In other words, there are macros and stuff available only
>  in the rules section, for use in actions.
> 
>    The `flex' input file consists of three sections, separated by a
> line containing only `%%'.
>          definitions
>          %%
>          rules
>          %%
>          user code
> 
> 	Flex sets up a number of things that are available in the
>  rules section, and now cleans it all up before polluting the user
>  namespace. Now, actions can be any C statement, but using functions
>  that in turn use flex macros is going to be a problem since declaring
>  the function is going to be problematic.
> 
> 	Some of these changes were driven by the need to make flex
>  scanners reentrant, others by hte requirements for having multiple
>  scanners, perhaps with different options, in the same program. 

It seems to promote bad coding style to require that reasonable little
functions like this:

  eos()
  {
      if (yytext[yyleng-1] == '.')
          dintI();
      else
          yyunput(yytext[yyleng-1], yytext);
  }

Must be inlined into the rules block or defined as macros or something,
instead of just being defined as regular functions. The function above is
called many times in the rules block, like this:

way                             printf("why");
[BbHh]it{EW}            {       printf("%ci'",yytext[0]); eos(); }
ait{EW}                 {       printf("ite"); eos(); }
ime{EW}                 {       printf("oime"); eos(); }

>  > Oh and why do I need an expliciy main() and yyweap() function now?
>  > This code always worked before with flex generating stub functions
>  > automatically. The real code is in the filters package, in
>  > cockney.l, jive.l, and others.
> 
> 	With multiple scanners now possible in the same program, flex
>  would not know where to put main, obviously, it shoulkd not generate
>  stubs in all the scanners generated.
> 
> 	What is yyweap? 

Typo for yywrap.

-- 
see shy jo

Attachment: pgpMQ3cgJKPhF.pgp
Description: PGP signature


Reply to: