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

Re: Re: new version breaks some uses of unput()



Okay maybe defining the function in the rules section does solve the problem. However, this can have the effect of putting bug hunks of C code in the rules section. This would seem to be bad coding style as already suggested. It would seem that (at least one of) the uses of the "user code" section is to make it possible to avoid this.

Is undefining these items (like yytext_ptr) at the end of the rules just being fastidious or is it really necessary for the new functionality?

Manoj Srivastava wrote:
On Tue, 15 Apr 2003 12:44:49 -0400,
Joey Hess <joeyh@debian.org> said:

 > Manoj Srivastava wrote:
 >> 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.

Not quite. ----------------------------------------------------------------------
   In the rules section, any indented or %{ %} enclosed text appearing
before the first rule may be used to declare variables which are local
to the scanning routine and (after the declarations) code which is to be
executed whenever the scanning routine is entered.  Other indented or
%{ %} text in the rule section is still copied to the output, but its
meaning is not well-defined and it may well cause compile-time errors
(this feature is present for POSIX compliance. See *Note Lex and Posix::, for
other such features).

   Any _indented_ text or text enclosed in `%{' and `%}' is copied
verbatim to the output (with the %{ and %} symbols removed).  The %{
and %} symbols must appear unindented on lines by themselves.
----------------------------------------------------------------------

	I'll attach a file at the end that uses functions once
 again. Just the placement of these function definitions has changed.

 >> > 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.

   You must supply a `yywrap()' function of your own, or link to
`libfl.a' (which provides one), or use


     %option noyywrap

   in your source to say you don't want a `yywrap()' function.

	manoj


%{
/* COMMENT: code block */
%}

%option noyywrap
/* COMMENT: Definitions Section */
BW [ \t\n]
SP [ \t]+
EW [ \t.,;!\?$]
%%
  /* COMMENT: Rules Section */
%{
	/* COMMENT: Define function */
	void foo () { unput(yytext[yyleng-1]); }
%}
foo  /* COMMENT: after regex */   foo(); /* COMMENT: after code block */
             /* COMMENT: Rules Section (indented) */
%%
     /* User COMMENT: Code Section */
int
main(void) {
        yylex();
}

--



Reply to: