improve IOCCC rules and guidelines

Fixed a number of typos, inconsistencies, and problems with the
rules and guidelines.

Improved how the closed version of the rules and guidelines declare
themselves at the top of the markdown and HTML file.

Changed `next/rules.md` VERSION from "2024-06-29-v28"
to "28.1 2024-06-29" in order to be more consistent
with IOCCC tool version format.

Changed `next/guidelines.md` VERSION from "2024-06-29-v28"
to "28.1 2024-06-29" in order to be more consistent
with IOCCC tool version format.

Make a minor format fix to `faq.md`.

Performed `make status` and `make www` to test the above umder macOS.

faq.html

@@ -2081,8 +2081,8 @@ very easily. To do that <code>cd 1991/dds</code> and then do:</p>
 <h4 id="tip-if-you-have-colordiff-installed-its-a-lot-easier-to-see-the-differences">Tip: if you have <code>colordiff</code> installed it’s a lot easier to see the differences</h4>
 <p>To use these rules but provide a different <code>diff</code>, for instance <code>colordiff</code>,
 just do:</p>
-<pre><code>    make DIFF=colordiff diff_orig_prog # for orig to prog diff
-    make DIFF=colordiff diff_alt_prog # for alt to prog diff</code></pre>
+<pre><code>    make DIFF=colordiff diff_orig_prog          # for orig to prog diff
+    make DIFF=colordiff diff_alt_prog           # for alt to prog diff</code></pre>
 <p>Obviously if you want to view the alternate code or the orig code you can just open
 the files as described above.</p>
 <div id="faq4_3">

faq.md

@@ -2484,8 +2484,8 @@ To use these rules but provide a different `diff`, for instance `colordiff`,
 just do:
 
 ``` <!---sh-->
-    make DIFF=colordiff diff_orig_prog # for orig to prog diff
-    make DIFF=colordiff diff_alt_prog # for alt to prog diff
+    make DIFF=colordiff diff_orig_prog          # for orig to prog diff
+    make DIFF=colordiff diff_alt_prog           # for alt to prog diff
 ```
 
 Obviously if you want to view the alternate code or the orig code you can just open

inc/guidelines.closed.hdr

@@ -5,9 +5,8 @@
 These guidelines are a **VERY TENTATIVE proposal** for the next IOCCC
 and are **VERY LIKELY** to be updated before the next IOCCC.
 They are are provided as a **VERY TENTATIVE** hint at **what
-MIGHT** be used in the next IOCCC.
-
-Please regard these guidelines as a historical archive.
+MIGHT** be used in the next IOCCC.  In some cases they might
+even be a copy of the guidelines from the previous IOCCC.
 
 
 # The IOCCC is closed

inc/rules.closed.hdr

@@ -5,9 +5,8 @@
 These rules are a **VERY TENTATIVE proposal** for the next IOCCC
 and are **VERY LIKELY** to be updated before the next IOCCC.
 They are are provided as a **very tentative** hint at **what
-MIGHT** be used in the next IOCCC.
-
-Please regard these rules as a historical archive.
+MIGHT** be used in the next IOCCC.  In some cases they might
+even be a copy of the rules from the previous IOCCC.
 
 
 # The IOCCC is closed

next/guidelines.html

@@ -382,12 +382,13 @@
 <!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
 
 <!-- BEFORE: 1st line of markdown file: next/guidelines.md -->
+<!-- START: this line starts content from: inc/guidelines.closed.hdr -->
 <h1 id="warning-these-guidelines-are-out-of-date">WARNING: These guidelines are OUT OF DATE</h1>
 <p>These guidelines are a <strong>VERY TENTATIVE proposal</strong> for the next IOCCC
 and are <strong>VERY LIKELY</strong> to be updated before the next IOCCC.
 They are are provided as a <strong>VERY TENTATIVE</strong> hint at <strong>what
-MIGHT</strong> be used in the next IOCCC.</p>
-<p>Please regard these guidelines as a historical archive.</p>
+MIGHT</strong> be used in the next IOCCC. In some cases they might
+even be a copy of the guidelines from the previous IOCCC.</p>
 <h1 id="the-ioccc-is-closed">The IOCCC is closed</h1>
 <p>The IOCCC is <strong>NOT</strong> accepting new submissions at this time. See the
 <a href="../years.html">IOCCC winning entries page</a> for the entries that have won the
