Re: RFC: maint: prepare NEWS

Hi Paul,

Thanks for the answer!

> Le 30 août 2020 à 19:19, Paul Eggert <[email protected]> a écrit :
> 
> I stopped worrying about CVEs like those long ago. They're not important and anybody who knows security knows they're not important.

I do not understand the point of submitting such CVEs.  I find disturbing that there are no authors.

> We could say something like the following, I suppose. Or maybe you'd want to tone it down a bit.
> 
> "This release of Bison fixes all known bugs reported for Bison in MITRE's Common Vulnerabilities and Exposures (CVE) system. Although these bugs are typically irrelevant to how Bison is used, they are worth fixing if only to give users peace of mind."

Tone down?  I find your wording extremely toned down already :)  I was really aiming at making clear that these entries are worthless.  A pure waste of time for everybody.

Here's a mixture of your words with mine.  WDYT?

commit a6e71b4f92f2d9d74d9212f575d9e3bd27689c84
Author: Akim Demaille <[email protected]>
Date:   Sun Aug 30 16:15:39 2020 +0200

    doc: updates
    
    * NEWS, TODO: here.

diff --git a/NEWS b/NEWS
index a5c59f0d..7f4e72c3 100644
--- a/NEWS
+++ b/NEWS
@@ -2,9 +2,29 @@ GNU Bison NEWS
 
 * Noteworthy changes in release ?.? (????-??-??) [?]
 
+  This release of Bison fixes all known bugs reported for Bison in MITRE's
+  Common Vulnerabilities and Exposures (CVE) system.
+
+  These "vulnerabilities" are only about bison-the-program itself, not the
+  generated code.  Users should not worry about them: the worst that can
+  happen is bison crashing on invalid input.  This is very much like an
+  Internal Compiler Error (ICE), and of course there is no reason to create
+  a CVE for every single ICE.
+
+  Although these bugs are typically irrelevant to how Bison is used, they
+  are worth fixing if only to give users peace of mind.
+
+  There is no known vulnerability in the generated parsers.
+
 ** Bug fixes
 
-  Push parsers use YYMALLOC/YYFREE instead of direct calls to malloc/free.
+  Push parsers always use YYMALLOC/YYFREE (no direct calls to malloc/free).
+
+  Portability issues of the test suite, and of bison itself.
+
+  Some unlikely crashes found by fuzzing have been fixed.  This is only
+  about bison itself, not the generated parsers.
+
 
 * Noteworthy changes in release 3.7.1 (2020-08-02) [stable]
 
@@ -560,7 +580,8 @@ GNU Bison NEWS
   \005) with incorrect styling.  Fixes for similar issues with unexpectedly
   short lines (e.g., the file was changed between parsing and diagnosing).
 
-  Several unlikely crashes found by fuzzing have been fixed.
+  Some unlikely crashes found by fuzzing have been fixed.  This is only
+  about bison itself, not the generated parsers.
 
 
 * Noteworthy changes in release 3.5.2 (2020-02-13) [stable]
diff --git a/TODO b/TODO
index b8b2befb..e9874678 100644
--- a/TODO
+++ b/TODO
@@ -1,4 +1,12 @@
-* Bison 3.7
+* Soon
+** gnulib
+Bruno notes:
+
+> I haven't looked deeply, but it strikes me that gnulib/lib/bitset/array.c
+> does not make use of the 'ffsl' function, nor or the 'integer_length_l'
+> function. Maybe because in Bison, all bitsets are so dense that it does
+> not give a performance advantage?
+
 ** Cex
 *** Improve gnulib
 Don't do this (counterexample.c):