blob: 352428ed0caacb32422be2b51c6e7128779e128e (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
|
=======================================================
Known Problems In PCCTS - Last revised 14 November 1998
=======================================================
#14. Parsing bug in dlg
THM: I have been unable to reproduce this problem.
Reported by Rick Howard Mijenix Corporation (rickh@mijenix.com).
The regular expression parser (in rexpr.c) fails while
trying to parse the following regular expression:
{[a-zA-Z]:}(\\\\[a-zA-Z0-9]*)+
See my comment in the following excerpt from rexpr.c:
/*
* <regExpr> ::= <andExpr> ( '|' {<andExpr>} )*
*
* Return -1 if syntax error
* Return 0 if none found
* Return 1 if a regExrp was found
*/
static
regExpr(g)
GraphPtr g;
{
Graph g1, g2;
if ( andExpr(&g1) == -1 )
{
return -1;
}
while ( token == '|' )
{
int a;
next();
a = andExpr(&g2);
if ( a == -1 ) return -1; /* syntax error below */
else if ( !a ) return 1; /* empty alternative */
g1 = BuildNFA_AorB(g1, g2);
}
if ( token!='\0' ) return -1;
*****
***** It appears to fail here becuause token is 125 - the closing '}'
***** If I change it to:
***** if ( token!='\0' && token!='}' && token!= ')' ) return -1;
*****
***** It succeeds, but I'm not sure this is the corrrect approach.
*****
*g = g1;
return 1;
}
#13. dlg reports an invalid range for: [\0x00-\0xff]
Diagnosed by Piotr Eljasiak (eljasiak@no-spam.zt.gdansk.tpsa.pl):
Fixed in MR16.
#12. Strings containing comment actions
Sequences that looked like C style comments appearing in string
literals are improperly parsed by antlr/dlg.
<< fprintf(out," /* obsolete */ ");
For this case use:
<< fprintf(out," \/\* obsolete \*\/ ");
Reported by K.J. Cummings (cummings@peritus.com).
#11. User hook for deallocation of variables on guess fail
The mechanism outlined in Item #108 works only for
heap allocated variables.
#10. Label re-initialization in ( X {y:Y} )*
If a label assignment is optional and appears in a
(...)* or (...)+ block it will not be reset to NULL
when it is skipped by a subsequent iteration.
Consider the example:
( X { y:Y })* Z
with input:
X Y X Z
The first time through the block Y will be matched and
y will be set to point to the token. On the second
iteration of the (...)* block there is no match for Y.
But y will not be reset to NULL, as the user might
expect, it will contain a reference to the Y that was
matched in the first iteration.
The work-around is to manually reset y:
( X << y = NULL; >> { y:Y } )* Z
or
( X ( y:Y | << y = NULL; >> /* epsilon */ ) )* Z
Reported by Jeff Vincent (JVincent@novell.com).
#9. PCCTAST.h PCCTSAST::setType() is a noop
#8. #tokdefs with ~Token and .
THM: I have been unable to reproduce this problem.
When antlr uses #tokdefs to define tokens the fields of
#errclass and #tokclass do not get properly defined.
When it subsequently attempts to take the complement of
the set of tokens (using ~Token or .) it can refer to
tokens which don't have names, generating a fatal error.
#7. DLG crashes on some invalid inputs
THM: In MR20 have fixed the most common cases.
The following token defintion will cause DLG to crash.
#token "()"
Reported by Mengue Olivier (dolmen@bigfoot.com).
#6. On MS systems \n\r is treated as two new lines
Fixed.
#5. Token expressions in #tokclass
#errclass does not support TOK1..TOK2 or ~TOK syntax.
#tokclass does not support ~TOKEN syntax
A workaround for #errclass TOK1..TOK2 is to use a
#tokclass.
Reported by Dave Watola (dwatola@amtsun.jpl.nasa.gov)
#4. A #tokdef must appear "early" in the grammar file.
The "early" section of the grammar file is the only
place where the following directives may appear:
#header
#first
#tokdefs
#parser
Any other kind of statement signifiies the end of the
"early" section.
#3. Use of PURIFY macro for C++ mode
Item #93 of the CHANGES_FROM_1.33 describes the use of
the PURIFY macro to zero arguments to be passed by
upward inheritance.
#define PURIFY(r, s) memset((char *) &(r), '\0', (s));
This may not be the right thing to do for C++ objects that
have constructors. Reported by Bonny Rais (bonny@werple.net.au).
For those cases one should #define PURIFY to be an empty macro
in the #header or #first actions.
#2. Fixed in 1.33MR10 - See CHANGES_FROM_1.33 Item #80.
#1. The quality of support for systems with 8.3 file names leaves
much to be desired. Since the kit is distributed using the
long file names and the make file uses long file names it requires
some effort to generate. This will probably not be changed due
to the large number of systems already written using the long
file names.
|