@@ -404,7 +405,7 @@ granted provided this this copyright and notice are included in its entirety
 and remains unaltered. All other uses must receive prior permission in
 writing by <a href="../contact.html">contacting the judges</a>.</p>
 <h2 id="ioccc-guidelines-version">IOCCC Guidelines version</h2>
-<p><strong><code>|</code></strong> These <a href="guidelines.html">IOCCC guidelines</a> are version <strong>2024-06-25-v28</strong>.</p>
+<p><strong><code>|</code></strong> These <a href="guidelines.html">IOCCC guidelines</a> are version <strong>28.1 2024-06-29</strong>.</p>
 <p><strong>IMPORTANT</strong>: Be <strong>SURE</strong> to read the <a href="rules.html">IOCCC rules</a>.</p>
 <h3 id="change-marks">Change marks</h3>
 <p><strong><code>|</code></strong> <strong>← Lines that start with this symbol indicate a change from the previous IOCCC</strong></p>
@@ -487,7 +488,9 @@ in an ironic way.</p>
 <p>We do realize that there are holes in the rules, and invite entries
 to attempt to exploit them. We will award ‘<em>Worst abuse of the rules</em>’ or
 ‘<em>Best abuse of the rules</em>’ and then plug the hole next year.</p>
-<p><strong><code>|</code></strong> Even so, we will attempt to use the smallest plug needed, if not smaller. Or, maybe not. :-)</p>
+<p><strong><code>|</code></strong> When we do need to plug a hole in the <a href="rules.html">IOCCC rules</a>
+or <a href="guidelines.html">IOCCC guidelines</a>, we will attempt to use a very
+small plug, if not smaller. Or, maybe not. :-)</p>
 <p><strong><code>|</code></strong> There may be less than 2^7+1 reasons why these <a href="guidelines.html">IOCCC guidelines</a> seem obfuscated.</p>
 <p>Check out your program and be sure that it works. We sometimes make
 the effort to debug an submission that has a slight problem, particularly
@@ -656,7 +659,8 @@ not portable and must not be used:</p>
 <li>using <code>va_list</code> as a structure or union</li>
 </ul>
 <p>In particular, do not treat <code>va_list</code> variables as if they were a <code>char **</code>s.</p>
-<p>Avoid using <code>varargs.h</code>. Use <code>stdarg.h</code> instead.</p>
+<p><strong><code>|</code></strong> We <strong>DISLIKE</strong> the use of <code>varargs.h</code>. Use <code>stdarg.h</code> instead.</p>
+<p><strong><code>|</code></strong> We <strong>DISLIKE</strong> the use of <code>gets(3)</code>. Use <code>fgets(3)</code> instead.</p>
 <p>On 28 January 2007, the Judges rescinded the requirement that the
 <code>#</code> in a C preprocessor directive must be the 1st non-whitespace octet.</p>
 <p>The <code>exit(3)</code> function returns <code>void</code>. Some broken systems have <code>exit(3)</code>
@@ -816,7 +820,7 @@ partly misunderstand this particular <em>guideline</em>, but of course, we could
 not possibly comment! :-) Nevertheless, you are neither prohibited, nor are<br>
 you fully required to determine that this or the previous sentence is either false<br>
 and/or perhaps misleading. Therefore, it might be wise for you to not fail to<br>
-consider to do so, accordingly. Thank you very much.</p>
+consider to not do so, accordingly. Thank you very much.</p>
 </blockquote>
 <p>Any complaints about the above <em>guideline</em> could be addressed to the
 Speaker of the House of Commons, or to the speaker of your national
@@ -899,8 +903,8 @@ a PDP-11. Heck, should we ever find an emulator of 60-bit CDC Cyber
 CPU, we might just try your submission on that emulator as well :-)</p>
 <p><strong><code>|</code></strong> If your submission <strong>MUST</strong> run only on a 64-bit or 32-bit architecture,
 then you <strong>MUST</strong> specify the <code>-arch</code> on your command line
