*** empty log message ***

1 files changed, 15 insertions, 1 deletions

diff --git a/HACKING b/HACKING
index 04c0720ac..c4846d080 100644
--- a/HACKING
+++ b/HACKING
@@ -32,6 +32,9 @@ The Guile sources live in several modules:
   - guile-oops --- The Guile Object-Oriented Programming System (talk to mdj)
   - guile-www --- A Guile module for making HTTP requests.
 
+There is a mailing list for CVS commit messages; see README for details.
+
+
 - We check Makefile.in and configure files into CVS, as well as the
 files they are built from (Makefile.am, configure.in); we do not check
 in Makefiles or header files generated by configuration scripts.  The
@@ -73,6 +76,14 @@ compiler.  This means that people using more stringent compilers will
 have more work to do, and assures that everyone won't switch to the
 most lenient compiler they can find.  :)
 
+Note also that EGCS (as of November 3 1998) doesn't handle the
+`noreturn' attribute properly, so it doesn't understand that functions
+like scm_error won't return.  This may lead to some silly warnings
+about uninitialized variables.  You should look into these warnings to
+make sure they are indeed spurious, but you needn't correct warnings
+caused by this EGCS bug.
+
+
 - When you make a user-visible change (i.e. one that should be
 documented, and appear in NEWS, put an asterisk in column zero of the
 start of the ChangeLog entry, like so:
@@ -92,7 +103,9 @@ Scheme under the functions' Scheme names.  Please don't do this:
 	* procs.c, procs.h (procedure-documentation): Moved from eval.c.
 
 Entries like this make it harder to search the ChangeLogs, because you
-can never tell which name the entry will refer to.
+can never tell which name the entry will refer to.  Instead, write this:
+
+	* procs.c, procs.h (scm_procedure_documentation): Moved from eval.c.
 
 Changes like adding this line are special:
 
@@ -103,6 +116,7 @@ alias for scm_map that guarantees the order in which we process list
 elements, but we're not changing scm_map at all --- it's appropriate
 to use the Scheme name in the log entry.
 
+
 - There's no need to keep a change log for documentation files.  This
 is because documentation is not susceptible to bugs that are hard to
 fix.  Documentation does not consist of parts that must interact in a