Mercurial > ~dholland > hg > ag > index.cgi
view doc/misc/buildnotes.html @ 7:57b2cc9b87f7
Use memcpy instead of strncpy when we know the length anyway.
Modern gcc seems to think it knows how to detect misuse of strncpy,
but it's wrong (in fact: very, very wrong) and the path of least
resistance is to not try to fight with it.
author | David A. Holland |
---|---|
date | Mon, 30 May 2022 23:47:52 -0400 |
parents | 13d2b8934445 |
children |
line wrap: on
line source
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <TITLE>AnaGram Build Notes</TITLE> </HEAD> <BODY BGCOLOR="#ffffff" BACKGROUND="html/tilbl6h.gif" TEXT="#000000" LINK="#0033CC" VLINK="#CC0033" ALINK="#CC0099" > <P align=right> <IMG SRC=html/images/aga6d.gif ALT="AnaGram"><BR> A System for Syntax Directed Programming<BR> Version 2.40<BR> <BR> Copyright © 1993-2002 Parsifal Software<BR> Copyright © 2006, 2007 David A. Holland<BR> All Rights Reserved. </P> <H1>Build/Release Notes</H1> <P> Version 2.40: <UL> <LI><A HREF=#24000>AnaGram 2.40.00</A> </UL> From version 2.01: <UL> <LI><A HREF=#20108>AnaGram 2.01.08</A> <LI><A HREF=#20107>AnaGram 2.01.07</A> <LI><A HREF=#20106>AnaGram 2.01.06</A> </UL> </P> <A NAME="24000"></A> <H2>AnaGram 2.40.00 Build Notes</H2> <P> AnaGram 2.40.00 is the first release build of AnaGram 2.40, and the first open source release. See <A HREF=whatsnew.html>whatsnew.html</A> for details. </P> <!-- ------------------------------------------------------------> <HR> <A NAME="20108"></A> <H2>AnaGram 2.01.08 Build Notes</H2> AnaGram 2.01.08 is a maintenance build devoted primarily to bug fixes. <P> <H3>Warning Messages</H3> Use of a <I>void</I> token as a reduction procedure parameter is now properly diagnosed. <P> Some problems associated with identifying "circular definitions" were fixed. <P> <H3>Parsing Syntax Files</H3> There was a problem that would occasionally manifest itself as a spurious "unexpected end of file" if the last line of a syntax file contained a "//" comment. This problem has now been corrected. <P> Character set ranges defined by the form 'a'..'z' are now allowed. <P> Continuation lines in "wrapper" statements are now allowed. <P> An empty "virtual production", e.g., { }..., now causes a syntax error. <P> <H3>Syntax Analysis</H3> A problem was corrected that sometimes caused incorrect partition set analysis when the "case sensitive" switch was turned off. <P> Any token that is used in the definition of a lexeme is now treated as a lexeme when it appears in any rule that is <I>not</I> part of the definition of a lexeme. <P> When <I>disregard white space</I> and <I>distinguish lexeme</I> statements are in effect, rules that are part of the definition of white space or of the definition of a lexeme are not reduced by keywords that are <I>not</I> themselves lexemes. <P> <H3>Code Generation</H3> Parser files with an automatically generated <I>main()</I> program now have a newline character at the end of file. <P> The use of template classes with more than one parameter, e.g.,<CODE> template <class Foo, class Bar> class Foobar {...}</CODE> for token value types caused errors at compile time. When the type name was used as a parameter in a macro invocation, the comma embedded in angle brackets appeared to the macro preprocessor as an argument delimiter, thus causing it to see an incorrect number of arguments. <P> A subtle interaction between wrapper classes and immediate actions was fixed. <P> Some unnecessary <I>#include</I> statements were removed from the generated code. <P> If any token has type <I>double</I>, the parser stack alignment is now set to <I>double</I>. <P> The definition of the AgObjectWrapper template class is now protected from multiple definition by an <I>#ifndef</I> statement. <P> Incorrect keyword recognition tables were generated for grammars with 256 or more keywords. They are now generated correctly, regardless of the number of keywords. <P> An error in the keyword recognition functions has been fixed. There was a possibility of unpredictable behavior in a grammar with both keywords and input codes greater than 255 decimal. <P> <H3>Miscellaneous Problems</H3> When the command line executable, <I>agcl</I>, was invoked without an explicit path, relying on the PATH environment variable, AnaGram was unable to find its support files. This has now been corrected. <P> <!-- ------------------------------------------------------------> <HR> <A NAME="20107"></A> <H2>2.01.07 Build Notes</H2> AnaGram 2.01.07 is a maintenance build which corrects a few minor bugs, modifies warning messages introduced in Build 2.01.06, and corrects a few help messages. <P> <H3>Corrected Error Token Handling</H3> Under certain circumstances, versions of AnaGram prior to the current version could generate instructions in the error token handling code which could cause bus errors. As far as we have been able to determine, actual instances of this problem have been rare. The problem has now been corrected. <P> <H3>Placement Delete Function</H3> C++ parsers that specified the wrapper option would get warnings from some compilers complaining about the absence of a "placement delete" operator for the wrapper classes. Conditional definition of "placement delete" operator has now been provided. Please see the on-line help for AG_PLACEMENT_DELETE_REQUIRED for details. <P> <H3>Modified Warning Messages</H3> The warning messages concerning grammars with "infinite recursion" and the possibility of consequent infinite loops in the generated parser have been changed to refer to "empty recursion" which we believe to be a more appropriate description of the problem. <H3>Incorrect Warning</H3> Version 2.01.06 would issue a diagnostic for "infinite recursion" in certain cases of center recursion which were not, in fact, in error. The diagnosis is now more precise. <H3>Warning instead of Error</H3> "Empty recursion", formerly known as "infinite recursion", was handled as a grammar error in version 2.01.06, so that further analysis of a grammar with this problem was not possible. In version 2.01.07, empty recursion causes only a warning, so that analysis of the grammar may continue. Note that if you ignore the warning and actually build a parser incorporating empty recursion, the parser could go into an infinite loop during operation. <P> In the presence of empty recursion, AnaGram's Keyword Anomaly analysis and File Trace are disabled. This is because AnaGram could easily get into an infinite loop while attempting to parse sample input for a grammar incorporating empty recursion. <P> <!-- ------------------------------------------------------------> <HR> <A NAME="20106"></A> <H2>2.01.06 Build Notes</H2> AnaGram 2.01.06 is a maintenance build which corrects a few minor bugs and introduces two new error messages. <P> <H3>Corrected "Wrapper" Feature Problems</H3> Under certain circumstances, in a grammar that used wrappers to encapsulate C++ class objects on the parser value stack, AnaGram would cause the wrapper for the first token in a rule to be deleted, even though the data was still needed. This bug was introduced in AnaGram 2.01.05 and has now been corrected. <P> If wrappers were enabled and <B>error token </B> resynchronization was also enabled, AnaGram generated incorrect code for deleting wrappers. This has been corrected. <H3>New Error Messages</H3> It is possible, with null productions or other zero length tokens, to write recursive rules which translate into infinite loops in a parser. AnaGram now identifies such <B>infinitely recursive rules</B> and provides an error message for each such rule. AnaGram also terminates the analysis with an <B>infinite recursion</B> warning, since the analysis could also get into an infinite loop. <H3>Thread Execution Priority</H3> AnaGram performs its analysis and build processes in separate background threads. The thread priority previously was set too low, so that thread execution could be delayed by power saving software running at the lowest priority level. The priority of the background thread was increased. <H3>Short Reduction Procedures and the Reentrant Parser Switch</H3> Reduction procedures of the form<CODE> ={ return x;}</CODE> are now handled correctly even if both the <B>reentrant parser</B> switch and the <B>allow macros</B> switches are set. Previously there was a possibility of a compiler error when the parser module was compiled. <H3>Default Value for Null Productions</H3> The default definition of the NULL_INITIALIZER macro was changed for parsers which have a simple integer value stack in order to avoid a compiler diagnostic generated by the Sun C++ 5.0 compiler. <P> </BODY> </HTML>