Web pages update for CPP

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

When I apply the CPP arithmetic patch, I'll apply this too.

Neil.

	* wwwdocs/htdocs/c99status.html: Update for CPP arithmetic.
	* wwwdocs/htdocs/projects/cpplib.html: Update.

Index: htdocs/c99status.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/c99status.html,v
retrieving revision 1.31
diff -u -p -r1.31 c99status.html
--- htdocs/c99status.html	28 Feb 2002 23:08:41 -0000	1.31
+++ htdocs/c99status.html	26 May 2002 20:31:34 -0000
@@ -149,7 +149,7 @@ the much more limited support in GCC 2.9
 </tr>
 
 <tr><td><em>preprocessor arithmetic<br />done in <code>intmax_t</code>/<code>uintmax_t</code></em></td>
-    <td></td><td></td><td>Broken</td><td></td>
+    <td></td><td>Done</td><td></td><td></td>
 </tr>
 
 <tr><td><em>mixed declarations and code</em></td>
@@ -297,10 +297,7 @@ the much more limited support in GCC 2.9
 
 <ul>
 
-<li>cpp has no support for multibyte character sets.</li>
-
-<li>cpp arithmetic is done in <code>HOST_WIDEST_INT</code>, which may not
-be the same as the target <code>intmax_t</code> required by C99.</li>
+<li>cpp has limited support for multibyte character sets.</li>
 
 <li>IEC 60559 is IEEE 751 floating point.  This works if and only if
 the hardware is perfectly compliant, but GCC does not define
Index: htdocs/projects/cpplib.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cpplib.html,v
retrieving revision 1.18
diff -u -p -r1.18 cpplib.html
--- htdocs/projects/cpplib.html	13 Feb 2002 21:12:07 -0000	1.18
+++ htdocs/projects/cpplib.html	26 May 2002 20:31:37 -0000
@@ -10,8 +10,8 @@
 <p>cpplib has largely been completed, and is stable at this point.
 For GCC versions 3.0 and later, it is linked into the C, C++ and
 Objective C front ends.  Most future work will relate to character set
-issues, performance enhancements, and moving the separate preprocessor
-into the compiler front ends.  </p>
+issues, integrating the traditional preprocessor, performance
+enhancements, and improving cpplib as a stand-alone library.</p>
 
 <p>Bug reports for code which must be compiled with <code>gcc
 -traditional</code> are of interest, but much lower priority than
@@ -22,13 +22,18 @@ varargs macros in traditional mode is a 
 <h2>Work recently completed</h2>
 
 <ol>
-  <li>The unnecessary dependency of non-C front ends for some targets
-      on c_lex() has been removed.</li>
-
-  <li>The lexical analyzer has been re-worked to permit stepback.</li>
-
   <li>Updates so that cpplib works correctly on VMS have been contributed
       by Douglas Rupp.</li>
+
+  <li>Stand-alone CPP is dead.  The compiler front end now handles
+      preprocessed output if necessary.</li>
+
+  <li>As many built-in macros as possible have been moved to the front
+      ends, and out of SPECS and cpplib itself (some targets still
+      in progress).</li>
+
+  <li>CPP arithmetic is now done to the correct target precision, based
+      upon the selected language standard.</li>
 </ol>
 
 <h2>Greater Coordination with the Front Ends</h2>
@@ -80,13 +85,8 @@ after thought, which is not entirely coi
       The rest of cpplib is now reasonably efficient in its use of
       memory; minor improvements are certainly still possible.</li>
 
-  <li>The traditional preprocessor needs a complete overhaul and
-      cleanup.  The current code is simply disgusting.  It is chock
-      full of buffer overflows, very long functions, and other
-      nasties.  I would like to get cpplib handling traditional
-      preprocessing eventually, but only when the charset issues
-      have been solved, and the separate ISO preprocessor no
-      longer exists.</li>
+  <li>The traditional preprocessor needs integrating into cpplib.
+      I'm working on this at the moment.</li>
 </ol>
 
 <h2>Optimizations</h2>