Re: RFC: maint: prepare NEWS

[Akim Demaille]

Hi Paul,

Thanks for the answer!

> Le 30 août 2020 à 19:19, Paul Eggert <eggert@cs.ucla.edu> 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 <akim.demaille@gmail.com>
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):