yacc sorrows

[Martin Weitzel]

In article <22529 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>(Incidentally, this is another thing that does not really belong in
>comp.lang.c, but in this case there *is* no appropriate group, so I
>have not attempted to redirect followups....)

Do we need comp.lang.yacc?

>
>A few minor points:
>
>In article <1990Feb9.171557.18465 at tcsc3b2.tcsc.com> prs at tcsc3b2.tcsc.com
>(Paul Stath) writes:
>>The string that gets matched in LEX is stored in a character pointer called
>>`yytext'.
>
>Actually, this is an array (of size YYLMAX, typically 200) of characters,
>not a pointer.
>
>[example lex code]
>>${alpha}{alphanum}*	{
>>				yylval.str=malloc(strlen(yytext)+1);
>>				strcpy(yylval.str, yytext);
>>				return (Identifier);
>>			}
>
>
>It is not actually necessary to call malloc() here, as the characters
>in yytext[] will be left undisturbed until the next call to yylex().

Though I have no strong motivation to argue against Chris, because he
gives allways good and correct advice, I have to warn here, that yylex()
*may* be called to read one token ahead, so that the Parser can decide
wether to shift or reduce. This may not be of importance in the example
Chris had in mind, but consider the following:

%token ID
%%
list	: id1 ';'
	| id2 ',' list
	;
id1	: ID	{ /*1*/ }
	;
id2	: ID	{ /*2*/ }
	;
%%

Before /*1*/ or /*2*/ can be executed, yylex() will have been called
to see if the next token is ',' or ';', because otherwise it could
not decide if 'id1' or 'id2' should be reduced.

Even if you can deduce that this will not be the case in a certain
grammar, it introduces a possible bug for someone who later builds
uppon your work, modifies the grammar and introduces the need for
look-ahead ...

[rest deleted]
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83