X-Git-Url: https://git.proxmox.com/?p=mirror_edk2.git;a=blobdiff_plain;f=Tools%2FSource%2FTianoTools%2FPccts%2FKNOWN_PROBLEMS.txt;fp=Tools%2FSource%2FTianoTools%2FPccts%2FKNOWN_PROBLEMS.txt;h=0000000000000000000000000000000000000000;hp=5a9b22e1bd5fb3fd21bc10e9ace42cef2e6e798e;hb=feccee87a78e68d575dbdf44b34ca0cb5a21ea8d;hpb=214b0d1914b48d651b25e58f321ddb77a46903b8 diff --git a/Tools/Source/TianoTools/Pccts/KNOWN_PROBLEMS.txt b/Tools/Source/TianoTools/Pccts/KNOWN_PROBLEMS.txt deleted file mode 100644 index 5a9b22e1bd..0000000000 --- a/Tools/Source/TianoTools/Pccts/KNOWN_PROBLEMS.txt +++ /dev/null @@ -1,241 +0,0 @@ - - ======================================================= - Known Problems In PCCTS - Last revised 14 November 1998 - ======================================================= - -#17. The dlg fix for handling characters up to 255 is incorrect. - - See item #207. - - Reported by Frank Hartmann. - -#16. A note about "&&" predicates (Mike Dimmick) - - Mike Dimmick has pointed out a potential pitfall in the use of the - "&&" style predicate. Consider: - - r0: (g)? => <

>? r1 - | ... - ; - r1: A | B; - - If the context guard g is not a subset of the lookahead context for r1 - (in other words g is neither A nor B) then the code may execute r1 - even when the lookahead context is not satisfied. This is an error - by the person coding the grammer, and the error should be reported to - the user, but it isn't. expect. Some examples I've run seem to - indicate that such an error actually results in the rule becoming - unreachable. - - When g is properly coded the code is correct, the problem is when g - is not properly coded. - - A second problem reported by Mike Dimmick is that the test for a - failed validation predicate is equivalent to a test on the predicate - along. In other words, if the "&&" has not been hoisted then it may - falsely report a validation error. - -#15. (Changed in MR23) Warning for LT(i), LATEXT(i) in token match actions - - An bug (or at least an oddity) is that a reference to LT(1), LA(1), - or LATEXT(1) in an action which immediately follows a token match - in a rule refers to the token matched, not the token which is in - the lookahead buffer. Consider: - - r : abc <> D <> E; - - In this case LT(1) in action alpha will refer to the next token in - the lookahead buffer ("D"), but LT(1) in action beta will refer to - the token matched by D - the preceding token. - - A warning has been added which warns users about this when an action - following a token match contains a reference to LT(1), LA(1), or LATEXT(1). - - This behavior should be changed, but it appears in too many programs - now. Another problem, perhaps more significant, is that the obvious - fix (moving the consume() call to before the action) could change the - order in which input is requested and output appears in existing programs. - - This problem was reported, along with a fix by Benjamin Mandel - (beny@sd.co.il). However, I felt that changing the behavior was too - dangerous for existing code. - -#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: - - /* - * ::= ( '|' {} )* - * - * 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.