--- /dev/null
+\r
+ =======================================================\r
+ Known Problems In PCCTS - Last revised 14 November 1998\r
+ =======================================================\r
+\r
+#14. Parsing bug in dlg\r
+\r
+ THM: I have been unable to reproduce this problem.\r
+\r
+ Reported by Rick Howard Mijenix Corporation (rickh@mijenix.com).\r
+\r
+ The regular expression parser (in rexpr.c) fails while\r
+ trying to parse the following regular expression:\r
+\r
+ {[a-zA-Z]:}(\\\\[a-zA-Z0-9]*)+\r
+\r
+ See my comment in the following excerpt from rexpr.c:\r
+\r
+ /*\r
+ * <regExpr> ::= <andExpr> ( '|' {<andExpr>} )*\r
+ *\r
+ * Return -1 if syntax error\r
+ * Return 0 if none found\r
+ * Return 1 if a regExrp was found\r
+ */\r
+ static\r
+ regExpr(g)\r
+ GraphPtr g;\r
+ {\r
+ Graph g1, g2;\r
+ \r
+ if ( andExpr(&g1) == -1 )\r
+ {\r
+ return -1;\r
+ }\r
+ \r
+ while ( token == '|' )\r
+ {\r
+ int a;\r
+ next();\r
+ a = andExpr(&g2);\r
+ if ( a == -1 ) return -1; /* syntax error below */\r
+ else if ( !a ) return 1; /* empty alternative */\r
+ g1 = BuildNFA_AorB(g1, g2);\r
+ }\r
+ \r
+ if ( token!='\0' ) return -1;\r
+ *****\r
+ ***** It appears to fail here becuause token is 125 - the closing '}'\r
+ ***** If I change it to:\r
+ ***** if ( token!='\0' && token!='}' && token!= ')' ) return -1;\r
+ *****\r
+ ***** It succeeds, but I'm not sure this is the corrrect approach.\r
+ *****\r
+ *g = g1;\r
+ return 1;\r
+ }\r
+\r
+#13. dlg reports an invalid range for: [\0x00-\0xff]\r
+\r
+ Diagnosed by Piotr Eljasiak (eljasiak@no-spam.zt.gdansk.tpsa.pl):\r
+\r
+ Fixed in MR16.\r
+\r
+#12. Strings containing comment actions\r
+\r
+ Sequences that looked like C style comments appearing in string\r
+ literals are improperly parsed by antlr/dlg.\r
+\r
+ << fprintf(out," /* obsolete */ ");\r
+\r
+ For this case use:\r
+\r
+ << fprintf(out," \/\* obsolete \*\/ ");\r
+\r
+ Reported by K.J. Cummings (cummings@peritus.com).\r
+\r
+#11. User hook for deallocation of variables on guess fail\r
+\r
+ The mechanism outlined in Item #108 works only for\r
+ heap allocated variables.\r
+\r
+#10. Label re-initialization in ( X {y:Y} )*\r
+\r
+ If a label assignment is optional and appears in a\r
+ (...)* or (...)+ block it will not be reset to NULL\r
+ when it is skipped by a subsequent iteration.\r
+\r
+ Consider the example:\r
+\r
+ ( X { y:Y })* Z\r
+\r
+ with input:\r
+\r
+ X Y X Z\r
+\r
+ The first time through the block Y will be matched and\r
+ y will be set to point to the token. On the second\r
+ iteration of the (...)* block there is no match for Y.\r
+ But y will not be reset to NULL, as the user might\r
+ expect, it will contain a reference to the Y that was\r
+ matched in the first iteration.\r
+\r
+ The work-around is to manually reset y:\r
+\r
+ ( X << y = NULL; >> { y:Y } )* Z\r
+\r
+ or\r
+\r
+ ( X ( y:Y | << y = NULL; >> /* epsilon */ ) )* Z\r
+\r
+ Reported by Jeff Vincent (JVincent@novell.com).\r
+\r
+#9. PCCTAST.h PCCTSAST::setType() is a noop\r
+\r
+#8. #tokdefs with ~Token and .\r
+\r
+ THM: I have been unable to reproduce this problem.\r
+\r
+ When antlr uses #tokdefs to define tokens the fields of\r
+ #errclass and #tokclass do not get properly defined.\r
+ When it subsequently attempts to take the complement of\r
+ the set of tokens (using ~Token or .) it can refer to\r
+ tokens which don't have names, generating a fatal error.\r
+\r
+#7. DLG crashes on some invalid inputs\r
+\r
+ THM: In MR20 have fixed the most common cases.\r
+\r
+ The following token defintion will cause DLG to crash.\r
+\r
+ #token "()"\r
+\r
+ Reported by Mengue Olivier (dolmen@bigfoot.com).\r
+\r
+#6. On MS systems \n\r is treated as two new lines\r
+\r
+ Fixed.\r
+\r
+#5. Token expressions in #tokclass\r
+\r
+ #errclass does not support TOK1..TOK2 or ~TOK syntax.\r
+ #tokclass does not support ~TOKEN syntax\r
+\r
+ A workaround for #errclass TOK1..TOK2 is to use a\r
+ #tokclass.\r
+\r
+ Reported by Dave Watola (dwatola@amtsun.jpl.nasa.gov)\r
+\r
+#4. A #tokdef must appear "early" in the grammar file.\r
+\r
+ The "early" section of the grammar file is the only\r
+ place where the following directives may appear:\r
+\r
+ #header\r
+ #first\r
+ #tokdefs\r
+ #parser\r
+\r
+ Any other kind of statement signifiies the end of the\r
+ "early" section.\r
+\r
+#3. Use of PURIFY macro for C++ mode\r
+\r
+ Item #93 of the CHANGES_FROM_1.33 describes the use of\r
+ the PURIFY macro to zero arguments to be passed by\r
+ upward inheritance.\r
+\r
+ #define PURIFY(r, s) memset((char *) &(r), '\0', (s));\r
+\r
+ This may not be the right thing to do for C++ objects that\r
+ have constructors. Reported by Bonny Rais (bonny@werple.net.au).\r
+\r
+ For those cases one should #define PURIFY to be an empty macro\r
+ in the #header or #first actions.\r
+\r
+#2. Fixed in 1.33MR10 - See CHANGES_FROM_1.33 Item #80.\r
+\r
+#1. The quality of support for systems with 8.3 file names leaves\r
+ much to be desired. Since the kit is distributed using the\r
+ long file names and the make file uses long file names it requires\r
+ some effort to generate. This will probably not be changed due\r
+ to the large number of systems already written using the long\r
+ file names.\r
projects / mirror_edk2.git / blobdiff