output; unput(c) sends the character c back in the text to be read by the next input()...

Ludzie pragną czasami się rozstawać, żeby móc tęsknić, czekać i cieszyć się z powrotem.

At the end of file, input() returns 0;
• the function yywrap() is called by Flex when the end of file is reached. It always returns the value 1. It can be re-programmed to print results or
carry on processing on another file.
• the REJECT macro indicates that once the rule applied, the recognised string must be rejected if one of the following other rule also matches it.
2.6
Using the Rules
If several strings verify the rules given in the input file, Flex chooses in the following manner:
• the longuest string is considered
• if several rules apply of the same string, then it is the first rule that is applied
Thus if we write a lexical analyser, we would recognise the keywords first before recogonising the identifiers; thus to recognise Pascal programs:
...
/*all the keywords e.g. then */
then
{/* actions to be performed on then */}
...
/* other lexical entities, such as identifiers */
[a-zA-Z][a-zA-Z0-9]* {/*actions to be performed on an identifier */}
When the string then will be analysed, two rules are matching but the first will be used. If the string thenumber is to be analysed, the string then will not be recognised since of the two rules that could be applied the second takes the longuest string.
2.7
Definitions in the Specification File
The three parts of the specification file (definitions, rules, functions) are transformed by Flex into a C program. This transformation follows the following scheme:
1. all the lines of the specification file that are not rules and which starts with a space or a tab are written verbatim in the generated C program. Such
lines in the definition part generate code with the extern attribute (e.g. a declaration of variables extern to all functions corresponding to the rules).
the comments are passed without change to the generated program.
7
2. all the text including the delimiters % { and % } is written in the program where they appear and in the format they appear. This allows to include
text which must appear in the first column (e.g. #include or #define in
C).
3. the entire third part is copied verbatim after what is generated by Flex.
Macro definitions in the first part start in the first column. Their format is name body. We can place here an encode table for characters whenever we want the output characters to be different than the input ones. The minimum code value must be 1, the last code must not be greater than what is recognisable by the computer of course. The format is the following:
%T
code
characters
...
...
%T
The following table encodes the lower and upper case letters and give them code from 1 to 26:
%T
1
aA
2
bB
...
26
zZ
%T
2.8
Examples
1. the following specification file will once processed by Flex generate a lexical analyser which will take a Pascal program as input and verify the that the number of end is identical to the number of the keywords begin and case.
int nbstart, nbend = 0 ; /* note the starting space */
%%
begin|start
nbstart = nbstart + 1 ;
end
nbend = nbend + 1 ;
.|\n
/* do nothing for everything else */
%%
2. the following specification file takes as input a Pascal program and rewrites it with added comments between the name of every procedure and its
parameters composed of several stars. The parameters are written on the
next line. The procedures without parameters are never modified.
8
P
[pP][rR][oO][cC][eE][dD][uU][rR]eE]
/* macro to recognise the keyword procedure with */
/* maybe mixed upper and lower case */
%START
proc
/*declares the initial condition proc */
%%
^" "*P
ECHO; BEGIN proc /* keyword recognised at the */
/* start of a line : the condition is satisfied */
<proc>(
{printf(" {********}\n");
printf("
");
}
\n
ECHO ; BEGIN 0 /* release the initial condition */
/* proc at the end of line */
3. simpler examples are provided in the following Bison section.
3
The Parser Generator: Bison
3.1
Aim
From an input grammar, Bison construct a C function which once compiled is a parser recognising the language described by the grammar. The programmer must provide a lexical analyser constructed with Flex or programmed manually.
In the specification file of Bison we can add actions programmed in C which will be executed by the parser everytime the corresponding grammar rule is recognised. An entire compiler can be written using this scheme.
In general Bison can generate parsers to check the structure of the input file which must respect the grammar rules given to Bison.
To use Bison, therefore, one must write in a specification file, the format of the eventual input files that will be analysed, the actions to perform, a lexical analyser and the necessary declarations.
3.2
The Specification File
A specification file for Bison is composed of three parts separated by %%: declarations
/* first part */
%%
rules
/* second part */
%%
functions
/* third part */
3.2.1
The Declarations Part
The first part, which can be empty (but the %% must still be present), contains various kinds of declarations:
9
• the lexical entities received from the lexical analyser are declared by the directive %token. For example :
%token IDENT NUMBER
indicates to Bison that IDENT and NUMBER in the rules designate two lexical entities produced by the lexical analyser. These entities must of course be recognised during the lexical analsing phase. In the C program generated by Bison these identifiers are integer constants whose value characterise the entity. In the preceeding example, the value of the entities is not
specified : Bison will assign an actual value. By default Bison give values between 1 and 255 to entities composed of a single charater and values
from 257 to entities composed of several characters. If one wants a special numbering, it can be done with:
%token IDENT
300
/* 300 is the value of the constant */
%token NUMBER
301