-(see <code>CARCH</code> in the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example">example Makefile</a>. Do not assume a processor word size without specifying <code>-arch</code>. For example:</p>
-<pre><code>    CARCH= -m64</code></pre>
+(see <code>ARCH</code> in the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example">example Makefile</a>. Do not assume a processor word size without specifying <code>-arch</code>. For example:</p>
+<pre><code>    ARCH= -m64</code></pre>
 <p><strong><code>|</code></strong> Try to be even more creative!</p>
 <p><strong><code>|</code></strong> If there are limitations in your submission, you are highly encouraged
 to note such limitations in your <code>remarks.md</code> file. For example if your

next/guidelines.md

@@ -1,11 +1,12 @@
+<!-- START: this line starts content from: inc/guidelines.closed.hdr -->
+
 # WARNING: These guidelines are OUT OF DATE
 
 These guidelines are a **VERY TENTATIVE proposal** for the next IOCCC
 and are **VERY LIKELY** to be updated before the next IOCCC.
 They are are provided as a **VERY TENTATIVE** hint at **what
-MIGHT** be used in the next IOCCC.
-
-Please regard these guidelines as a historical archive.
+MIGHT** be used in the next IOCCC.  In some cases they might
+even be a copy of the guidelines from the previous IOCCC.
 
 
 # The IOCCC is closed
@@ -32,7 +33,7 @@ writing by [contacting the judges](../contact.html).
 
 ## IOCCC Guidelines version
 
-**`|`**   These [IOCCC guidelines](guidelines.html) are version **2024-06-25-v28**.
+**`|`**   These [IOCCC guidelines](guidelines.html) are version **28.1 2024-06-29**.
 
 **IMPORTANT**: Be **SURE** to read the [IOCCC rules](rules.html).
 
@@ -149,7 +150,9 @@ We do realize that there are holes in the rules, and invite entries
 to attempt to exploit them.  We will award '_Worst abuse of the rules_' or
 '_Best abuse of the rules_' and then plug the hole next year.
 
-**`|`**   Even so, we will attempt to use the smallest plug needed, if not smaller.  Or, maybe not.  :-)
+**`|`**   When we do need to plug a hole in the [IOCCC rules](rules.html)
+or [IOCCC guidelines](guidelines.html), we will attempt to use a very
+small plug, if not smaller.  Or, maybe not.  :-)
 
 **`|`**   There may be less than 2^7+1 reasons why these [IOCCC guidelines](guidelines.html) seem obfuscated.
 
@@ -264,7 +267,7 @@ compiler!  We often start by compiling using the **clang** C compiler instead.
 **`|`**   You may change the standard under which your submission is compiled
 by modifying the `CSTD` Makefile variable.  For example, to use `c17` instead:
 
-```
+``` <!---make-->
     CSTD= -std=c17
 ```
 
@@ -277,7 +280,7 @@ your submission's `Makefile`.
 which your submission is compiled by modifying the `COPT` Makefile variable.
 For example, to compile without optimization:
 
-```
+``` <!---make-->
     COPT= -O0 -g3
 ```
 
@@ -289,7 +292,7 @@ warning, try not fret too much.
 **`|`**   To turn off a compiler warning, to your submission's `Makefile`,
 try something such as:
 
-```
+``` <!---make-->
     CSILENCE= -Wno-some-thing -Wno-another-thing -Wno-unknown-warning-option
 ```
 
@@ -301,14 +304,14 @@ submission.
 **`|`**   If you need to define something on the compile line, use
 the `CDEFINE` Makefile variable.  For example:
 
-```
+``` <!---make-->
     CDEFINE= -Dfoo -Dbar=baz
 ```
 
 **`|`**   If you need to include a file on the command line, use
 the `CINCLUDE` Makefile variable.  For example:
 
-```
+``` <!---make-->
     CINCLUDE= -include stdio.h
 ```
 
@@ -316,7 +319,7 @@ the `CINCLUDE` Makefile variable.  For example:
 **`|`**   If need add other "_magic_" flags to your compile line,
 use the `COTHER` Makefile variable.  For example:
 
-```
+``` <!---make-->
     COTHER= -fno-math-errno
 ```
 
