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 &copy; 1993-2002 Parsifal Software<BR>
Copyright &copy; 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 &lt;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>