Improve discussion of gets()/fgets() in FAQ/thanks

It is not yet clear to me if some of the information in the two files
should be swapped. I think it probably should be done as the point in
the thanks file was to be a quick note but it ended up being long and
with details better left to the FAQ. But this can be done another time
after the remaining entries are reviewed or sometime in between.

faq.md

@@ -34,9 +34,10 @@
 
 ## Section  4 - [Changes made to IOCCC winners](#faq4)
 - [4.0  - Why are some winning author remarks incongruent with the winning IOCCC code?](#faq4_0)
-- [4.1  - Why were some calls to the libc function gets changed to use fgets?](#faq4_1)
+- [4.1  - Why were some calls to the libc function `gets(3)` changed to use `fgets(3)`?](#faq4_1)
 - [4.2  - What was changed in an IOCCC winner source code?](#faq4_2)
-- [4.3  - Why do author remarks sometimes not match the source?](#faq4_3)
+- [4.3  - Why do author remarks sometimes not match the source / why are there
+other inconsistencies with the original entry?](#faq4_3)
 - [4.4  - What is the meaning of the file ending in .orig.c in IOCCC winners?](#faq4_4)
 
 ## Section  5 - [Updating or correcting IOCCC web site content](#faq5)
@@ -988,7 +989,7 @@ version like `winner.alt.c` or `prog.alt.c`. In fact it is advisable to look at
 the original code when reading the author's (and sometimes authors') remarks.
 
 
-### <a name="faq4_1"></a>FAQ 4.1: Why were some calls to the libc function gets changed to use fgets?
+### <a name="faq4_1"></a>FAQ 4.1: Why were some calls to the libc function `gets(3)` changed to use `fgets(3)`?
 
 Some may wonder: "Doesn't this tamper with the entry too much?"
 
@@ -1015,7 +1016,6 @@ those have mainly not been touched except one that has had the buffer size
 increased (which could be done for others that are not possible to change to
 `fgets()` though this has not been done).
 
-
 Some entries can be made to look almost identical to the original entry. For
 instance the fix to [1988/reddy](1988/reddy/README.md) required only a single
 `#define` be added.
@@ -1023,12 +1023,22 @@ instance the fix to [1988/reddy](1988/reddy/README.md) required only a single
 In the future we, the judges, would prefer that entries use `fgets()` to prevent
 these problems.
 
-NOTE: due to 'compatibility reasons' `fgets()` stores the newline and `gets()`
-does not. We're not sure how this is compatibility but either way it can cause a
+An annoying fact is that for '"compatibility" reasons' `fgets()` retains the
+newline and `gets()` does not.  As the v7 man page used to say:
+
+```
+BUGS
+
+The fgets(3) function retains the newline while gets(3) does not, all in the
+name of backward compatibility.
+```
+
+We're not sure how this is compatibility but either way it can cause a
 problem and it is this that has complicated most of the fixes though again some
 can look almost identical.
 
 
+
 ### <a name="faq4_2"></a>FAQ 4.2: What was changed in an IOCCC winner source code?
 
 We have set up make rules to easily do see what was changed in the IOCCC
@@ -1126,12 +1136,25 @@ Obviously if you want to view the alt code or the orig code you can just open
 the files as described above.
 
 
-### <a name="faq4_3"></a>FAQ 4.3: Why do author remarks sometimes not match the source?
+### <a name="faq4_3"></a> FAQ 4.3  - Why do author remarks sometimes not match the source / why are there other inconsistencies with the original entry?
 
-This is very likely to happen when an entry was fixed for modern systems. When
-you look at the remarks of the author you should look at the `prog.orig.c` or
-the `winner.orig.c` file. You might also find value in the above `diff` make
-rules.
+If the entry has been fixed for modern systems and this fix required
+modification to the code then invariably there will be entries where the remarks
+of the author or authors are inconsistent with the original code, the size of
+the code might be against rule 2 and other kinds of inconsistencies might also
+be there.
+
+This is why we recommend that when you read the remarks, sometimes the judges'
+remarks and always the author's or authors' remarks, we recommend that you look
+at the original code. When the entry source code is called `prog.c` the original
+code is in `prog.orig.c`; otherwise it is `winner.orig.c`. For instance one of
+Landon's all time favourite entries is
+[1984/mullender](1984/mullender/README.md) and the original code is in
+[mullender.orig.c](1984/mullender/mullender.orig.c). In some cases, such as
+`1984/mullender`, the original code is the same as the code as no changes were
+made (there is an alt version for systems that are not VAX-11/PDP-11, however).
+
+See also [FAQ 4.2: What was changed in an IOCCC winner source code?](#faq4_2)
 
 
 ### <a name="faq4_4"></a>FAQ 4.4: What is the meaning of the file ending in .orig.c in IOCCC winners?

thanks-for-fixes.md

@@ -64,10 +64,28 @@ We are pleased to note the many contributions, **made since 2021 Jan 01**,
 on a winner by winner basis.
 
 
+## Note about fixes and inconsistencies with the original code and remarks
+
+Invariably when an entry is fixed and it is not made an alt version (sometimes
+it is worth an alt version and other times not - it all depends on what was
+done) some inconsistencies will be introduced of the original code, the remarks
+of the author(s) and the size restrictions of the contest for that year (and in
+some cases it might end up being against other rules).
+
+See [FAQ 4.3  - Why do author remarks sometimes not match the source / why are
+there other inconsistencies with the original entry?](/faq.md#faq4_3) for this
+specifically and also [FAQ 4.2: What was changed in an IOCCC winner source
+code?](/faq.mdfaq4_2).
+
+
 ## Notes about changing `gets()` to `fgets()` in some entries:
 
-Although this is discussed in the [FAQ](/faq.md) we want to say here simply that
-the problem with `gets()` is that in some systems a warning can be interspersed
+Although the 'why' is discussed in the [FAQ 4.1: Why were some calls to the libc
+function `gets(3)` changed to use `fgets(3)`?](/faq.md#faq4_1) we want to give
+more details here as it pertains to the fixes and  updates made in numerous
+entries below (note that some of the information in that FAQ entry are below).
+
+The problem with `gets()` is that in some systems a warning can be interspersed
 with the output which can be confusing, to say nothing of the annoyance of it
 (which can be fixed via `2>/dev/null` - and this is done with some entries in
 the to use/try sections - but which makes it more burdensome to run as there are
@@ -76,11 +94,16 @@ a lot of entries that use it still).
 A good example was [1990/tbr](/thanks-for-fixes.md#1990tbr-readmemd) where one
 would see:
 
-```sh
+```
 $ warning: this program uses gets(), which is unsafe.
+# cursor here, what to do?
 ```
 
-whereas without the warning it's much easier to see that it's a prompt.
+whereas without the warning it's much easier to see that it's a prompt:
+
+```
+$
+```
 
 Another great example is:
 
@@ -114,8 +137,8 @@ fixes in that entry.
 In any case some of the entries have been updated this way for the reasons
 described above and in the [FAQ](/faq.md).
 
-Where possible `gets` has been redefined to be `fgets` with the appropriate arg.
-This is not always possible but if often is.
+Where possible `gets(3)` has been redefined to be `fgets(3)` with the
+appropriate arg.  This is not always possible but if often it is.
 
 See also [bugs.md](/bugs.md) for a further discussion on the matter.