From 69f76e54041864bed143a65e9fb55a073159bd92 Mon Sep 17 00:00:00 2001
From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com>
Date: Mon, 27 Mar 2023 06:26:30 -0700
Subject: [PATCH] Add general note on warnings in bugs.md

In general the compiler warnings should be ignored. Only if the entry
does not work and even then only sometimes should they be fixed.
Sometimes fixing them will introduce bugs and/or crashes. Sometimes a
fix which works correctly (see my fixes to 1986/holloway and
1998/schnitzi for two examples) will introduce new warnings which MUST
NOT be fixed. Thus a general section warning against fixing warnings
lest they cause other bugs which might or might not cause other warnings
to fix (if even possible) to make it work without warnings is something
that should be there. I also noted how although some entries in the list
do have warnings noted we will not try and keep them up to date as
different compilers and almost certainly platforms (e.g. data type
sizes) generate different warnings. Sometimes this does mean that an
entry will only work on certain platforms and some might or might not be
fixable but most likely they cannot be fixed easily and even if they can
be it almost certainly will be just as non-portable (importable ? :-) ).

I did update the list of warnings in one of the entries I fixed however.
---
 bugs.md | 40 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/bugs.md b/bugs.md
index 8ad5e9b96..2ed3ea1eb 100644
--- a/bugs.md
+++ b/bugs.md
@@ -51,6 +51,22 @@ needs `stdio.h` you could do `-include stdio.h`. Please leave a space after the
 `=` in the Makefile!
 
 
+### Compiler warnings are very rarely a problem
+
+In general warnings should NOT be addressed. The only time they should be
+CONSIDERED is when the entry does not work. However note that sometimes trying
+to fix the warnings will actually introduce bugs! Below in some entries we do
+list some warnings that definitely should be ignored (including some introduced
+by fixes) but we do not list them all: trying to keep track of them all would be
+impractical especially as different compilers give different warnings. Another
+type of warning that would be hard to keep track of is different data sizes on
+different platforms. These tend to be required at the risk that sometimes the
+entry will not work for certain platforms, some of which might or might not be
+fixable. But even if they are fixable (which will likely be hard to do) it's
+almost certain that such code would be just as non-portable (importable ? :-) ).
+
+
+
 ## STATUS: INABIAF - please **DO NOT** fix
 ### INABIAF: It's not a bug it's a feature :-)
 
@@ -191,7 +207,29 @@ the correct output. Thus:
               *
 ```
 
-is NOT a problem and should not be changed.
+is NOT a problem and should NOT be changed. Neither are:
+
+```c
+holloway.c:14:1: warning: return type defaults to 'int' [-Wreturn-type]
+   14 | main(m1,s) char **s; {
+      | ^~~~
+holloway.c: In function 'main':
+holloway.c:14:1: warning: type of 'm1' defaults to 'int' [-Wmissing-parameter-type]
+holloway.c:15:15: warning: initialization of 'char *' from incompatible pointer type 'char **' [-Wincompatible-pointer-types]
+   15 |     char *t = s;
+      |               ^
+holloway.c:23:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
+   23 |             for(a=f;a<j;++a)if(tab1[a]&&!(tab1[a]%((long)l(n))))return(a);
+      |                      ^
+holloway.c:24:9: note: here
+   24 |         case g:
+      |         ^~~~
+holloway.c:34:1: warning: control reaches end of non-void function [-Wreturn-type]
+   34 | }
+      | ^
+
+```
+