+++ /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