Related articles |
---|
COCO/R bug fix CSPT@giraffe.ru.ac.za (Pat Terry) (1993-04-30) |
Newsgroups: | comp.compilers |
From: | Pat Terry <CSPT@giraffe.ru.ac.za> |
Keywords: | tools, LL(1) |
Organization: | Compilers Central |
Date: | Fri, 30 Apr 1993 20:37:26 GMT |
John Gough has reported a bug in Coco/R (the LL(1) parser generator that
originated from Hanspeter Mossenbock in Zurich). It exists in my MS-DOS
port (version 1.27), which I know several readers of this group have used,
and I suspect exists in the Oberon version too. A simple input that will
set it off is the following
COMPILER E
PRODUCTIONS
E = % | % .
END E.
The problem occurs when there are unrecognisable symbols (like %) in the
alternatives for a production. It does not always cause trouble; when it
does, the system loops infinitely.
The fix is as follows:
In CRP.MOD the code for PROCEDURE Term currently allows one to leave the
procedure without assigning proper values to the parameters gL and gR if
an unrecognisable terminal is encountered. A simple extra line sorts that
out
PROCEDURE Term (VAR gL, gR: INTEGER);
VAR
gL2, gR2: INTEGER;
BEGIN
gL := 0; gR := 0; (* <= =============== add line here *)
IF In(symSet[2], sym) THEN (* This is the DOS version; Oberon
one is slightly different here *)
Factor(gL, gR);
The simplest fix is to alter CR.ATG. If you do this as below you can
generate a new CRP.MOD file by a bootstrap process:
CR.ATG : we need to get the extra line generated ======
so the attribute grammar needs fixing |
|
Term<VAR gL, gR: INTEGER> (.VAR |
gL2, gR2: INTEGER;.) |
= (.gL := 0; gR := 0.) <----- add here
( Factor <gL, gR>
{ Factor <gL2, gR2> (.CRT.ConcatSeq(gL, gR, gL2, gR2).)
}
| (.gL := CRT.NewNode(CRT.eps, 0, 0); gR := gL.)
).
Pat Terry, Computer Science, Rhodes University, GRAHAMSTOWN 6140, RSA
cspt@alpha.ru.ac.za or cspt@giraffe.ru.ac.za or pdterry@psg.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.