YACC(1P) POSIX Programmer's Manual YACC(1P)PROLOG
This manual page is part of the POSIX Programmer's Manual. The Linux
implementation of this interface may differ (consult the corresponding
Linux manual page for details of Linux behavior), or the interface may
not be implemented on Linux.
NAMEyacc - yet another compiler compiler (DEVELOPMENT)
SYNOPSISyacc [-dltv][-b file_prefix][-p sym_prefix] grammar
DESCRIPTION
The yacc utility shall read a description of a context-free grammar in
grammar and write C source code, conforming to the ISO C standard, to a
code file, and optionally header information into a header file, in the
current directory. The C code shall define a function and related rou‐
tines and macros for an automaton that executes a parsing algorithm
meeting the requirements in Algorithms .
The form and meaning of the grammar are described in the EXTENDED
DESCRIPTION section.
The C source code and header file shall be produced in a form suitable
as input for the C compiler (see c99 ).
OPTIONS
The yacc utility shall conform to the Base Definitions volume of
IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.
The following options shall be supported:
-b file_prefix
Use file_prefix instead of y as the prefix for all output file‐
names. The code file y.tab.c, the header file y.tab.h (created
when -d is specified), and the description file y.output (cre‐
ated when -v is specified), shall be changed to file_prefix
.tab.c, file_prefix .tab.h, and file_prefix .output, respec‐
tively.
-d Write the header file; by default only the code file is written.
The #define statements associate the token codes assigned by
yacc with the user-declared token names. This allows source
files other than y.tab.c to access the token codes.
-l Produce a code file that does not contain any #line constructs.
If this option is not present, it is unspecified whether the
code file or header file contains #line directives. This should
only be used after the grammar and the associated actions are
fully debugged.
-p sym_prefix
Use sym_prefix instead of yy as the prefix for all external
names produced by yacc. The names affected shall include the
functions yyparse(), yylex(), and yyerror(), and the variables
yylval, yychar, and yydebug. (In the remainder of this section,
the six symbols cited are referenced using their default names
only as a notational convenience.) Local names may also be
affected by the -p option; however, the -p option shall not
affect #define symbols generated by yacc.
-t Modify conditional compilation directives to permit compilation
of debugging code in the code file. Runtime debugging statements
shall always be contained in the code file, but by default con‐
ditional compilation directives prevent their compilation.
-v Write a file containing a description of the parser and a report
of conflicts generated by ambiguities in the grammar.
OPERANDS
The following operand is required:
grammar
A pathname of a file containing instructions, hereafter called
grammar, for which a parser is to be created. The format for the
grammar is described in the EXTENDED DESCRIPTION section.
STDIN
Not used.
INPUT FILES
The file grammar shall be a text file formatted as specified in the
EXTENDED DESCRIPTION section.
ENVIRONMENT VARIABLES
The following environment variables shall affect the execution of yacc:
LANG Provide a default value for the internationalization variables
that are unset or null. (See the Base Definitions volume of
IEEE Std 1003.1-2001, Section 8.2, Internationalization Vari‐
ables for the precedence of internationalization variables used
to determine the values of locale categories.)
LC_ALL If set to a non-empty string value, override the values of all
the other internationalization variables.
LC_CTYPE
Determine the locale for the interpretation of sequences of
bytes of text data as characters (for example, single-byte as
opposed to multi-byte characters in arguments and input files).
LC_MESSAGES
Determine the locale that should be used to affect the format
and contents of diagnostic messages written to standard error.
NLSPATH
Determine the location of message catalogs for the processing of
LC_MESSAGES .
The LANG and LC_* variables affect the execution of the yacc utility as
stated. The main() function defined in Yacc Library shall call:
setlocale(LC_ALL, "")
and thus the program generated by yacc shall also be affected by the
contents of these variables at runtime.
ASYNCHRONOUS EVENTS
Default.
STDOUT
Not used.
STDERR
If shift/reduce or reduce/reduce conflicts are detected in grammar,
yacc shall write a report of those conflicts to the standard error in
an unspecified format.
Standard error shall also be used for diagnostic messages.
OUTPUT FILES
The code file, the header file, and the description file shall be text
files. All are described in the following sections.
Code File
This file shall contain the C source code for the yyparse() function.
It shall contain code for the various semantic actions with macro sub‐
stitution performed on them as described in the EXTENDED DESCRIPTION
section. It also shall contain a copy of the #define statements in the
header file. If a %union declaration is used, the declaration for
YYSTYPE shall also be included in this file.
Header File
The header file shall contain #define statements that associate the
token numbers with the token names. This allows source files other than
the code file to access the token codes. If a %union declaration is
used, the declaration for YYSTYPE and an extern YYSTYPE yylval declara‐
tion shall also be included in this file.
Description File
The description file shall be a text file containing a description of
the state machine corresponding to the parser, using an unspecified
format. Limits for internal tables (see Limits ) shall also be
reported, in an implementation-defined manner. (Some implementations
may use dynamic allocation techniques and have no specific limit values
to report.)
EXTENDED DESCRIPTION
The yacc command accepts a language that is used to define a grammar
for a target language to be parsed by the tables and code generated by
yacc. The language accepted by yacc as a grammar for the target lan‐
guage is described below using the yacc input language itself.
The input grammar includes rules describing the input structure of the
target language and code to be invoked when these rules are recognized
to provide the associated semantic action. The code to be executed
shall appear as bodies of text that are intended to be C-language code.
The C-language inclusions are presumed to form a correct function when
processed by yacc into its output files. The code included in this way
shall be executed during the recognition of the target language.
Given a grammar, the yacc utility generates the files described in the
OUTPUT FILES section. The code file can be compiled and linked using
c99. If the declaration and programs sections of the grammar file did
not include definitions of main(), yylex(), and yyerror(), the compiled
output requires linking with externally supplied versions of those
functions. Default versions of main() and yyerror() are supplied in the
yacc library and can be linked in by using the -l y operand to c99.
The yacc library interfaces need not support interfaces with other than
the default yy symbol prefix. The application provides the lexical ana‐
lyzer function, yylex(); the lex utility is specifically designed to
generate such a routine.
Input Language
The application shall ensure that every specification file consists of
three sections in order: declarations, grammar rules, and programs,
separated by double percent signs ( "%%" ). The declarations and pro‐
grams sections can be empty. If the latter is empty, the preceding "%%"
mark separating it from the rules section can be omitted.
The input is free form text following the structure of the grammar
defined below.
Lexical Structure of the Grammar
The <blank>s, <newline>s, and <form-feed>s shall be ignored, except
that the application shall ensure that they do not appear in names or
multi-character reserved symbols. Comments shall be enclosed in
"/* ... */", and can appear wherever a name is valid.
Names are of arbitrary length, made up of letters, periods ( '.' ),
underscores ( '_' ), and non-initial digits. Uppercase and lowercase
letters are distinct. Conforming applications shall not use names
beginning in yy or YY since the yacc parser uses such names. Many of
the names appear in the final output of yacc, and thus they should be
chosen to conform with any additional rules created by the C compiler
to be used. In particular they appear in #define statements.
A literal shall consist of a single character enclosed in single-quotes
( '" ). All of the escape sequences supported for character constants
by the ISO C standard shall be supported by yacc.
The relationship with the lexical analyzer is discussed in detail
below.
The application shall ensure that the NUL character is not used in
grammar rules or literals.
Declarations Section
The declarations section is used to define the symbols used to define
the target language and their relationship with each other. In particu‐
lar, much of the additional information required to resolve ambiguities
in the context-free grammar for the target language is provided here.
Usually yacc assigns the relationship between the symbolic names it
generates and their underlying numeric value. The declarations section
makes it possible to control the assignment of these values.
It is also possible to keep semantic information associated with the
tokens currently on the parse stack in a user-defined C-language union,
if the members of the union are associated with the various names in
the grammar. The declarations section provides for this as well.
The first group of declarators below all take a list of names as argu‐
ments. That list can optionally be preceded by the name of a C union
member (called a tag below) appearing within '<' and '>' . (As an
exception to the typographical conventions of the rest of this volume
of IEEE Std 1003.1-2001, in this case <tag> does not represent a
metavariable, but the literal angle bracket characters surrounding a
symbol.) The use of tag specifies that the tokens named on this line
shall be of the same C type as the union member referenced by tag. This
is discussed in more detail below.
For lists used to define tokens, the first appearance of a given token
can be followed by a positive integer (as a string of decimal digits).
If this is done, the underlying value assigned to it for lexical pur‐
poses shall be taken to be that number.
The following declares name to be a token:
%token [<tag>] name [number][name [number]]...
If tag is present, the C type for all tokens on this line shall be
declared to be the type referenced by tag. If a positive integer, num‐
ber, follows a name, that value shall be assigned to the token.
The following declares name to be a token, and assigns precedence to
it:
%left [<tag>] name [number][name [number]]...
%right [<tag>] name [number][name [number]]...
One or more lines, each beginning with one of these symbols, can appear
in this section. All tokens on the same line have the same precedence
level and associativity; the lines are in order of increasing prece‐
dence or binding strength. %left denotes that the operators on that
line are left associative, and %right similarly denotes right associa‐
tive operators. If tag is present, it shall declare a C type for names
as described for %token.
The following declares name to be a token, and indicates that this can‐
not be used associatively:
%nonassoc [<tag>] name [number][name [number]]...
If the parser encounters associative use of this token it reports an
error. If tag is present, it shall declare a C type for names as
described for %token.
The following declares that union member names are non-terminals, and
thus it is required to have a tag field at its beginning:
%type <tag> name...
Because it deals with non-terminals only, assigning a token number or
using a literal is also prohibited. If this construct is present, yacc
shall perform type checking; if this construct is not present, the
parse stack shall hold only the int type.
Every name used in grammar not defined by a %token, %left, %right, or
%nonassoc declaration is assumed to represent a non-terminal symbol.
The yacc utility shall report an error for any non-terminal symbol that
does not appear on the left side of at least one grammar rule.
Once the type, precedence, or token number of a name is specified, it
shall not be changed. If the first declaration of a token does not
assign a token number, yacc shall assign a token number. Once this
assignment is made, the token number shall not be changed by explicit
assignment.
The following declarators do not follow the previous pattern.
The following declares the non-terminal name to be the start symbol,
which represents the largest, most general structure described by the
grammar rules:
%start name
By default, it is the left-hand side of the first grammar rule; this
default can be overridden with this declaration.
The following declares the yacc value stack to be a union of the vari‐
ous types of values desired:
%union { body of union (in C) }
By default, the values returned by actions (see below) and the lexical
analyzer shall be of type int. The yacc utility keeps track of types,
and it shall insert corresponding union member names in order to per‐
form strict type checking of the resulting parser.
Alternatively, given that at least one <tag> construct is used, the
union can be declared in a header file (which shall be included in the
declarations section by using a #include construct within %{ and %}),
and a typedef used to define the symbol YYSTYPE to represent this
union. The effect of %union is to provide the declaration of YYSTYPE
directly from the yacc input.
C-language declarations and definitions can appear in the declarations
section, enclosed by the following marks:
%{ ... %}
These statements shall be copied into the code file, and have global
scope within it so that they can be used in the rules and program sec‐
tions.
The application shall ensure that the declarations section is termi‐
nated by the token %%.
Grammar Rules in yacc
The rules section defines the context-free grammar to be accepted by
the function yacc generates, and associates with those rules C-language
actions and additional precedence information. The grammar is
described below, and a formal definition follows.
The rules section is comprised of one or more grammar rules. A grammar
rule has the form:
A : BODY ;
The symbol A represents a non-terminal name, and BODY represents a
sequence of zero or more names, literals, and semantic actions that can
then be followed by optional precedence rules. Only the names and lit‐
erals participate in the formation of the grammar; the semantic actions
and precedence rules are used in other ways. The colon and the semi‐
colon are yacc punctuation. If there are several successive grammar
rules with the same left-hand side, the vertical bar '|' can be used to
avoid rewriting the left-hand side; in this case the semicolon appears
only after the last rule. The BODY part can be empty (or empty of names
and literals) to indicate that the non-terminal symbol matches the
empty string.
The yacc utility assigns a unique number to each rule. Rules using the
vertical bar notation are distinct rules. The number assigned to the
rule appears in the description file.
The elements comprising a BODY are:
name, literal
These form the rules of the grammar: name is either a token or a
non-terminal; literal stands for itself (less the lexically
required quotation marks).
semantic action
With each grammar rule, the user can associate actions to be
performed each time the rule is recognized in the input process.
(Note that the word "action" can also refer to the actions of
the parser-shift, reduce, and so on.)
These actions can return values and can obtain the values returned by
previous actions. These values are kept in objects of type YYSTYPE (see
%union). The result value of the action shall be kept on the parse
stack with the left-hand side of the rule, to be accessed by other
reductions as part of their right-hand side. By using the <tag> infor‐
mation provided in the declarations section, the code generated by yacc
can be strictly type checked and contain arbitrary information. In
addition, the lexical analyzer can provide the same kinds of values for
tokens, if desired.
An action is an arbitrary C statement and as such can do input or out‐
put, call subprograms, and alter external variables. An action is one
or more C statements enclosed in curly braces '{' and '}' .
Certain pseudo-variables can be used in the action. These are macros
for access to data structures known internally to yacc.
$$
The value of the action can be set by assigning it to $$. If
type checking is enabled and the type of the value to be
assigned cannot be determined, a diagnostic message may be gen‐
erated.
$number
This refers to the value returned by the component specified by
the token number in the right side of a rule, reading from left
to right; number can be zero or negative. If number is zero or
negative, it refers to the data associated with the name on the
parser's stack preceding the leftmost symbol of the current
rule. (That is, "$0" refers to the name immediately preceding
the leftmost name in the current rule to be found on the
parser's stack and "$-1" refers to the symbol to its left.) If
number refers to an element past the current point in the rule,
or beyond the bottom of the stack, the result is undefined. If
type checking is enabled and the type of the value to be
assigned cannot be determined, a diagnostic message may be gen‐
erated.
$<tag>number
These correspond exactly to the corresponding symbols without
the tag inclusion, but allow for strict type checking (and pre‐
clude unwanted type conversions). The effect is that the macro
is expanded to use tag to select an element from the YYSTYPE
union (using dataname.tag). This is particularly useful if num‐
ber is not positive.
$<tag>$
This imposes on the reference the type of the union member ref‐
erenced by tag. This construction is applicable when a reference
to a left context value occurs in the grammar, and provides yacc
with a means for selecting a type.
Actions can occur anywhere in a rule (not just at the end); an action
can access values returned by actions to its left, and in turn the
value it returns can be accessed by actions to its right. An action
appearing in the middle of a rule shall be equivalent to replacing the
action with a new non-terminal symbol and adding an empty rule with
that non-terminal symbol on the left-hand side. The semantic action
associated with the new rule shall be equivalent to the original
action. The use of actions within rules might introduce conflicts that
would not otherwise exist.
By default, the value of a rule shall be the value of the first element
in it. If the first element does not have a type (particularly in the
case of a literal) and type checking is turned on by %type, an error
message shall result.
precedence
The keyword %prec can be used to change the precedence level
associated with a particular grammar rule. Examples of this are
in cases where a unary and binary operator have the same sym‐
bolic representation, but need to be given different prece‐
dences, or where the handling of an ambiguous if-else construc‐
tion is necessary. The reserved symbol %prec can appear immedi‐
ately after the body of the grammar rule and can be followed by
a token name or a literal. It shall cause the precedence of the
grammar rule to become that of the following token name or lit‐
eral. The action for the rule as a whole can follow %prec.
If a program section follows, the application shall ensure that the
grammar rules are terminated by %%.
Programs Section
The programs section can include the definition of the lexical analyzer
yylex(), and any other functions; for example, those used in the
actions specified in the grammar rules. It is unspecified whether the
programs section precedes or follows the semantic actions in the output
file; therefore, if the application contains any macro definitions and
declarations intended to apply to the code in the semantic actions, it
shall place them within "%{ ... %}" in the declarations section.
Input Grammar
The following input to yacc yields a parser for the input to yacc. This
formal syntax takes precedence over the preceding text syntax descrip‐
tion.
The lexical structure is defined less precisely; Lexical Structure of
the Grammar defines most terms. The correspondence between the previous
terms and the tokens below is as follows.
IDENTIFIER
This corresponds to the concept of name, given previously. It
also includes literals as defined previously.
C_IDENTIFIER
This is a name, and additionally it is known to be followed by a
colon. A literal cannot yield this token.
NUMBER A string of digits (a non-negative decimal integer).
TYPE, LEFT, MARK, LCURL, RCURL
These correspond directly to %type, %left, %%, %{, and %}.
{ ... }
This indicates C-language source code, with the possible inclu‐
sion of '$' macros as discussed previously.
/* Grammar for the input to yacc. */
/* Basic entries. */
/* The following are recognized by the lexical analyzer. */
%token IDENTIFIER /* Includes identifiers and literals */
%token C_IDENTIFIER /* identifier (but not literal)
followed by a :. */
%token NUMBER /* [0-9][0-9]* */
/* Reserved words : %type=>TYPE %left=>LEFT, and so on */
%token LEFT RIGHT NONASSOC TOKEN PREC TYPE START UNION
%token MARK /* The %% mark. */
%token LCURL /* The %{ mark. */
%token RCURL /* The %} mark. */
/* 8-bit character literals stand for themselves; */
/* tokens have to be defined for multi-byte characters. */
%start spec
%%
spec : defs MARK rules tail
;
tail : MARK
{
/* In this action, set up the rest of the file. */
}
| /* Empty; the second MARK is optional. */
;
defs : /* Empty. */
| defs def
;
def : START IDENTIFIER
| UNION
{
/* Copy union definition to output. */
}
| LCURL
{
/* Copy C code to output file. */
}
RCURL
| rword tag nlist
;
rword : TOKEN
| LEFT
| RIGHT
| NONASSOC
| TYPE
;
tag : /* Empty: union tag ID optional. */
| '<' IDENTIFIER '>'
;
nlist : nmno
| nlist nmno
;
nmno : IDENTIFIER /* Note: literal invalid with % type. */
| IDENTIFIER NUMBER /* Note: invalid with % type. */
;
/* Rule section */
rules : C_IDENTIFIER rbody prec
| rules rule
;
rule : C_IDENTIFIER rbody prec
| '|' rbody prec
;
rbody : /* empty */
| rbody IDENTIFIER
| rbody act
;
act : '{'
{
/* Copy action, translate $$, and so on. */
}
'}'
;
prec : /* Empty */
| PREC IDENTIFIER
| PREC IDENTIFIER act
| prec ';'
;
Conflicts
The parser produced for an input grammar may contain states in which
conflicts occur. The conflicts occur because the grammar is not
LALR(1). An ambiguous grammar always contains at least one LALR(1) con‐
flict. The yacc utility shall resolve all conflicts, using either
default rules or user-specified precedence rules.
Conflicts are either shift/reduce conflicts or reduce/reduce conflicts.
A shift/reduce conflict is where, for a given state and lookahead sym‐
bol, both a shift action and a reduce action are possible. A
reduce/reduce conflict is where, for a given state and lookahead sym‐
bol, reductions by two different rules are possible.
The rules below describe how to specify what actions to take when a
conflict occurs. Not all shift/reduce conflicts can be successfully
resolved this way because the conflict may be due to something other
than ambiguity, so incautious use of these facilities can cause the
language accepted by the parser to be much different from that which
was intended. The description file shall contain sufficient information
to understand the cause of the conflict. Where ambiguity is the reason
either the default or explicit rules should be adequate to produce a
working parser.
The declared precedences and associativities (see Declarations Section
) are used to resolve parsing conflicts as follows:
1. A precedence and associativity is associated with each grammar
rule; it is the precedence and associativity of the last token or
literal in the body of the rule. If the %prec keyword is used, it
overrides this default. Some grammar rules might not have both
precedence and associativity.
2. If there is a shift/reduce conflict, and both the grammar rule and
the input symbol have precedence and associativity associated with
them, then the conflict is resolved in favor of the action (shift
or reduce) associated with the higher precedence. If the prece‐
dences are the same, then the associativity is used; left associa‐
tive implies reduce, right associative implies shift, and non-asso‐
ciative implies an error in the string being parsed.
3. When there is a shift/reduce conflict that cannot be resolved by
rule 2, the shift is done. Conflicts resolved this way are counted
in the diagnostic output described in Error Handling .
4. When there is a reduce/reduce conflict, a reduction is done by the
grammar rule that occurs earlier in the input sequence. Conflicts
resolved this way are counted in the diagnostic output described in
Error Handling .
Conflicts resolved by precedence or associativity shall not be counted
in the shift/reduce and reduce/reduce conflicts reported by yacc on
either standard error or in the description file.
Error Handling
The token error shall be reserved for error handling. The name error
can be used in grammar rules. It indicates places where the parser can
recover from a syntax error. The default value of error shall be 256.
Its value can be changed using a %token declaration. The lexical ana‐
lyzer should not return the value of error.
The parser shall detect a syntax error when it is in a state where the
action associated with the lookahead symbol is error. A semantic action
can cause the parser to initiate error handling by executing the macro
YYERROR. When YYERROR is executed, the semantic action passes control
back to the parser. YYERROR cannot be used outside of semantic actions.
When the parser detects a syntax error, it normally calls yyerror()
with the character string "syntax error" as its argument. The call
shall not be made if the parser is still recovering from a previous
error when the error is detected. The parser is considered to be recov‐
ering from a previous error until the parser has shifted over at least
three normal input symbols since the last error was detected or a
semantic action has executed the macro yyerrok. The parser shall not
call yyerror() when YYERROR is executed.
The macro function YYRECOVERING shall return 1 if a syntax error has
been detected and the parser has not yet fully recovered from it. Oth‐
erwise, zero shall be returned.
When a syntax error is detected by the parser, the parser shall check
if a previous syntax error has been detected. If a previous error was
detected, and if no normal input symbols have been shifted since the
preceding error was detected, the parser checks if the lookahead symbol
is an endmarker (see Interface to the Lexical Analyzer ). If it is, the
parser shall return with a non-zero value. Otherwise, the lookahead
symbol shall be discarded and normal parsing shall resume.
When YYERROR is executed or when the parser detects a syntax error and
no previous error has been detected, or at least one normal input sym‐
bol has been shifted since the previous error was detected, the parser
shall pop back one state at a time until the parse stack is empty or
the current state allows a shift over error. If the parser empties the
parse stack, it shall return with a non-zero value. Otherwise, it shall
shift over error and then resume normal parsing. If the parser reads a
lookahead symbol before the error was detected, that symbol shall still
be the lookahead symbol when parsing is resumed.
The macro yyerrok in a semantic action shall cause the parser to act as
if it has fully recovered from any previous errors. The macro yyclearin
shall cause the parser to discard the current lookahead token. If the
current lookahead token has not yet been read, yyclearin shall have no
effect.
The macro YYACCEPT shall cause the parser to return with the value
zero. The macro YYABORT shall cause the parser to return with a non-
zero value.
Interface to the Lexical Analyzer
The yylex() function is an integer-valued function that returns a token
number representing the kind of token read. If there is a value associ‐
ated with the token returned by yylex() (see the discussion of tag
above), it shall be assigned to the external variable yylval.
If the parser and yylex() do not agree on these token numbers, reliable
communication between them cannot occur. For (single-byte character)
literals, the token is simply the numeric value of the character in the
current character set. The numbers for other tokens can either be cho‐
sen by yacc, or chosen by the user. In either case, the #define con‐
struct of C is used to allow yylex() to return these numbers symboli‐
cally. The #define statements are put into the code file, and the
header file if that file is requested. The set of characters permitted
by yacc in an identifier is larger than that permitted by C. Token
names found to contain such characters shall not be included in the
#define declarations.
If the token numbers are chosen by yacc, the tokens other than literals
shall be assigned numbers greater than 256, although no order is
implied. A token can be explicitly assigned a number by following its
first appearance in the declarations section with a number. Names and
literals not defined this way retain their default definition. All
token numbers assigned by yacc shall be unique and distinct from the
token numbers used for literals and user-assigned tokens. If duplicate
token numbers cause conflicts in parser generation, yacc shall report
an error; otherwise, it is unspecified whether the token assignment is
accepted or an error is reported.
The end of the input is marked by a special token called the endmarker,
which has a token number that is zero or negative. (These values are
invalid for any other token.) All lexical analyzers shall return zero
or negative as a token number upon reaching the end of their input. If
the tokens up to, but excluding, the endmarker form a structure that
matches the start symbol, the parser shall accept the input. If the
endmarker is seen in any other context, it shall be considered an
error.
Completing the Program
In addition to yyparse() and yylex(), the functions yyerror() and
main() are required to make a complete program. The application can
supply main() and yyerror(), or those routines can be obtained from the
yacc library.
Yacc Library
The following functions shall appear only in the yacc library accessi‐
ble through the -l y operand to c99; they can therefore be redefined by
a conforming application:
int main(void)
This function shall call yyparse() and exit with an unspecified
value. Other actions within this function are unspecified.
int yyerror(const char *s)
This function shall write the NUL-terminated argument to stan‐
dard error, followed by a <newline>.
The order of the -l y and -l l operands given to c99 is significant;
the application shall either provide its own main() function or ensure
that -l y precedes -l l.
Debugging the Parser
The parser generated by yacc shall have diagnostic facilities in it
that can be optionally enabled at either compile time or at runtime (if
enabled at compile time). The compilation of the runtime debugging code
is under the control of YYDEBUG, a preprocessor symbol. If YYDEBUG has
a non-zero value, the debugging code shall be included. If its value is
zero, the code shall not be included.
In parsers where the debugging code has been included, the external int
yydebug can be used to turn debugging on (with a non-zero value) and
off (zero value) at runtime. The initial value of yydebug shall be
zero.
When -t is specified, the code file shall be built such that, if YYDE‐
BUG is not already defined at compilation time (using the c99 -D YYDE‐
BUG option, for example), YYDEBUG shall be set explicitly to 1. When -t
is not specified, the code file shall be built such that, if YYDEBUG is
not already defined, it shall be set explicitly to zero.
The format of the debugging output is unspecified but includes at least
enough information to determine the shift and reduce actions, and the
input symbols. It also provides information about error recovery.
Algorithms
The parser constructed by yacc implements an LALR(1) parsing algorithm
as documented in the literature. It is unspecified whether the parser
is table-driven or direct-coded.
A parser generated by yacc shall never request an input symbol from
yylex() while in a state where the only actions other than the error
action are reductions by a single rule.
The literature of parsing theory defines these concepts.
Limits
The yacc utility may have several internal tables. The minimum maximums
for these tables are shown in the following table. The exact meaning of
these values is implementation-defined. The implementation shall
define the relationship between these values and between them and any
error messages that the implementation may generate should it run out
of space for any internal structure. An implementation may combine
groups of these resources into a single pool as long as the total
available to the user does not fall below the sum of the sizes speci‐
fied by this section.
Table: Internal Limits in yacc
Minimum
Limit Maximum Description
{NTERMS} 126 Number of tokens.
{NNONTERM} 200 Number of non-terminals.
{NPROD} 300 Number of rules.
{NSTATES} 600 Number of states.
{MEMSIZE} 5200 Length of rules. The total length, in
names (tokens and non-terminals), of all
the rules of the grammar. The left-hand
side is counted for each rule, even if
it is not explicitly repeated, as speci‐
fied in Grammar Rules in yacc .
{ACTSIZE} 4000 Number of actions. "Actions" here (and
in the description file) refer to parser
actions (shift, reduce, and so on) not
to semantic actions defined in Grammar
Rules in yacc .
EXIT STATUS
The following exit values shall be returned:
0 Successful completion.
>0 An error occurred.
CONSEQUENCES OF ERRORS
If any errors are encountered, the run is aborted and yacc exits with a
non-zero status. Partial code files and header files may be produced.
The summary information in the description file shall always be pro‐
duced if the -v flag is present.
The following sections are informative.
APPLICATION USAGE
Historical implementations experience name conflicts on the names
yacc.tmp, yacc.acts, yacc.debug, y.tab.c, y.tab.h, and y.output if more
than one copy of yacc is running in a single directory at one time. The
-b option was added to overcome this problem. The related problem of
allowing multiple yacc parsers to be placed in the same file was
addressed by adding a -p option to override the previously hard-coded
yy variable prefix.
The description of the -p option specifies the minimal set of function
and variable names that cause conflict when multiple parsers are linked
together. YYSTYPE does not need to be changed. Instead, the programmer
can use -b to give the header files for different parsers different
names, and then the file with the yylex() for a given parser can
include the header for that parser. Names such as yyclearerr do not
need to be changed because they are used only in the actions; they do
not have linkage. It is possible that an implementation has other
names, either internal ones for implementing things such as yyclearerr,
or providing non-standard features that it wants to change with -p.
Unary operators that are the same token as a binary operator in general
need their precedence adjusted. This is handled by the %prec advisory
symbol associated with the particular grammar rule defining that unary
operator. (See Grammar Rules in yacc .) Applications are not required
to use this operator for unary operators, but the grammars that do not
require it are rare.
EXAMPLES
Access to the yacc library is obtained with library search operands to
c99. To use the yacc library main():
c99 y.tab.c -l y
Both the lex library and the yacc library contain main(). To access
the yaccmain():
c99 y.tab.c lex.yy.c -l y -l l
This ensures that the yacc library is searched first, so that its
main() is used.
The historical yacc libraries have contained two simple functions that
are normally coded by the application programmer. These functions are
similar to the following code:
#include <locale.h>
int main(void)
{
extern int yyparse();
setlocale(LC_ALL, "");
/* If the following parser is one created by lex, the
application must be careful to ensure that LC_CTYPE
and LC_COLLATE are set to the POSIX locale. */
(void) yyparse();
return (0);
}
#include <stdio.h>
int yyerror(const char *msg)
{
(void) fprintf(stderr, "%s\n", msg);
return (0);
}
RATIONALE
The references in may be helpful in constructing the parser generator.
The referenced DeRemer and Pennello article (along with the works it
references) describes a technique to generate parsers that conform to
this volume of IEEE Std 1003.1-2001. Work in this area continues to be
done, so implementors should consult current literature before doing
any new implementations. The original Knuth article is the theoretical
basis for this kind of parser, but the tables it generates are imprac‐
tically large for reasonable grammars and should not be used. The
"equivalent to" wording is intentional to assure that the best tables
that are LALR(1) can be generated.
There has been confusion between the class of grammars, the algorithms
needed to generate parsers, and the algorithms needed to parse the lan‐
guages. They are all reasonably orthogonal. In particular, a parser
generator that accepts the full range of LR(1) grammars need not gener‐
ate a table any more complex than one that accepts SLR(1) (a relatively
weak class of LR grammars) for a grammar that happens to be SLR(1).
Such an implementation need not recognize the case, either; table com‐
pression can yield the SLR(1) table (or one even smaller than that)
without recognizing that the grammar is SLR(1). The speed of an LR(1)
parser for any class is dependent more upon the table representation
and compression (or the code generation if a direct parser is gener‐
ated) than upon the class of grammar that the table generator handles.
The speed of the parser generator is somewhat dependent upon the class
of grammar it handles. However, the original Knuth article algorithms
for constructing LR parsers were judged by its author to be impracti‐
cally slow at that time. Although full LR is more complex than LALR(1),
as computer speeds and algorithms improve, the difference (in terms of
acceptable wall-clock execution time) is becoming less significant.
Potential authors are cautioned that the referenced DeRemer and Pen‐
nello article previously cited identifies a bug (an over-simplification
of the computation of LALR(1) lookahead sets) in some of the LALR(1)
algorithm statements that preceded it to publication. They should take
the time to seek out that paper, as well as current relevant work, par‐
ticularly Aho's.
The -b option was added to provide a portable method for permitting
yacc to work on multiple separate parsers in the same directory. If a
directory contains more than one yacc grammar, and both grammars are
constructed at the same time (by, for example, a parallel make pro‐
gram), conflict results. While the solution is not historical prac‐
tice, it corrects a known deficiency in historical implementations.
Corresponding changes were made to all sections that referenced the
filenames y.tab.c (now "the code file"), y.tab.h (now "the header
file"), and y.output (now "the description file").
The grammar for yacc input is based on System V documentation. The
textual description shows there that the ';' is required at the end of
the rule. The grammar and the implementation do not require this. (The
use of C_IDENTIFIER causes a reduce to occur in the right place.)
Also, in that implementation, the constructs such as %token can be ter‐
minated by a semicolon, but this is not permitted by the grammar. The
keywords such as %token can also appear in uppercase, which is again
not discussed. In most places where '%' is used, '\' can be substi‐
tuted, and there are alternate spellings for some of the symbols (for
example, %LEFT can be "%<" or even "\<" ).
Historically, <tag> can contain any characters except '>', including
white space, in the implementation. However, since the tag must refer‐
ence an ISO C standard union member, in practice conforming implementa‐
tions need to support only the set of characters for ISO C standard
identifiers in this context.
Some historical implementations are known to accept actions that are
terminated by a period. Historical implementations often allow '$' in
names. A conforming implementation does not need to support either of
these behaviors.
Deciding when to use %prec illustrates the difficulty in specifying the
behavior of yacc. There may be situations in which the grammar is not,
strictly speaking, in error, and yet yacc cannot interpret it unambigu‐
ously. The resolution of ambiguities in the grammar can in many
instances be resolved by providing additional information, such as
using %type or %union declarations. It is often easier and it usually
yields a smaller parser to take this alternative when it is appropri‐
ate.
The size and execution time of a program produced without the runtime
debugging code is usually smaller and slightly faster in historical
implementations.
Statistics messages from several historical implementations include the
following types of information:
n/512 terminals, n/300 non-terminals
n/600 grammar rules, n/1500 states
n shift/reduce, n reduce/reduce conflicts reported
n/350 working sets used
Memory: states, etc. n/15000, parser n/15000
n/600 distinct lookahead sets
n extra closures
n shift entries, n exceptions
n goto entries
n entries saved by goto default
Optimizer space used: input n/15000, output n/15000
n table entries, n zero
Maximum spread: n, Maximum offset: n
The report of internal tables in the description file is left implemen‐
tation-defined because all aspects of these limits are also implementa‐
tion-defined. Some implementations may use dynamic allocation tech‐
niques and have no specific limit values to report.
The format of the y.output file is not given because specification of
the format was not seen to enhance applications portability. The list‐
ing is primarily intended to help human users understand and debug the
parser; use of y.output by a conforming application script would be
unusual. Furthermore, implementations have not produced consistent out‐
put and no popular format was apparent. The format selected by the
implementation should be human-readable, in addition to the requirement
that it be a text file.
Standard error reports are not specifically described because they are
seldom of use to conforming applications and there was no reason to
restrict implementations.
Some implementations recognize "={" as equivalent to '{' because it
appears in historical documentation. This construction was recognized
and documented as obsolete as long ago as 1978, in the referenced Yacc:
Yet Another Compiler-Compiler. This volume of IEEE Std 1003.1-2001
chose to leave it as obsolete and omit it.
Multi-byte characters should be recognized by the lexical analyzer and
returned as tokens. They should not be returned as multi-byte character
literals. The token error that is used for error recovery is normally
assigned the value 256 in the historical implementation. Thus, the
token value 256, which is used in many multi-byte character sets, is
not available for use as the value of a user-defined token.
FUTURE DIRECTIONS
None.
SEE ALSO
c99, lex
COPYRIGHT
Portions of this text are reprinted and reproduced in electronic form
from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
-- Portable Operating System Interface (POSIX), The Open Group Base
Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
Electrical and Electronics Engineers, Inc and The Open Group. In the
event of any discrepancy between this version and the original IEEE and
The Open Group Standard, the original IEEE and The Open Group Standard
is the referee document. The original Standard can be obtained online
at http://www.opengroup.org/unix/online.html .
IEEE/The Open Group 2003 YACC(1P)
