The macro YY_USER_ACTION can be defined to provide an
action which is always executed prior to the matched
rule's action. For example, it could be #define'd to call
a routine to convert yytext to lower-case. When
YY_USER_ACTION is invoked, the variable yy_act gives the
number of the matched rule (rules are numbered starting
with 1). Suppose you want to profile how often each of
your rules is matched. The following would do the trick:
#define YY_USER_ACTION ++ctr[yy_act]
where ctr is an array to hold the counts for the different
rules. Note that the macro YY_NUM_RULES gives the total number
of rules (including the default rule, even if you use `-s', so
a correct declaration for ctr is:
int ctr[YY_NUM_RULES];
The macro YY_USER_INIT may be defined to provide an action
which is always executed before the first scan (and before
the scanner's internal initializations are done). For
example, it could be used to call a routine to read in a
data table or open a logging file.
The macro `yy_set_interactive(is_interactive)' can be used to control whether the current buffer is considered interactive. An interactive buffer is processed more slowly, but must be used when the scanner's input source is indeed interactive to avoid problems due to waiting to fill buffers (see the discussion of the `-I' flag below). A non-zero value in the macro invocation marks the buffer as interactive, a zero value as non-interactive. Note that use of this macro overrides `%option always-interactive' or `%option never-interactive' (see Options below). `yy_set_interactive()' must be invoked prior to beginning to scan the buffer that is (or is not) to be considered interactive.
The macro `yy_set_bol(at_bol)' can be used to control whether the current buffer's scanning context for the next token match is done as though at the beginning of a line. A non-zero macro argument makes rules anchored with
The macro `YY_AT_BOL()' returns true if the next token scanned from the current buffer will have '^' rules active, false otherwise.
In the generated scanner, the actions are all gathered in
one large switch statement and separated using YY_BREAK,
which may be redefined. By default, it is simply a
"break", to separate each rule's action from the following
rule's. Redefining YY_BREAK allows, for example, C++
users to #define YY_BREAK to do nothing (while being very
careful that every rule ends with a "break" or a
"return"!) to avoid suffering from unreachable statement
warnings where because a rule's action ends with "return",
the YY_BREAK is inaccessible.