@@ -354,7 +357,7 @@ When declaring local or global variables, you should declare the type:
 **`|`**   We **LIKE** code that has a minimum of warnings, especially under the
 more strict ` -Wall -Wextra -pedantic` mode:
 
-```
+``` <!---make-->
     CWARN= -Wall -Wextra -pedantic
 ```
 
@@ -408,7 +411,9 @@ not portable and must not be used:
 
 In particular, do not treat `va_list` variables as if they were a `char **`s.
 
-Avoid using `varargs.h`.  Use `stdarg.h` instead.
+**`|`**   We **DISLIKE** the use of `varargs.h`.  Use `stdarg.h` instead.
+
+**`|`**   We **DISLIKE** the use of `gets(3)`.  Use `fgets(3)` instead.
 
 On 28 January 2007, the Judges rescinded the requirement that the
 `#` in a C preprocessor directive must be the 1st non-whitespace octet.
@@ -630,7 +635,7 @@ particular window manager.
 > not possibly comment!  :-)  Nevertheless, you are neither prohibited, nor are<br>
 > you fully required to determine that this or the previous sentence is either false<br>
 > and/or perhaps misleading.  Therefore, it might be wise for you to not fail to<br>
-> consider to do so, accordingly. Thank you very much.
+> consider to not do so, accordingly. Thank you very much.
 
 Any complaints about the above _guideline_ could be addressed to the
 Speaker of the House of Commons, or to the speaker of your national
@@ -733,10 +738,10 @@ CPU, we might just try your submission on that emulator as well :-)
 
 **`|`**   If your submission **MUST** run only on a 64-bit or 32-bit architecture,
 then you **MUST** specify the `-arch` on your command line
