diff --git a/faq.md b/faq.md
index 5ff6e8a16..4c4452978 100644
--- a/faq.md
+++ b/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?
diff --git a/thanks-for-fixes.md b/thanks-for-fixes.md
index 8fcbc77ee..5e35b7775 100644
--- a/thanks-for-fixes.md
+++ b/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.