.
Last update: 1997-05-20
9945-2-93
_____________________________________________________________________________
Topic: yacc
Relevant Sections: A.3.6.1.3.1
Defect Report:
-----------------------
Date: Tue, 20 Dec 1994 14:09:54 -0800
From: [email protected] (Seizo Sakurai)
A request for interpretation
A) The specific designation of the standard
WG15
ISO/IEC 9945-2:1993
B) The specific subsection being questioned
A.3.6.1.3.1 yacc Code File
Line 690-691
C) The applicable conditions for the case in questions
The applicable condition is when yacc input
file has the programs section. Please see Appendix 1
attached to this note.
D) A suggested correction, if applicable
Remove Line 690-691
E) Reson for the suggested correction
1) There are quite many yacc input files assuming that
the program section is copied before yyparse().
If the program section needs to be copied after
yyparse(), then many of already written yacc input
files need to be modified.
2) The line 936-941 says that
"It is unspecified whether the program section
precedes or follows the semantic actions in the
output file; therefore, if the application
contains any macro definitions and declarations
intended to apply the code in the semantic actions,
it shall place them within %{ ... %} in the
declaration section."
The above says that "it is unspecified whether the
program section precedes or follows the semantic actions
in the output file;". Most of yacc implementation
places its semantic actions in yyparse() and the document
also mentions it. (Line 685-686) Therefore, there should be
no problem removing line 690-691.
Appendix 1: An example
This yacc input file is a little example about the problem.
From this input, yacc will generate a parser. The parser
calls hello_world() when non-terminal sound is recognized.
The parser also calls print_str() when ding is recognized.
%{
/*
* Declaration
*/
#include <stdio.h>
char *hello_world(char *);
%}
%token DING
%token DONG
%token DELL
%%
sound: ding DONG DELL
{
hello_world("sound recognized\n");
};
ding: DING
{
print_str("ding recognized\n");
}
%%
char *
print_str(char *s)
{
printf(s);
return (s);
}
Yacc's output will have the following format. (This is y.tab.c by default.)
1) Declaration section
The beginning of y.tab.c is a copy of
the input portion surrounded by %{ and %}.
In the above example,
#include <stdio.h>
char *hello_world(char *)
are copied.
2) Then bunch of #defines and variables which will be used by yacc
generated code comes.
*3) Then user defined code will be copied.
In this above example,
char *
print_str(char *s)
{
printf(s);
return (s);
}
4) Then tables generated by yacc comes in.
5) Then finally the parser generated by yacc comes.
This is yyparse() and in the example above,
the generated parser will call print_str() and
hellow_world().
The spec says *3) part should be copied after 5).
If *3) part is copied after yyparse(), then the C compiler later
will complain that print_str() is implicitly declared as int type,
but later it is redeclared as char *.
So the spec says, that the functions that the parser uses should be
declared at the declaration section.
%{
/*
* Declaration
*/
#include <stdio.h>
char *hello_world(char *);
char *print_str(char *);
%}
Quite many existing yacc input are written like ding.y expecting that
print_str() does not need to be declared at the declaration section.
(Because user codes are copied before yyparse().)
WG15 response for 9945-2:1993
-----------------------------------
First note that in B) the relevent section is A.3.6.3.1, not A.3.6.1.3.1
The standard states behavior for the yacc code file, and conforming
implementations must conform to this. However, concerns have been raised
about this which are being referred to the sponsor.
Rationale
-------------
Forwarded to Interpretations group: 10 Jan 95
Response received: Feb 10 1995
Proposed Resoln forwarded: 13th Feb 1995
Finalised: March 28th 1995
_____________________________________________________________________________