-(see `CARCH` in the [example Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example).  Do not assume a processor word size without specifying `-arch`.  For example:
+(see `ARCH` in the [example Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example).  Do not assume a processor word size without specifying `-arch`.  For example:
 
-```
-    CARCH= -m64
+``` <!---make-->
+    ARCH= -m64
 ```
 
 **`|`**   Try to be even more creative!

next/rules.html

@@ -387,7 +387,8 @@
 <p>These rules are a <strong>VERY TENTATIVE proposal</strong> for the next IOCCC
 and are <strong>VERY LIKELY</strong> to be updated before the next IOCCC.
 They are are provided as a <strong>very tentative</strong> hint at <strong>what
-MIGHT</strong> be used in the next IOCCC.</p>
+MIGHT</strong> be used in the next IOCCC. In some cases they might
+even be a copy of the rules from the previous IOCCC.</p>
 <h1 id="the-ioccc-is-closed">The IOCCC is closed</h1>
 <p>The IOCCC is <strong>NOT</strong> accepting new submissions at this time. See the <a href="../years.html">IOCCC
 winning entries page</a> for the entries that have won the IOCCC in
@@ -406,7 +407,7 @@ writing by <a href="../contact.html">contacting the judges</a>.</p>
 <div id="rule_version">
 <h2 id="ioccc-rules-version">IOCCC Rules version</h2>
 </div>
-<p><strong><code>|</code></strong> These <a href="rules.html">IOCCC rules</a> are version <strong>2024-06-25-v28</strong>.</p>
+<p><strong><code>|</code></strong> These <a href="rules.html">IOCCC rules</a> are version <strong>28.1 2024-06-29</strong>.</p>
 <p><strong>IMPORTANT</strong>: Be sure to read the <a href="guidelines.html">IOCCC guidelines</a>.</p>
 <h3 id="change-marks">Change marks</h3>
 <p><strong><code>|</code></strong> <strong>← Lines that start with this symbol indicate a change from the previous IOCCC</strong></p>
@@ -571,11 +572,12 @@ before the close of the contest.</p>
 <div id="rule11">
 <h2 id="rule-11">Rule 11</h2>
 </div>
-<p>Programs that require special privileges (<code>setuid(2)</code>, <code>setgid(2)</code>, super-user,
-special owner, special group, etc.) are still highly discouraged. We
-do not guarantee these functions will behave as you expect on our test
-platforms. If your program needs special permissions <strong>please document
-them</strong> in the remarks file.</p>
+<p>Programs that require special privileges (<code>setuid(2)</code>, <code>setgid(2)</code>,
+super-user, special owner, special group, etc.) are still <strong>HIGHLY
+DISCOURAGED</strong>. We do not guarantee these functions will behave as
+you expect on our test platforms. If your program needs special
+permissions you <strong>MUST</strong> document this fact, and explain why
+it is needed in your submissions <code>remarks.md</code> file.</p>
 <div id="rule12">
 <h2 id="rule-12">Rule 12</h2>
 </div>
@@ -587,12 +589,12 @@ their rule abuse is legal, in the submission’s <code>remarks.md</code> file.</
 <h2 id="rule-13">Rule 13</h2>
 </div>
 <p><strong><code>|</code></strong> Any C source that fails to compile because of unescaped octets with
-the high bit set (octet value &gt;= 128) might be rejected.</p>
+the high bit set (octet value &gt;= 128) <strong><em>might</em></strong> be rejected.</p>
 <div id="rule14">
 <h2 id="rule-14">Rule 14</h2>
 </div>
 <p><strong><code>|</code></strong> Any C source that fails to compile because of lines with trailing
-control-M’s (i.e., lines with a tailing octet <code>015</code>) might be rejected.</p>
+control-M’s (i.e., lines with a tailing octet <code>015</code>) <strong><em>might</em></strong> be rejected.</p>
 <p>Please do <strong>NOT</strong> put trailing control-M’s on remarks file lines.
 Please check to be sure, before submitting, that you have removed
 any control-M at the end of remark file lines.</p>

next/rules.md

@@ -5,7 +5,8 @@
 These rules are a **VERY TENTATIVE proposal** for the next IOCCC
 and are **VERY LIKELY** to be updated before the next IOCCC.
 They are are provided as a **very tentative** hint at **what
-MIGHT** be used in the next IOCCC.
+MIGHT** be used in the next IOCCC.  In some cases they might
+even be a copy of the rules from the previous IOCCC.
 
 
 # The IOCCC is closed
@@ -34,7 +35,7 @@ writing by [contacting the judges](../contact.html).
 ## IOCCC Rules version
 </div>
 
-**`|`**   These [IOCCC rules](rules.html) are version **2024-06-25-v28**.
+**`|`**   These [IOCCC rules](rules.html) are version **28.1 2024-06-29**.
 
 **IMPORTANT**: Be sure to read the [IOCCC guidelines](guidelines.html).
 
@@ -294,11 +295,12 @@ Entries requiring human interaction to be initially compiled are not permitted.
 ## Rule 11
 </div>
 
-Programs that require special privileges (`setuid(2)`, `setgid(2)`, super-user,
-special owner, special group, etc.) are still highly discouraged. We
-do not guarantee these functions will behave as you expect on our test
-platforms. If your program needs special permissions **please document
-them** in the remarks file.
+Programs that require special privileges (`setuid(2)`, `setgid(2)`,
+super-user, special owner, special group, etc.) are still **HIGHLY
+DISCOURAGED**. We do not guarantee these functions will behave as
+you expect on our test platforms. If your program needs special
+permissions you **MUST** document this fact, and explain why
+it is needed in your submissions `remarks.md` file.
 
 
 <div id="rule12">
@@ -316,7 +318,7 @@ their rule abuse is legal, in the submission's `remarks.md` file.
 </div>
 
 **`|`**   Any C source that fails to compile because of unescaped octets with
-the high bit set (octet value >= 128) might be rejected.
+the high bit set (octet value >= 128) **_might_** be rejected.
 
 
 <div id="rule14">
@@ -324,7 +326,7 @@ the high bit set (octet value >= 128) might be rejected.
 </div>
 
 **`|`**   Any C source that fails to compile because of lines with trailing
-control-M's (i.e., lines with a tailing octet `015`) might be rejected.
+control-M's (i.e., lines with a tailing octet `015`) **_might_** be rejected.
 
 Please do **NOT** put trailing control-M's on remarks file lines.
 Please check to be sure, before submitting, that you have removed