diff options
Diffstat (limited to 'src/VBox/Devices/EFI/Firmware/BaseTools/Source/C/VfrCompile/Pccts/KNOWN_PROBLEMS.txt')
-rw-r--r-- | src/VBox/Devices/EFI/Firmware/BaseTools/Source/C/VfrCompile/Pccts/KNOWN_PROBLEMS.txt | 241 |
1 files changed, 241 insertions, 0 deletions
diff --git a/src/VBox/Devices/EFI/Firmware/BaseTools/Source/C/VfrCompile/Pccts/KNOWN_PROBLEMS.txt b/src/VBox/Devices/EFI/Firmware/BaseTools/Source/C/VfrCompile/Pccts/KNOWN_PROBLEMS.txt new file mode 100644 index 00000000..8c4bef7a --- /dev/null +++ b/src/VBox/Devices/EFI/Firmware/BaseTools/Source/C/VfrCompile/Pccts/KNOWN_PROBLEMS.txt @@ -0,0 +1,241 @@ + + ======================================================= + 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)? => <<P>>? 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 grammar, 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 <<action alpha>> D <<action beta>> 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: + + /* + * <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 definition 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. |