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