From 698cd8f92b620d493d1a7e21512ce828a3038262 Mon Sep 17 00:00:00 2001
From: Landon Curt Noll <github-mail@asthe.com>
Date: Sat, 29 Nov 2025 00:14:31 -0800
Subject: [PATCH] checkpoint rules & guidelines, FAQ update, draft IOCCC29
 dates

This is a draft edit of the revised IOCCC guidelines for **IOCCC29**.

Due the above, `next/guidelines.md` has undergone a significant update.
The `next/rules.md` and `faq.md` files have been modified accordingly.

The `faq.md` version is now **29.01 2025-11-28**.
The `next/guidelines.md` version is now **29.00 2025-11-28**.
The `next/rules.md` version is now *29.08 2025-11-28**.

Draft **IOCCC29** dates have been added to `rules.md`.

Ran `make quick_www` to perform the above.

TODO: Continue to revise and improve the IOCCC guidelines.

TODO: Fix typos and minor nits in the `next/guidelines.md`.

TODO: Fix typos and minor nits in the `next/rules.md`.
---
 faq.html             |  224 +++-
 faq.md               |  345 ++++-
 next/guidelines.html | 2309 +++++++++++---------------------
 next/guidelines.md   | 2997 +++++++++++++++---------------------------
 next/rules.html      |   84 +-
 next/rules.md        |  109 +-
 sitemap.xml          |   14 +-
 7 files changed, 2510 insertions(+), 3572 deletions(-)

diff --git a/faq.html b/faq.html
index f0fbdc5d2..44dff4a67 100644
--- a/faq.html
+++ b/faq.html
@@ -453,7 +453,7 @@
 
 <!-- BEFORE: 1st line of markdown file: faq.md -->
 <h1 id="ioccc-faq-table-of-contents">IOCCC FAQ Table of Contents</h1>
-<p>This is FAQ version <strong>28.2.24 2025-11-18</strong>.</p>
+<p>This is FAQ version <strong>29.01 2025-11-28</strong>.</p>
 <h2 id="entering-the-ioccc-the-bare-minimum-you-need-to-know">0. <a href="#enter_questions">Entering the IOCCC: the bare minimum you need to know</a></h2>
 <ul>
 <li><strong>Q 0.0</strong>: <a class="normal" href="#enter">How can I enter the IOCCC?</a></li>
@@ -485,6 +485,7 @@
 <li><strong>Q 1.9</strong>: <a class="normal" href="#submission_dir">How can I avoid having to move or delete my submission directory for the same workdir?</a></li>
 <li><strong>Q 1.10</strong>: <a class="normal" href="#download_submission">Can I download my submission tarball from the submit server?</a></li>
 <li><strong>Q 1.11</strong>: <a class="normal" href="#del_submission">Can I delete a submission from the submit server?</a></li>
+<li><strong>Q 1.12</strong>: <a class="normal" href="#makefile_details">What are the detailed recommendations for a submission Makefile?</a></li>
 </ul>
 <h2 id="ioccc-judging-process">2. <a href="#judging_process">IOCCC Judging process</a></h2>
 <ul>
@@ -882,6 +883,9 @@ date
 <code>Makefile.example</code>
 does have other rules like <code>everything</code> and <code>alt</code>, and we encourage you to use
 the one linked to above.</p>
+<p>See also the
+FAQ on “<a href="#makefile_details">detailed Makefile recommendations</a>”
+for more details.</p>
 <p>Jump to: <a href="#">top</a></p>
 <div id="remarks_md">
 <div id="remarks">
@@ -1113,7 +1117,7 @@ and the
 FAQ on “<a href="#fnamchk">fnamchk</a>”
 for more details.</p>
 <div id="extra-files">
-<h1 id="what-are-extra-files-and-how-may-i-include-additional-files-beyond-the-max-allowed">1.5: What are extra files and how may I include additional files beyond the max allowed?</h1>
+<h3 id="q1.5-what-are-extra-files-and-how-may-i-include-additional-files-beyond-the-max-allowed">Q1.5: What are extra files and how may I include additional files beyond the max allowed?</h3>
 </div>
 <p>Extra files are defined as files that are not the free files (the required files
 <code>prog.c</code>, <code>Makefile</code>, <code>remarks.md</code> and the optional <code>try.sh</code>, <code>try.alt.sh</code>,
@@ -1479,6 +1483,222 @@ Makefile</a> to your Makefile and add to the remarks.md:</p>
 <p>Please ignore this submission.</p>
 </blockquote>
 <p>Jump to: <a href="#">top</a></p>
+<div id="makefile_details">
+<h3 id="q-1.12-what-are-the-detailed-recommendations-for-a-submission-makefile">Q 1.12: What are the detailed recommendations for a submission Makefile?</h3>
+</div>
+<p>We <strong>recommend</strong> AND <strong>encourage</strong> you to use the example Makefile,
+as the starting point for your submission’s required <code>Makefile</code>:</p>
+<ul>
+<li><a href="https://github.com/ioccc-src/winner/blob/master/next/Makefile.example">view example Makefile</a></li>
+<li><a href="Makefile.example" download="Makefile">download example Makefile</a></li>
+</ul>
+<p>Feel free to modify the <code>Makefile</code> to suit your obfuscation needs.</p>
+<p><strong>Please</strong> add a space between the <code>=</code> and the value of variables, in the
+<code>Makefile</code>, making sure that the <code>=</code> comes immediately after the name. See the
+example <code>Makefile</code> for examples.</p>
+<p>The rest of this section and its subsections will assume that you are using some
+variant of the example <code>Makefile</code>, again renamed as <code>Makefile</code>.</p>
+<p>We suggest that you compile your submission with a commonly available
+<code>-std=gnu17</code> (ISO C 2017 with GNU extensions) C compiler, via <code>clang(1)</code>
+and/or <code>gcc(1)</code>.</p>
+<div id="cflags">
+<div id="flags">
+<h4 id="default-compiler-flags">Default compiler flags</h4>
+</div>
+</div>
+<p>Unless you <strong>clearly state</strong> otherwise in your <code>remarks.md</code> file, <strong>AND</strong> put in
+your submission’s <code>Makefile</code>, we <strong>will</strong> compile using <code>-std=gnu17 -O3</code>!</p>
+<p>It <strong>is OK</strong> if you need to require your submission to <strong>NOT be</strong> compiled
+using the default <code>-std=gnu17 -O3</code> settings. Simply <strong>explain why</strong>
+your submission should NOT be compiled using <code>-std=gnu17 -O3</code> in
+your <code>remarks.md</code> file, <strong>AND</strong> adjust your <code>Makefile</code> accordingly.</p>
+<p class="leftbar">
+You really should <strong>NOT</strong> redefine <code>CC</code> because doing so makes it less portable. &lt;– <strong>Hint!</strong>
+</p>
+<p>One reason that you might have to change the flags, is that the optimiser is
+known to break some programs, but there are certainly other possible valid
+reasons. Again, just update the <code>Makefile</code> and explain it in your <code>remarks.md</code>.
+See the <a href="#optimiser">optimiser section</a> for details for changing optimiser
+flags.</p>
+<p>For more fun when it comes to optimisers breaking code, see
+<a href="1986/marshall/compilers.html">1986/marshall/compilers.html</a>.</p>
+<div id="compilers">
+<h4 id="default-compiler">Default compiler</h4>
+</div>
+<p><strong>IMPORTANT NOTE</strong>: The use of <code>-std=gnu17</code> does <strong>NOT</strong> imply the use of the <code>gcc</code>
+compiler! We often start by compiling using the <strong>clang</strong> C compiler instead.</p>
+<p><strong>PLEASE NOTE</strong>: in macOS, the compiler <code>gcc</code> found at <code>/usr/bin/gcc</code> is
+in truth the <code>clang</code> compiler, as <code>/usr/bin/gcc --version</code> will show!</p>
+<div id="cstd">
+<div id="standard">
+<h4 id="c-standard">C standard</h4>
+</div>
+</div>
+<p>You may change the standard under which your submission is compiled
+by modifying the <code>CSTD</code> Makefile variable. For example, to use <code>c99</code> instead:</p>
+<pre><code>    CSTD= -std=c99</code></pre>
+<div id="opt">
+<div id="optimization">
+<div id="optimisation">
+<div id="optimizer">
+<div id="optimiser">
+<h4 id="default-optimisation-level">Default optimisation level</h4>
+</div>
+</div>
+</div>
+</div>
+</div>
+<p>You may change the level of optimization and compiler debug level
+that your submission is compiled with, by modifying the <code>OPT</code> Makefile variable.
+For example, to compile without optimization, and to include debug symbols:</p>
+<pre><code>    OPT= -O0 -g3</code></pre>
+<div id="warnings">
+<div id="cwarn">
+<h4 id="compiler-warnings">Compiler warnings</h4>
+</div>
+</div>
+<p>The default warning flags are set via the <code>CWARN</code> variable, as shown in the
+example <code>Makefile</code>:</p>
+<pre><code>    # Common C compiler warning flags
+    #
+    CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN}</code></pre>
+<p>For details on <code>CSILENCE</code> and <code>CUNKNOWN</code>, see the <a href="#disabling-warnings">section on disabling
+warnings</a>.</p>
+<div id="weverything">
+<h5 id="the--weverything-option">The <code>-Weverything</code> option</h5>
+</div>
+<p>We do <strong>NOT</strong> recommend that you put
+the use of <code>-Weverything</code> into your submission’s <code>Makefile</code> for the reasons
+cited there. This goes even if your version does not trigger a warning as some
+other version might!</p>
+<p>On the other hand, if <code>${CC}</code> has “<code>clang</code>” in the name, the example <code>Makefile</code> will
+automatically enable <code>-Weverything</code>, so you might have to use <code>-Wno-foo</code>
+options anyway, as detailed below.</p>
+<p>If “<code>clang</code>” is NOT in <code>${CC}</code>, the <code>CWARN</code> variable will not be further
+modified.</p>
+<p>There is no real penalty for compiler warnings. Sometimes
+compiler warnings cannot be helped: especially in the case of
+obfuscated C. :-) So if you cannot easily get rid of a compiler
+warning, try not to fret too much.</p>
+<p>We <strong>LIKE</strong> code that has a minimum of warnings, especially under the
+more strict <code>-Wall -Wextra -pedantic</code> mode:</p>
+<pre><code>    CWARN= -Wall -Wextra -pedantic</code></pre>
+<p>The two previous guidelines might be thought by some as being somewhat
+contradictory. Isn’t life, and isn’t trying to satisfy “contradictory customer
+requirements” all too often like that? :-) Try to minimize warnings if you
+can.</p>
+<p>If you manage to produce very few warnings, or perhaps no warnings at
+all under the <code>-Wall -Wextra -pedantic</code> mode, then by all means brag about it in
+your <code>remarks.md</code> file <strong>AND BE SURE TO TELL US</strong> the OS, OS version, compiler
+and compiler version in which you observed this occurring (in case our OS and
+compiler produces a different result: so your submission won’t be penalized for
+not meeting your claims).</p>
+<p>On the other hand, some warnings cannot be disabled and are enabled by compilers
+without any warning option specified. These are sometimes inevitable in
+obfuscated code and even in some non-obfuscated code, and you should not worry
+about this, though it might be worth pointing out.</p>
+<p>For instance, some compilers like to warn about use of pointers as arrays, which seems to
+be dubious, as it obviously can’t (always) be avoided, being a big part of C, so
+you should not worry about this either; this is the warning
+<code>-Wunsafe-buffer-usage</code> and the way to disable it is <code>-Wno-unsafe-buffer-usage</code>.</p>
+<h4 id="disabling-warnings">Disabling warnings</h4>
+<p class="leftbar">
+If you do have to disable warnings due to <code>-Weverything</code> automatically being
+included, you might wish to state this fact in your <code>remarks.md</code> file.
+And even without <code>-Weverything</code> there can be warnings, as noted above.
+</p>
+<p>If your submission issues lots of warnings but is otherwise
+marvelously obfuscated in multiple levels, don’t worry about it. Nevertheless,
+be sure that the warnings do not constitute a potential “<strong>show stopper</strong>”
+compiler problem. Be sure that compilers such as both <code>gcc</code> and <code>clang</code> won’t
+produce a compiler <strong>error</strong> and refuse to compile your code: unless for some
+reason that is what you intend to happen in which case document that too in your
+<code>remarks.md</code> file. :-)</p>
+<p>All other things being equal, a program that must turn off fewer
+warnings will be considered better, for certain values of better.</p>
+<p>To turn off a compiler warning, in your submission’s <code>Makefile</code>,
+try something such as:</p>
+<pre><code>    CSILENCE= -Wno-some-thing -Wno-another-thing</code></pre>
+<p class="leftbar">
+For instance:
+</p>
+<pre><code>    CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation</code></pre>
+<div id="macros">
+<h4 id="defining-macros-in-the-makefile">Defining macros in the Makefile</h4>
+</div>
+<p>If you need to define something on the compile line, use
+the <code>CDEFINE</code> Makefile variable. For example:</p>
+<pre><code>    CDEFINE= -Dfoo -Dbar=baz</code></pre>
+<p><strong>NOTE</strong>: just because we offer a default way to use the <code>-D</code> option, we still
+do not like excess use of <code>-D</code> to get past size limits, especially since you
+could use <code>#define</code> in your code instead.</p>
+<div id="include">
+<h4 id="include-files-in-the-makefile">Include files in the Makefile</h4>
+</div>
+<p>If you need to include a file (as in <code>#include</code>) on the command line, use the
+<code>CINCLUDE</code> Makefile variable. For example:</p>
+<pre><code>    CINCLUDE= -include stdio.h</code></pre>
+<div id="magic">
+<h4 id="magic-in-the-makefile">Magic in the Makefile</h4>
+</div>
+<p>If you need to add other “<strong>magic</strong>” flags to your compile line,
+use the <code>COTHER</code> Makefile variable. For example:</p>
+<pre><code>    COTHER= -fno-math-errno</code></pre>
+<p><strong>NOTE</strong>: <strong>We only recommend using “<em>magic</em>” flags if <em>BOTH</em> <code>gcc</code>
+<em>and</em> <code>clang</code></strong> support it.</p>
+<p>Again, please note that in macOS, <code>/usr/bin/gcc</code> is actually <code>clang</code>!</p>
+<div id="clobber">
+<h4 id="the-clobber-rule">The clobber rule</h4>
+</div>
+<p>When <code>make clobber</code> is invoked, we request that submissions be restored
+to their original submission state. For example, any temporary files
+(<strong>including</strong> the compiled program(s)) created during the build process, or
+during execution should be removed by the <code>clobber</code> rule. In other words, the
+only things that should be in the directory after running <code>make clobber</code> is what
+is in your submission tarball itself.</p>
+<p>While people are free to manage their submission under <code>git(1)</code> or even use a
+GitHub repo, dot-files and dot-directories such as <code>.git</code> are not allowed in a
+submission.</p>
+<p>The <code>mkiocccentry(1)</code> tool will ignore dot-files and dot-directories (such as
+<code>.vimrc</code>, <code>.bashrc</code>, <code>.git</code> and <code>.github</code>) and not put them in the submission’s
+compressed tarball. So while you may use such files and
+directories to help develop your submission, they won’t be included when you run
+the <code>mkiocccentry(1)</code> tool.</p>
+<p>Even if you did manage to get dot files or dot directories in the tarball
+somehow, <code>txzchk(1)</code> will flag it as an error. When the judges run <code>txzchk(1)</code>
+on the uploaded submission compressed tarball, if anything is wrong, for
+instance if you “sneak in” any dot files or dot directories, the submission
+<strong>WILL BE REJECTED</strong> for violating
+<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
+<p>You may use whatever tools you need to develop your submission, including the
+use of <code>git(1)</code> or <code>gh(1)</code>, just be sure that your submission code and your
+submission Makefile don’t depend on such tools.</p>
+<p>Of course if you do use GitHub to work on your submission, you might want to
+make the repo private so you don’t reveal who you are. :-)</p>
+<p class="leftbar">
+In other words, make <strong>SURE</strong> you keep anonymous who submitted the code!
+</p>
+<p class="leftbar">
+Please do <strong>NOT</strong> use these tools to help with the
+<code>clobber</code> rule! For instance, do <strong>NOT</strong> use <code>git clean</code>! Not only does this
+depend on the user having <code>git(1)</code> but it also does not account for the
+submission tarballs. Even worse is when someone does have it in a <code>git(1)</code> repo
+it will remove files that are not under <code>git(1)</code> control! Instead, see the
+<code>clobber</code> rule in the example Makefile to see how to manage this.
+</p>
+<p>In other words, for <code>make clobber</code>, do something like:</p>
+<pre><code>    clobber:
+            ${RM} -f foo bar baz</code></pre>
+<p>and <strong>NOT</strong> something like this:</p>
+<pre><code>    # do NOT do this!
+    clobber:
+            -git clean -f   # WRONG !!!</code></pre>
+<p>And do <strong>NOT</strong> use <code>git</code> for any other <code>Makefile</code> rule either.</p>
+<p><strong>NOTE</strong>: <code>mkiocccentry(1)</code> will directly run <code>make clobber</code> in the submission
+directory. And although it is not an error if this fails, if it fails because the
+Makefile does not have a clobber rule, it will be flagged by <code>mkiocccentry(1)</code>
+(you may ignore this but it does put you at a risk of violating the rules).</p>
+<p>Jump to: <a href="#">top</a></p>
 <hr style="width:50%;text-align:left;margin-left:0">
 <hr style="width:50%;text-align:left;margin-left:0">
 <div id="judging_process">
diff --git a/faq.md b/faq.md
index f79f953a3..e1f435682 100644
--- a/faq.md
+++ b/faq.md
@@ -1,6 +1,6 @@
 # IOCCC FAQ Table of Contents
 
-This is FAQ version **28.2.24 2025-11-18**.
+This is FAQ version **29.01 2025-11-28**.
 
 
 ## 0. [Entering the IOCCC: the bare minimum you need to know](#enter_questions)
@@ -31,6 +31,7 @@ This is FAQ version **28.2.24 2025-11-18**.
 - **Q 1.9**: <a class="normal" href="#submission_dir">How can I avoid having to move or delete my submission directory for the same workdir?</a>
 - **Q 1.10**: <a class="normal" href="#download_submission">Can I download my submission tarball from the submit server?</a>
 - **Q 1.11**: <a class="normal" href="#del_submission">Can I delete a submission from the submit server?</a>
+- **Q 1.12**: <a class="normal" href="#makefile_details">What are the detailed recommendations for a submission Makefile?</a>
 
 
 ## 2. [IOCCC Judging process](#judging_process)
@@ -416,6 +417,7 @@ first.
 
 Jump to: [top](#)
 
+
 <div id="SUS">
 <div id="platform">
 <div id="portability">
@@ -512,6 +514,10 @@ date
 does have other rules like `everything` and `alt`, and we encourage you to use
 the one linked to above.
 
+See also the
+FAQ on "[detailed Makefile recommendations](#makefile_details)"
+for more details.
+
 
 Jump to: [top](#)
 
@@ -834,7 +840,7 @@ for more details.
 
 
 <div id="extra-files">
-# 1.5: What are extra files and how may I include additional files beyond the max allowed?
+### Q1.5: What are extra files and how may I include additional files beyond the max allowed?
 </div>
 
 Extra files are defined as files that are not the free files (the required files
@@ -929,6 +935,7 @@ for more details.
 
 Below we will list more details and link to relevant FAQs as well.
 
+
 Jump to: [top](#)
 
 
@@ -1264,6 +1271,7 @@ FAQ on "[the answers file](#answers_file)".
 
 Jump to: [top](#)
 
+
 <div id="submission_dir">
 ### Q 1.9: How can I avoid having to move or delete my submission directory for the same workdir?
 </div>
@@ -1285,6 +1293,7 @@ specify the path by the `-r rm` option.
 
 Jump to: [top](#)
 
+
 <div id="download_submission">
 ### Q 1.10: Can I download my submission tarball from the submit server?
 </div>
@@ -1293,8 +1302,10 @@ We do not support this. If you need to verify your submission, then
 you can re-upload (while the contest is in open state) and verify the SHA256
 checksum listed in the submission slot.
 
+
 Jump to: [top](#)
 
+
 <div id="del_submission">
 ### Q 1.11: Can I delete a submission from the submit server?
 </div>
@@ -1304,9 +1315,334 @@ Makefile](next/Makefile.example) to your Makefile and add to the remarks.md:
 
 > Please ignore this submission.
 
+
 Jump to: [top](#)
 
 
+<div id="makefile_details">
+### Q 1.12: What are the detailed recommendations for a submission Makefile?
+</div>
+
+We **recommend** AND **encourage** you to use the example Makefile,
+as the starting point for your submission's required `Makefile`:
+
+- [view example Makefile](%%REPO_URL%%/next/Makefile.example)
+- <a href="Makefile.example" download="Makefile">download example Makefile</a>
+
+Feel free to modify the `Makefile` to suit your obfuscation needs.
+
+**Please** add a space between the `=` and the value of variables, in the
+`Makefile`, making sure that the `=` comes immediately after the name. See the
+example `Makefile` for examples.
+
+The rest of this section and its subsections will assume that you are using some
+variant of the example `Makefile`, again renamed as `Makefile`.
+
+We suggest that you compile your submission with a commonly available
+`-std=gnu17` (ISO C 2017 with GNU extensions) C compiler, via `clang(1)`
+and/or `gcc(1)`.
+
+
+<div id="cflags">
+<div id="flags">
+#### Default compiler flags
+</div>
+</div>
+
+Unless you **clearly state** otherwise in your `remarks.md` file, **AND** put in
+your submission's `Makefile`, we **will** compile using `-std=gnu17 -O3`!
+
+It **is OK** if you need to require your submission to **NOT be** compiled
+using the default `-std=gnu17 -O3` settings.  Simply **explain why**
+your submission should NOT be compiled using `-std=gnu17 -O3` in
+your `remarks.md` file, **AND** adjust your `Makefile` accordingly.
+
+<p class="leftbar">
+You really should **NOT** redefine `CC` because doing so makes it less portable. <-- **Hint!**
+</p>
+
+One reason that you might have to change the flags, is that the optimiser is
+known to break some programs, but there are certainly other possible valid
+reasons. Again, just update the `Makefile` and explain it in your `remarks.md`.
+See the [optimiser section](#optimiser) for details for changing optimiser
+flags.
+
+For more fun when it comes to optimisers breaking code, see
+[1986/marshall/compilers.html](1986/marshall/compilers.html).
+
+
+<div id="compilers">
+#### Default compiler
+</div>
+
+**IMPORTANT NOTE**: The use of `-std=gnu17` does **NOT** imply the use of the `gcc`
+compiler!  We often start by compiling using the **clang** C compiler instead.
+
+**PLEASE NOTE**: in macOS, the compiler `gcc` found at `/usr/bin/gcc` is
+in truth the `clang` compiler, as `/usr/bin/gcc --version` will show!
+
+
+<div id="cstd">
+<div id="standard">
+#### C standard
+</div>
+</div>
+
+You may change the standard under which your submission is compiled
+by modifying the `CSTD` Makefile variable.  For example, to use `c99` instead:
+
+``` <!---make-->
+    CSTD= -std=c99
+```
+
+
+<div id="opt">
+<div id="optimization">
+<div id="optimisation">
+<div id="optimizer">
+<div id="optimiser">
+#### Default optimisation level
+</div>
+</div>
+</div>
+</div>
+</div>
+
+You may change the level of optimization and compiler debug level
+that your submission is compiled with, by modifying the `OPT` Makefile variable.
+For example, to compile without optimization, and to include debug symbols:
+
+``` <!---make-->
+    OPT= -O0 -g3
+```
+
+
+<div id="warnings">
+<div id="cwarn">
+#### Compiler warnings
+</div>
+</div>
+
+The default warning flags are set via the `CWARN` variable, as shown in the
+example `Makefile`:
+
+``` <!---make-->
+    # Common C compiler warning flags
+    #
+    CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN}
+```
+
+For details on `CSILENCE` and `CUNKNOWN`, see the [section on disabling
+warnings](#disabling-warnings).
+
+
+<div id="weverything">
+##### The `-Weverything` option
+</div>
+
+We do **NOT** recommend that you put
+the use of `-Weverything` into your submission's `Makefile` for the reasons
+cited there. This goes even if your version does not trigger a warning as some
+other version might!
+
+On the other hand, if `${CC}` has "`clang`" in the name, the example `Makefile` will
+automatically enable `-Weverything`, so you might have to use `-Wno-foo`
+options anyway, as detailed below.
+
+If "`clang`" is NOT in `${CC}`, the `CWARN` variable will not be further
+modified.
+
+There is no real penalty for compiler warnings.  Sometimes
+compiler warnings cannot be helped: especially in the case of
+obfuscated C.  :-)  So if you cannot easily get rid of a compiler
+warning, try not to fret too much.
+
+We **LIKE** code that has a minimum of warnings, especially under the
+more strict ` -Wall -Wextra -pedantic` mode:
+
+``` <!---make-->
+    CWARN= -Wall -Wextra -pedantic
+```
+
+The two previous guidelines might be thought by some as being somewhat
+contradictory.  Isn't life, and isn't trying to satisfy "contradictory customer
+requirements" all too often like that?  :-)  Try to minimize warnings if you
+can.
+
+If you manage to produce very few warnings, or perhaps no warnings at
+all under the `-Wall -Wextra -pedantic` mode, then by all means brag about it in
+your `remarks.md` file **AND BE SURE TO TELL US** the OS, OS version, compiler
+and compiler version in which you observed this occurring (in case our OS and
+compiler produces a different result: so your submission won't be penalized for
+not meeting your claims).
+
+On the other hand, some warnings cannot be disabled and are enabled by compilers
+without any warning option specified. These are sometimes inevitable in
+obfuscated code and even in some non-obfuscated code, and you should not worry
+about this, though it might be worth pointing out.
+
+For instance, some compilers like to warn about use of pointers as arrays, which seems to
+be dubious, as it obviously can't (always) be avoided, being a big part of C, so
+you should not worry about this either; this is the warning
+`-Wunsafe-buffer-usage` and the way to disable it is `-Wno-unsafe-buffer-usage`.
+
+
+<div id="disabling-warnings">
+#### Disabling warnings
+</div>
+
+<p class="leftbar">
+If you do have to disable warnings due to `-Weverything` automatically being
+included, you might wish to state this fact in your `remarks.md` file.
+And even without `-Weverything` there can be warnings, as noted above.
+</p>
+
+If your submission issues lots of warnings but is otherwise
+marvelously obfuscated in multiple levels, don't worry about it.  Nevertheless,
+be sure that the warnings do not constitute a potential "**show stopper**"
+compiler problem.  Be sure that compilers such as both `gcc` and `clang` won't
+produce a compiler **error** and refuse to compile your code: unless for some
+reason that is what you intend to happen in which case document that too in your
+`remarks.md` file.  :-)
+
+All other things being equal, a program that must turn off fewer
+warnings will be considered better, for certain values of better.
+
+To turn off a compiler warning, in your submission's `Makefile`,
+try something such as:
+
+``` <!---make-->
+    CSILENCE= -Wno-some-thing -Wno-another-thing
+```
+
+<p class="leftbar">
+For instance:
+</p>
+
+``` <!---make-->
+    CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation
+```
+
+
+<div id="macros">
+#### Defining macros in the Makefile
+</div>
+
+If you need to define something on the compile line, use
+the `CDEFINE` Makefile variable.  For example:
+
+``` <!---make-->
+    CDEFINE= -Dfoo -Dbar=baz
+```
+
+**NOTE**: just because we offer a default way to use the `-D` option, we still
+do not like excess use of `-D` to get past size limits, especially since you
+could use `#define` in your code instead.
+
+<div id="include">
+#### Include files in the Makefile
+</div>
+
+If you need to include a file (as in `#include`) on the command line, use the
+`CINCLUDE` Makefile variable.  For example:
+
+``` <!---make-->
+    CINCLUDE= -include stdio.h
+```
+
+
+<div id="magic">
+#### Magic in the Makefile
+</div>
+
+If you need to add other "**magic**" flags to your compile line,
+use the `COTHER` Makefile variable.  For example:
+
+``` <!---make-->
+    COTHER= -fno-math-errno
+```
+
+**NOTE**: **We only recommend using "_magic_" flags if _BOTH_ `gcc`
+_and_ `clang`** support it.
+
+Again, please note that in macOS, `/usr/bin/gcc` is actually `clang`!
+
+
+<div id="clobber">
+#### The clobber rule
+</div>
+
+When `make clobber` is invoked, we request that submissions be restored
+to their original submission state.  For example, any temporary files
+(**including** the compiled program(s)) created during the build process, or
+during execution should be removed by the `clobber` rule. In other words, the
+only things that should be in the directory after running `make clobber` is what
+is in your submission tarball itself.
+
+While people are free to manage their submission under `git(1)` or even use a
+GitHub repo, dot-files and dot-directories such as `.git` are not allowed in a
+submission.
+
+The `mkiocccentry(1)` tool will ignore dot-files and dot-directories (such as
+`.vimrc`, `.bashrc`, `.git` and `.github`) and not put them in the submission's
+compressed tarball. So while you may use such files and
+directories to help develop your submission, they won't be included when you run
+the `mkiocccentry(1)` tool.
+
+Even if you did manage to get dot files or dot directories in the tarball
+somehow, `txzchk(1)` will flag it as an error. When the judges run `txzchk(1)`
+on the uploaded submission compressed tarball, if anything is wrong, for
+instance if you "sneak in" any dot files or dot directories, the submission
+**WILL BE REJECTED** for violating
+[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
+
+You may use whatever tools you need to develop your submission, including the
+use of `git(1)` or `gh(1)`, just be sure that your submission code and your
+submission Makefile don't depend on such tools.
+
+Of course if you do use GitHub to work on your submission, you might want to
+make the repo private so you don't reveal who you are. :-)
+
+<p class="leftbar">
+In other words, make **SURE** you keep anonymous who submitted the code!
+</p>
+
+<p class="leftbar">
+Please do **NOT** use these tools to help with the
+`clobber` rule! For instance, do **NOT** use `git clean`! Not only does this
+depend on the user having `git(1)` but it also does not account for the
+submission tarballs. Even worse is when someone does have it in a `git(1)` repo
+it will remove files that are not under `git(1)` control! Instead, see the
+`clobber` rule in the example Makefile to see how to manage this.
+</p>
+
+In other words, for `make clobber`, do something like:
+
+
+``` <!---makefile-->
+    clobber:
+            ${RM} -f foo bar baz
+```
+
+and **NOT** something like this:
+
+``` <!---makefile-->
+    # do NOT do this!
+    clobber:
+            -git clean -f   # WRONG !!!
+```
+
+And do **NOT** use `git` for any other `Makefile` rule either.
+
+
+**NOTE**: `mkiocccentry(1)` will directly run `make clobber` in the submission
+directory. And although it is not an error if this fails, if it fails because the
+Makefile does not have a clobber rule, it will be flagged by `mkiocccentry(1)`
+(you may ignore this but it does put you at a risk of violating the rules).
+
+
+Jump to: [top](#)
+
 
 <hr style="width:50%;text-align:left;margin-left:0">
 <hr style="width:50%;text-align:left;margin-left:0">
@@ -1914,6 +2250,7 @@ of `chkentry(1)` when validating a directory; `chkentry(1)` is for the judges
 and is what was used in IOCCC28. For IOCCC29 and beyond, `mkiocccentry(1)` uses
 `chksubmit(1)` and so should you.
 
+
 Jump to: [top](#)
 
 
@@ -7059,6 +7396,7 @@ to help ensure that everyone may enjoy the IOCCC.
 
 Jump to: [top](#)
 
+
 <div id="try_mastodon">
 ### Q 10.6: What is Mastodon and why does the IOCCC use it?
 </div>
@@ -7095,6 +7433,7 @@ follow posts something so you will have to check the IOCCC feed manually.
 mastodon feed](https://fosstodon.org/@ioccc) page and/or mastodon
 app from time to time to view IOCCC mastodon updates.
 
+
 Jump to: [top](#)
 
 
@@ -7117,8 +7456,8 @@ It is not yet clear if this only works on desktop/computers or mobile devices
 too as it was only just discovered (31 July 2025) but whatever the case we
 suggest you do it.
 
-Jump to: [top](#)
 
+Jump to: [top](#)
 
 
 <div id="tabstops">
diff --git a/next/guidelines.html b/next/guidelines.html
index e5b437f2e..ce7bb3a11 100644
--- a/next/guidelines.html
+++ b/next/guidelines.html
@@ -473,164 +473,33 @@ mastodon feed</a> page and/or mastodon
 app from time to time to view IOCCC mastodon updates.</p>
 <!-- END: the next line ends content from: inc/guidelines.closed.hdr -->
 <!-- This is the last line modified by the tool: bin/gen-status.sh -->
-<h1 id="th-international-obfuscated-c-code-contest-official-guidelines">28th International Obfuscated C Code Contest Official Guidelines</h1>
+<h1 id="th-international-obfuscated-c-code-contest-official-guidelines">29th International Obfuscated C Code Contest Official Guidelines</h1>
 <p class="leftbar">
-Copyright © 2024-2025 Leonid A. Broukhis and Landon Curt Noll.
+Copyright © 2025 Leonid A. Broukhis and Landon Curt Noll.
 </p>
 <p>All Rights Reserved. Permission for personal, education or non-profit use is
 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>
-<p>Jump to: <a href="#">top</a></p>
-<div id="guidelines_version">
-<div id="version">
 <h1 id="ioccc-guidelines-version">IOCCC Guidelines version</h1>
+<p class="leftbar">
+These IOCCC guidelines are version <strong>29.00 2025-11-28</strong>.
+</p>
+<p class="leftbar">
+The <span style="font-size:28px;"><b>|</b></span> symbol indicates an <strong>change</strong> from the previous IOCCC.
+</p>
+<p class="leftbar">
+Because the <strong>IOCCC29</strong> guidelines was a substantial rewrite, only <strong>important changes</strong> from <strong>IOCCC28</strong> have been marked.
+</p>
+<p>Be sure to read the <a href="guidelines.html">IOCCC rules</a>.</p>
+<div id="guideline2">
+<div id="guideline-2---size">
+<h1 id="guidelines-for-rule-2---size">Guidelines for <a href="rules.html#rule-2---size">Rule 2 - Size</a></h1>
 </div>
 </div>
 <p class="leftbar">
-These <a href="guidelines.html">IOCCC guidelines</a> are version <strong>28.49 2025-11-17</strong>.
-</p>
-<p>The markdown form of these guidelines <a href="guidelines.md"
-download="guidelines.md">is available for download</a>.</p>
-<p><strong>IMPORTANT</strong>: Be <strong>SURE</strong> to read the <a href="rules.html">IOCCC rules</a>.</p>
-<p>Jump to: <a href="#">top</a></p>
-<div id="change_marks">
-<h1 id="change-marks">Change marks</h1>
-</div>
-<p class="leftbar">
-<strong>← Lines that start with this symbol indicate a change from the
-previous IOCCC</strong>.
-</p>
-<p>Most lines (we sometimes make mistakes) that were modified since the previous
-IOCCC start with a solid 4 pixel black left border (or, in the case of a code
-block or blockquote, just a vertical bar).</p>
-<p>Jump to: <a href="#">top</a></p>
-<div id="about_guidelines">
-<h1 id="about-this-file">ABOUT THIS FILE:</h1>
-</div>
-<p>This file contains <em>guidelines</em> intended to help people who wish to
-participate in the <a href="https://www.ioccc.org">International Obfuscated C Code Contest
-(IOCCC)</a>.</p>
-<p>These are <strong>NOT the <a href="rules.html">IOCCC rules</a></strong>, though it does contain comments
-about them. The <a href="guidelines.html">IOCCC guidelines</a> should be viewed as
-<strong>hints</strong> and <strong>suggestions</strong>. <strong>Submission that violate the
-<a href="guidelines.html">guidelines</a> <em>but remain within the <a href="rules.html">rules</a></em></strong> <em>are
-allowed</em>. Even so, you are safer if you remain within the <a href="guidelines.html">IOCCC
-guidelines</a>.</p>
-<p>Of course if a guideline is talking about a rule and you break that guideline,
-you stand a good chance of having your submission rejected for breaking the
-rule, not the guideline.</p>
-<p>You <strong>SHOULD read the CURRENT <a href="rules.html">IOCCC rules</a></strong>, <em>prior</em> to submitting
-code to the contest.</p>
-<p>Jump to: <a href="#">top</a></p>
-<div id="new">
-<h1 id="whats-new-this-ioccc">WHAT’S NEW THIS IOCCC</h1>
-</div>
-<p class="leftbar">
-This IOCCC runs from <strong>2024-12-29 23:58:13.213455 UTC</strong> to <strong>2025-06-05 04:03:02.010099 UTC</strong>.
-This IOCCC marks the <strong>40th anniversary</strong> of the contest!
-</p>
-<p class="leftbar">
-This contest will enter the <strong><a href="../faq.html#pending">pending</a></strong> state on or about
-<strong>2024-12-29 23:58:13.213455 UTC</strong>.
-When this happens, you may begin registering to enter the IOCCC.
-</p>
-<p class="leftbar">
-This contest will enter the <strong><a href="../faq.html#open">open</a></strong> state on <strong>2025-03-05 23:19:17.131107 UTC</strong>.
-When this happens, you may begin uploading your submissions to the IOCCC.
-</p>
-<p class="leftbar">
-This contest will enter the <strong><a href="../faq.html#judging">judging</a></strong> state on <strong>2025-06-05 04:03:02.010099 UTC</strong>.
-When this happens, you may no longer upload your submissions to the IOCCC.
-</p>
-<p><strong>IMPORTANT NOTE</strong>: Until the contest enters the <strong><a href="../faq.html#open">open</a></strong> state, any or all
-of the above <strong>dates and times may change <em>AT ANY TIME</em></strong>!</p>
-<p class="leftbar">
-The reason for the times of day are so that key IOCCC events are <strong>calculated</strong>
-to be a <strong>fun</strong>ctional UTC time. :-)
-</p>
-<p>Until the contest status becomes <strong><a href="../faq.html#open">open</a></strong>,
-the <a href="rules.html">IOCCC rules</a>,
-<a href="guidelines.html">IOCCC guidelines</a> and the tools in the
-<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a> <strong>SHOULD be
-considered</strong> provisional <strong>BETA</strong> versions and <strong>may be adjusted <em>AT ANY TIME</em></strong>
-before the contest status becomes <strong><a href="../faq.html#open">open</a></strong>.</p>
-<p>See the
-FAQ on “<a href="../quick-start.html#enter">how to register and submit to the IOCCC</a>”
-for instructions on registering and participating in the IOCCC, as the process
-may change from contest to contest.</p>
-<p>To assist in the formation of the xz compressed tarball for submission, use the
-<code>mkiocccentry(1)</code> tool as found in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>.</p>
-<p>See FAQs regarding:</p>
-<ul>
-<li><a href="../faq.html#obtaining_mkiocccentry">obtaining the latest mkiocccentry tools</a></li>
-<li><a href="../faq.html#compiling_mkiocccentry">compiling the mkiocccentry tools</a></li>
-<li><a href="../faq.html#install">installing the mkiocccentry tools</a></li>
-<li><a href="../faq.html#using_mkiocccentry">using the mkiocccentry tools</a></li>
-</ul>
-<p>Uploading a tarball not formed by <code>mkiocccentry(1)</code> puts you at a very big risk of
-violating
-<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>,
-especially as <code>mkiocccentry(1)</code> does a
-great number of things that are required, and it also runs many checks, and if
-any of those checks fail, you are at a very great risk of having your submission
-rejected for violating
-<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p>
-<p>We <strong>STRONGLY</strong> recommend you <strong>do</strong> install the
-<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>.</p>
-<p><strong>IMPORTANT NOTE</strong>: the tools that require other tools, <code>mkiocccentry(1)</code> and
-<code>txzchk(1)</code>, will, as of version <code>2.0.2 2025-03-11</code>, search under <code>$PATH</code>. If
-you have an earlier version and you have not installed the tools and run the
-tools from outside the repo directory, you will have to use the options to the
-tools to set the path to the required tools.</p>
-<p>See the
-FAQ on “<a href="../faq.html#mkiocccentry">obtaining and compiling the most recent mkiocccentry tools</a>”
-and the
-FAQ on “<a href="../quick-start.html#enter">how to enter the IOCCC</a>”
-as that FAQ has important details on
-<a href="../next/register.html">how to register</a>
-as well as
-<a href="../next/submit.html">how to upload your submission</a> to the IOCCC.</p>
-<p>While the contest is <strong><a href="../faq.html#open">open</a></strong>, you may modify your
-previously uploaded submission by rebuilding your submission with the
-<code>mkiocccentry(1)</code> tool and then re-uploading it to <strong>the same slot number</strong> on the
-<a href="https://submit.ioccc.org">submit server</a>.</p>
-<p><strong>HINT:</strong> so that you do not have to repeatedly answer all the
-questions, the <code>mkiocccentry(1)</code> tool has the options <code>-a answers</code>, <code>-A answers</code>
-and <code>-i answers</code>, where <code>-a</code> will write to an answers file (if it does not
-already exist), <code>-A</code> <strong>WILL OVERWRITE THE FILE</strong> and <code>-i</code> will read the answers from
-the file. If you use <code>-A</code>, <strong>BE SURE</strong> you don’t overwrite another file by accident!</p>
-<p>Be aware that even with the <code>-i answers</code> you will still be required to confirm
-most if not all <code>y/n</code> questions - you just don’t have to input the name of the
-submission, the abstract, the author details etc. If you really wish to
-circumvent this you can use the <code>-Y</code> option but we do not recommend this because
-if your update breaks a rule or there is some problem, you might not see it.</p>
-<p>To help with not having to repeatedly enter a UUID, whether for the same
-submission or multiple submissions, you can use the <code>-u uuidfile</code> or <code>-U UUID</code>
-option. See the
-FAQ on “<a href="../faq.html#uuid">how to avoid re-entering your UUID</a>”
-for more details. Note that the <code>-i answers</code> option cannot be used with the UUID
-options as the answers file includes the UUID.</p>
-<p>The overall size limit (see Rule 2a Gross Size](rules.html#rule-2a-gross-size)) on <code>prog.c</code> has been
-<strong>increased from 4096 to 4993</strong> bytes.
-The <a href="rules.html#rule-2b-net-size">Rule 2b Next Size</a>size was changed from
-<strong>4096</strong> to <strong>4993</strong> to keep the “2b to 2a” size ratio to a
-value similar to the <a href="../faq.html#size_rule2001-2012">2001-2012</a> and
-<a href="../faq.html#size_rule2013-2020">2013-2020</a> IOCCC eras.</p>
-<p>The <a href="rules.html#rule-2b-net-size">Rule 2b Next Size</a> size has <strong>increased from 2053 to 2503</strong>
-bytes.</p>
-<p class="leftbar">
-However, you should pay especial attention to our remarks in the <a href="../2024/index.html">IOCCC28
-index.html</a>:
-</p>
-<p class="leftbar">
-<blockquote>
-<p><strong>IMPORTANT HINT</strong>: Only 3 of the 23 <strong>IOCCC28 winners</strong> came close to the
-<a href="rules.html#rule-2---size">Rule 2 - Size</a> limit.
-Large code size isn’t
-everything. :-) Those submitting to future contents should <strong>take a careful
-note</strong> of that fact.</p>
-</blockquote>
+You should pay attention to our observations on
+<a href="../2024/index.html#code-size-and-rule-2">code size and Rule 2 remarks for IOCCC28</a>.
 </p>
 <p>Your submission must satisfy <strong>BOTH</strong> the maximum size
 <a href="rules.html#rule-2a-gross-size">Rule 2a Gross Size</a>
@@ -648,1193 +517,66 @@ preprocessor keywords) as 1. The size tool counts all other bytes as 1
 excluding ASCII whitespace, and excluding any ‘<code>;</code>’, ‘<code>{</code>’ or ‘<code>}</code>’ followed by
 ASCII whitespace, and excluding any ‘<code>;</code>’, ‘<code>{</code>’ or ‘<code>}</code>’ byte immediately
 before the end of file.</p>
-</blockquote>
-<p>ASCII whitespace includes ASCII tab, ASCII space, ASCII newline,
-ASCII formfeed, and ASCII carriage return.</p>
+<p>ASCII whitespace includes ASCII tab, ASCII space, ASCII newline, ASCII formfeed, and ASCII carriage return.</p>
 <p>When ‘<code>;</code>’, ‘<code>{</code>’ or ‘<code>}</code>’ are within a C string, they may still not be
-counted by the IOCCC size tool. This is a <strong>feature</strong>, not a bug!</p>
+counted by the IOCCC size tool.</p>
+</blockquote>
 <p>In cases where the above summary and the algorithm implemented by
 the IOCCC size tool <code>iocccsize(1)</code> conflict, the algorithm implemented
 by the current version of <code>iocccsize(1)</code> is preferred by the <a href="../judges.html">IOCCC judges</a>.</p>
-<p>In other words, make sure <code>iocccsize</code> does not flag any issues with your
-<code>prog.c</code>.</p>
-<p>There are at least 2 other reasons for selecting 2503 as the 2nd limit besides
-the fact that 2503 is a prime. These reasons may be searched for and discovered
-if you are <a href="https://t5k.org/curios/page.php/2503.html">“Curios!” about 2503</a>.
-:-) Moreover, 2053 was the number of the kernel disk pack of one of the judge’s
-BESM-6, and 2503 is a decimal anagram of 2053.</p>
-<p>Take note that this secondary limit imposed by the IOCCC size tool
-obviates some of the need to <code>#define</code> C reserved words in an effort
+<p>Make sure <code>iocccsize</code> does not flag any issues with your <code>prog.c</code>.</p>
+<p>There a much less need to <code>#define</code> C reserved words in an effort
 to get around the size limits of
-<a href="rules.html#rule-2---size">Rule 2 - Size</a>.</p>
-<p>Yes Virginia, <strong>that is a hint</strong>!</p>
-<p>The <strong>official locale</strong> of the <strong>IOCCC</strong> is <strong>C</strong>.</p>
-<p class="leftbar">
-Did you really think anything else? :-)
-</p>
-The <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>,
-as of <a href="https://github.com/ioccc-src/mkiocccentry/releases/tag/2.4.4">Release version 2.4.4 2025-03-15</a>,
-will run with a locale set to <strong>C</strong>.
-</p>
+<a href="rules.html#rule-2---size">Rule 2 - Size</a>
+because of the <code>iocccsize(1)</code> algorithm.</p>
+<p>Yes Virginia, <strong>the previous guideline sentence is an important hint</strong>!</p>
 <p>Jump to: <a href="#">top</a></p>
-<div id="hints">
-<div id="suggestions">
-<h1 id="hints-and-suggestions">HINTS AND SUGGESTIONS:</h1>
+<div id="guideline3">
+<div id="guideline-3---register">
+<h1 id="guidelines-for-rule-3---register">Guidelines for <a href="rules.html#rule-3---register">Rule 3 - Register</a></h1>
 </div>
 </div>
-<p>You are <strong>encouraged</strong> to examine the <a href="../years.html">winners of previous contests</a>.</p>
-<p>Keep in mind that <a href="rules.html">rules</a> change from year to year, so some <a href="../years.html">winning
-entries</a> might not be valid submissions this year; what <em>was</em> unique
-and novel one year <em>might be ‘old’ the next year</em>.</p>
-<p>A submission is usually examined in a number of ways. We typically apply
-a number of tests to a submission:</p>
+<p>See FAQ on “<a href="../faq.html#author_handle_faq">What is an author handle?</a>”.</p>
+<p>Jump to: <a href="#">top</a></p>
+<div id="guideline7">
+<div id="guideline-7---original-work">
+<h1 id="guidelines-for-rule-7---original-work">Guidelines for <a href="rules.html#rule-7---original-work">Rule 7 - Original Work</a></h1>
+</div>
+</div>
+<p>While it is <strong>NOT</strong> required, you are allowed to use tools or services such as:</p>
 <ul>
-<li>look at the original source</li>
-<li>C pre-process the source ignoring <code>#include</code> lines</li>
-<li>C pre-process the source ignoring <code>#define</code> <em>and</em> <code>#include</code> lines</li>
-<li>run it through a C beautifier</li>
-<li>examine the algorithm</li>
-<li>compile it (with flags to enable all warnings)</li>
-<li>execute it</li>
+<li>Code generators</li>
+<li>Static and runtime code analysis tools</li>
+<li>Machine learning tools</li>
+<li>natural language models</li>
+<li>Large language models (LLMs)</li>
+<li>Code copilot tools</li>
+<li>So called “<em>AI services</em>”</li>
+<li>etc.</li>
 </ul>
-<p>You should consider how your submission looks in each of the above tests.
-You should ask yourself if your submission remains obscure after it has been
-‘<em>cleaned up</em>’ by the C pre-processor and a C beautifier.</p>
-<p>Your submission need not pass all of the above tests. In certain
-cases, a test is not important. Submissions that compete for the
-‘<strong>strangest/most creative source layout</strong>’ need not do as well as
-others in terms of their algorithm. On the other hand, given
-two such submissions, we are more inclined to pick the submission that
-does something interesting when it’s executed.</p>
-<p>We try to avoid limiting creativity in our <a href="rules.html">rules</a>. As such, we
-leave the contest open for creative rule interpretation. As in <a href="https://en.wikipedia.org/wiki/Real_life">real
-life</a> programming, interpreting a
-requirements document or a customer request is important. For this reason, we
-often award ‘<strong>Best abuse of the <a href="rules.html">rules</a></strong>’ or ‘<strong>Worst abuse of the
-<a href="rules.html">rules</a></strong>’ or some variation to a submission that illustrates this
-point in an ironic way.</p>
 <p>The IOCCC has a rich history of remarkable winning entries created by
-authors who skillfully employed various techniques to develop their code.
-While it is <strong>NOT</strong> required, you are allowed to use tools to develop
-and test your submission. These tools may include, but are not limited
-to code generators, code analysis tools, static code analysis tools,
-runtime analysis tools, machine learning tools, natural language models,
-code copilot tools, so-called AI services, large language models (LLMS), etc.
-If you do make use of such tools or services, then we <strong>ENCOURAGE you to describe
+authors who skillfully employed various techniques to develop their code.</p>
+<p>If you do make use of such tools or services, then we <strong>ENCOURAGE you to describe
 how you used such tools</strong> in your <code>remarks.md</code> file.</p>
-<p>You may use git, or services such as <a href="https://www.github.com">GitHub</a>
-to develop and maintain your submission. However, we <strong>DISLIKE</strong>
-submissions that <strong>require</strong> them in order to build/compile your submission.</p>
-<p>Submissions will be judged in an environment that has no <strong>IDE</strong>.
-Any submission that fails to compile/build because it requires
-an <strong>IDE</strong> will be rejected.</p>
-<p>We will use the <code>make(1)</code> tool, your <code>Makefile</code>, and other tools found in
-<a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a>
-environments and systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
-Specification</a>
-in the building and compiling of your submission.</p>
-<p>We do realize that there are holes in the <a href="rules.html">rules</a>, and invite
-submitters to attempt to exploit them. We may award ‘<strong>Worst abuse of the
-<a href="rules.html">rules</a></strong>’ or ‘<strong>Best abuse of the <a href="rules.html">rules</a></strong>’ or some
-variation and then plug the hole next year.</p>
-<p>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>There may be fewer than 2^7+1 reasons why these <a href="guidelines.html">IOCCC
-guidelines</a> seem obfuscated.</p>
-<p><strong>IMPORTANT:</strong> Be sure that <strong>your submission works</strong> as documented in your
-<code>remarks.md</code> file. We sometimes make an effort to debug a submission
-that has a slight problem, particularly in or near the final round.
-On the other hand, we have seen some otherwise excellent submissions
-fall down because they didn’t work as documented.</p>
-<p>If you submission has bugs and/or mis-features, you are <strong>MUCH BETTER</strong> off
-documenting such bugs and/or mis-features in your <code>remarks.md</code> file.</p>
-<p>Consider an example of a <a href="https://en.wikipedia.org/wiki/Prime_number">prime number</a>
-printing program that claims that 16 is a prime number.
-Noting such a bug in your <code>remarks.md</code> file could save your submission:</p>
-<blockquote>
-<p>“<em>this submission sometimes prints the 4th power of a prime by mistake</em>”</p>
-</blockquote>
-<p>Sometimes a strange bug or (mis-)feature can even help the submission! Of course, a correctly
-working submission might be better.</p>
-<p>We tend to look down on a <a href="https://en.wikipedia.org/wiki/Prime_number">prime
-number</a> printer that claims that
-16 is a prime number.
-Clever people will note that 16 might be prime
-under certain conditions. ;-) Wise people, when submitting something clever
-will fully explain such cleverness in their submission’s <code>remarks.md</code> file.</p>
-<p>People who are considering to just use some complex mathematical
-function or state machine to spell out something such as “<em>hello,
-world!</em>” <strong>really really, <em>and we do mean REALLY</em>, do need to be more creative</strong>.</p>
-<p>Ultra-obfuscated programs are, in some cases, easier to
-deobfuscate than subtly-obfuscated programs. Consider using
-misleading or subtle tricks layered on top of or under an
-appropriate level of obfuscation. A clean looking program with
-misleading comments and variable names might be a <strong>VERY GOOD START</strong>
-to a great submission!</p>
+<p>In short: You created it, you own it, and its an original work, or you have explicit permission.</p>
+<p>See FAQ on “<a href="../faq.html#ai">May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?</a>”.</p>
 <p>Jump to: <a href="#">top</a></p>
-<h1 id="mkiocccentry"><code>mkiocccentry</code></h1>
-<p><a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>
-(the <code>mkiocccentry(1)</code> rule) states that
-you <strong>REALLY SHOULD</strong> use the <code>mkiocccentry(1)</code> tool to package your submission tarball.</p>
-<p>See the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>
-for the <code>mkiocccentry(1)</code> tool and below for more details.</p>
-<p><strong>IMPORTANT NOTE</strong>: make <strong>CERTAIN</strong> you have the most recent version of the
-<code>mkiocccentry</code> toolkit! See the
-FAQ on “<a href="../faq.html#obtaining_mkiocccentry">obtaining the mkiocccentry toolkit</a>”.</p>
-<p><code>mkiocccentry</code> runs a number of checks, by the tool itself and by executing
-other tools, <em>before</em> packaging your xz compressed tarball, including running
-<code>chksubmit(1)</code> on the submission directory.</p>
-<p>If <code>mkiocccentry</code> encounters an <strong>error</strong>, the program will exit and the xz
-compressed tarball <strong>will not be formed</strong>. For instance, if
-<a href="#chksubmit">chksubmit</a> fails to validate the submission directory, either because
-of a validation error in the <code>.auth.json</code> or <code>.info.json</code>
-<a href="https://www.json.org/json-en.html">JSON</a> files or because of
-something else that <code>mkiocccentry(1)</code> creates or does, it is an
-<strong>error</strong> and <strong>possibly</strong> a bug that you should <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report as a bug at the
-mkiocccentry bug report
-page</a>.
-<strong>PLEASE run the <code>bug_report.sh</code> script to help us out here!</strong> See the
-FAQ on “<a href="../faq.html#mkiocccentry_bugs">reporting mkiocccentry bugs</a>”.</p>
-<p>Once the tarball is packaged it will
-run <code>txzchk(1)</code>, which will also run <code>fnamchk(1)</code>, as part of its algorithm.</p>
-<p>However, even if <code>mkiocccentry</code> or one of the tools it invokes reports an error,
-it <strong>does not</strong> necessarily mean it is a bug in the code. It might be an issue with
-your submission. Thus if you report an error as a bug it might not be something
-that will be fixed as there might not be anything wrong with the tools.</p>
-<p>On the other hand, some conditions flagged by <code>mkiocccentry(1)</code> are <strong>warnings</strong>
-and it allows you to override these, if you wish. If you’re brave enough you can
-use the <code>-W</code> option to ignore all warnings but this is a big risk; the <code>-y</code>
-option will assume ‘<em>yes</em>’ to most questions but this is also a big risk. Using
-<code>-Y</code> will say ‘<em>yes</em>’ to even more prompts. Needless to say, we do <strong>NOT</strong>
-recommend these options.</p>
-<p>In many places it will prompt you to verify what you input, allowing you to
-correct details as you go along. Be advised that there is a default answer and
-if you press enter it will proceed with that default, so make sure you have
-provided the correct answer.</p>
-<p>If you wish to <strong>test</strong> that your submission passes the <code>mkiocccentry(1)</code> tests
-without having to type in in answers each time, you can use the <code>-d</code> or <code>-s seed</code>
-option to <code>mkiocccentry</code> for the tool to pseudo-randomly create answers for you.
-For example:</p>
-<pre><code>    mkiocccentry -d workdir topdir</code></pre>
-<p><strong>IMPORTANT NOTE</strong>: if you run an IOCCC related tool outside the repo directory
-(specifying the absolute or relative path to the tool) and you have not
-installed the tools (and we <strong>STRONGLY</strong> recommend you <strong>do</strong> install them),
-then you will have to specify the options (such as paths) for the tools that are required like
-<code>chksubmit(1)</code>, <code>txzchk(1)</code> and <code>fnamchk(1)</code>.</p>
-<p>Make sure you have
-the latest version of of the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
-so that you do not violate
-<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>
-by mistake.</p>
-<p>Jump to: <a href="#">top</a></p>
-<div id="mkiocccentry-synopsis">
-<h2 id="mkiocccentry1-synopsis"><code>mkiocccentry(1)</code> synopsis</h2>
-</div>
-<p>The synopsis of the <code>mkiocccentry(1)</code> tool is:</p>
-<pre><code>    mkiocccentry [options] workdir topdir</code></pre>
-<p>To help you with editing a submission, the <code>mkiocccentry(1)</code> tool has
-some options to write <em>OR</em> read from an answers file so you do not have to input
-the information about the author(s) and the submission more than once, unless of
-course you need to make some changes, in which case you can use the option that
-overwrites the file. If you do use the overwrite option, <strong>MAKE SURE</strong> you do
-not overwrite another file!</p>
-<p>See the
-FAQ on the
-“<a href="../faq.html#mkiocccentry">mkiocccentry tool</a>”
-for how to use this tool and the
-FAQ on the
-“<a href="../faq.html#mkiocccentry_details">finer details of mkiocccentry</a>”
-for even more information.</p>
-<div id="tools">
-<h1 id="other-mkiocccentry-tools">Other mkiocccentry tools</h1>
-</div>
-<p>The <code>mkiocccentry(1)</code> tool will execute a number of tools, some of which will
-execute one or more additional tools.</p>
-<h2 id="iocccsize"><code>iocccsize</code></h2>
-<p><code>mkiocccentry(1)</code> will use code from <code>iocccsize(1)</code> which detects a number of
-issues (such as <a href="rules.html#rule-2---size">Rule 2 - Size</a>) that you may ignore, if you wish, as
-noted above.</p>
-<p>In other words, you no longer need to run <code>iocccsize</code> manually. However, the
-checks described above are still made but through the <code>mkiocccentry(1)</code> tool itself.</p>
-<p>Jump to: <a href="#">top</a></p>
-<h2 id="chksubmit"><code>chksubmit</code></h2>
-<p><code>mkiocccentry(1)</code> will write two JSON files: <code>.auth.json</code> and
-<code>.info.json</code>. These files contain information about the author(s) and about the
-submission. After these files are formed, the <code>chksubmit(1)</code> tool will be run on
-the submission directory; this tool not only validates the two JSON files
-(and runs specific checks on them after validating the JSON), but it also
-verifies that what is in the manifest in <code>.info.json</code> matches the contents of
-the directory, in addition to other checks. If <code>chksubmit(1)</code> fails to validate
-anything at all, your submission <strong>WILL BE</strong> rejected!</p>
-<p><strong>IMPORTANT</strong>: although <code>chksubmit(1)</code> validates the files in the directory, it
-only inspects the contents of the two JSON files; it performs other kinds of
-checks on the other files, and those checks are run on the two JSON files as
-well.</p>
-<p>If you submit your own JSON files (other than <code>.auth.json</code> and
-<code>.info.json</code>) then they do <strong>NOT</strong> have to be valid JSON.
-However, if you do provide such invalid JSON files, <strong>PLEASE</strong>
-document and explain this in your <code>remarks.md</code> file.</p>
-<p class="leftbar">
-On the other hand, some people might question what actually constitutes a valid
-JSON file. :-)
-</p>
-<p>If <code>chksubmit</code> does not pass and you used <code>mkiocccentry(1)</code> it is <strong>very likely</strong> a
-bug and you should <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the mkiocccentry issues
-page</a>.
-<strong>PLEASE</strong> run the command:</p>
-<pre><code>    make bug_report</code></pre>
-<p>from the top level repo directory itself and attach the bug report file (it will
-tell you the name of the file). See also the
-FAQ on “<a href="../faq.html#mkiocccentry_bugs">reporting mkiocccentry bugs</a>”.</p>
-<p>Assuming that <code>chksubmit(1)</code> successfully validates your submission directory,
-the tarball will be formed and then <code>txzchk(1)</code> will be executed on it. In this
-case, there should be no problems, as <code>mkiocccentry(1)</code> should <strong>NOT</strong> form a
-tarball if there are any issues.</p>
-<p>If <code>mkiocccentry(1)</code> is used and <code>chksubmit(1)</code> fails to validate your submission
-directory, then unless it is a system specific problem, it could be a bug in
-<code>mkiocccentry(1)</code>, <code>chksubmit(1)</code> or possibly <code>jparse</code>, although this is unlikely.
-Nonetheless, if you believe there is a bug, you may report it as explained above.</p>
-<p>If you want to know what <code>.auth.json</code> is, see the
-FAQ on “<a href="../faq.html#auth_json">.auth.json</a>”.
-If you want to know what the <code>.info.json</code> file is, see the
-FAQ on “<a href="../faq.html#info_json">.info.json</a>”.
-On the other hand, if you want to know a bit more details about <code>chksubmit(1)</code>, see the
-FAQ about “<a href="../faq.html#chksubmit">chksubmit</a>”.</p>
-<p><code>chksubmit</code> uses the <code>jparse</code> library. See the
-<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/README.md">jparse
-README.md</a>
-in the <a href="https://github.com/ioccc-src/mkiocccentry/tree/master/jparse">mkiocccentry GitHub repo subdirectory
-jparse</a> as well as
-the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jparse_library_README.md">jparse library README.md
-file</a>
-in the <a href="https://github.com/ioccc-src/mkiocccentry/tree/master/jparse">mkiocccentry GitHub repo subdirectory
-jparse</a>, for more
-details.</p>
-<p>The <code>jparse</code> parser, library and tools were co-developed by <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone
-Ferguson</a> and <a href="http://www.isthe.com/chongo/index.html">Landon Curt
-Noll</a> in 2022-2025 and come from the
-<a href="https://github.com/xexyl/jparse">jparse repo</a>. However, the <strong>mkiocccentry
-tools use a <em>clone</em></strong> of the <a href="https://github.com/xexyl/jparse">jparse repo</a> <strong>at
-a <em>specific</em> release</strong>. Thus the <code>mkiocccentry</code> will at times be behind the
-<a href="https://github.com/xexyl/jparse">jparse repo</a>!</p>
-<p>You do <strong>NOT need to install</strong> <code>jparse</code> from the <a href="https://github.com/xexyl/jparse">jparse
-repo</a>! The <code>mkiocccentry</code> tools link in the
-static library from <code>mkiocccentry</code>’s <em>clone</em>.</p>
-<p>The <code>mkiocccentry</code> toolkit <em>also</em> has a clone of <em>both</em> the <a href="https://github.com/lcn2/dbg">dbg
-library</a> and the
-<a href="https://github.com/lcn2/dyn_array">dyn_array library</a>; the <a href="https://github.com/lcn2/dyn_array">dyn_array
-library</a> uses the <a href="https://github.com/lcn2/dbg">dbg
-library</a> and the <a href="https://github.com/xexyl/jparse">jparse
-library</a> uses both libraries but unlike in the
-<a href="https://github.com/xexyl/jparse">jparse repo</a>, the libraries do not need to be
-installed separately, in order to use the tools in <code>mkiocccentry</code>.</p>
-<p>In other words, <code>mkiocccentry</code> <strong>contains everything</strong> you need, and <em>even if you
-do install</em> the libraries from their respective repos, it/they will <strong>not be
-used</strong> when compiling the <code>mkiocccentry</code> tools. This is important to
-make sure that you’re using the correct versions, which is also verified by
-<code>chksubmit</code> (in the JSON files created by <code>mkiocccentry(1)</code>). See
-<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
-<p class="leftbar">
-We <strong>HIGHLY</strong> recommend you install the <code>mkiocccentry</code> toolkit, however.
-</p>
-<p>Please see the
-FAQ on “<a href="../faq.html#chksubmit">validating your submission directory</a>
-for more details on <code>chksubmit(1)</code>.</p>
-<p>You might also wish to see the
-FAQ on “<a href="../faq.html#auth_json">.auth.json</a>”
-and the
-FAQ on “<a href="../faq.html#info_json">.info.json</a>”
-for much more information on these files.</p>
-<p>Jump to: <a href="#">top</a></p>
-<h2 id="txzchk"><code>txzchk</code></h2>
-<p><code>txzchk(1)</code> performs a wide number of sanity checks on the xz compressed
-tarball; if any issues are found (‘<code>feathers are stuck in the tarball</code>’ :-) )
-<strong>AND if and <em>ONLY IF</em> you used <code>mkiocccentry(1)</code></strong>, then it is <strong>possibly</strong> a
-bug in one of the tools and you might want to <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the
-mkiocccentry bug report
-page</a>.
-<strong>PLEASE run the <code>bug_report.sh</code> script to help us out here!</strong> You may do this
-by running from the top level directory of the repo <code>make bug_report</code>. See the
-FAQ on “<a href="../faq.html#mkiocccentry_bugs">reporting mkiocccentry bugs</a>”.</p>
-<p>As part of its algorithm, <code>txzchk(1)</code> will run <code>fnamchk(1)</code> on the
-<em>tarball</em> to verify that the <em>filename</em> is valid. See the
-FAQ on “<a href="../faq.html#fnamchk">fnamchk</a>”
-and the <a href="#fnamchk">fnamchk section</a> below for more details on this tool.</p>
-<p>It is beyond the scope of this document to discuss the many tests that
-<code>txzchk(1)</code> performs; if you wish to know, we refer you to the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c">source
-code</a> or the man
-page. You might just find a fun option if you do either of these!</p>
-<p>Of course, as <code>txzchk</code> does not extract the tarball, it is possible that if you
-manually package your submission tarball and/or find and exploit a missing
-check, you could still be violating
-<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p>
-<div id="extra-files">
-<h2 id="including-optional-and-extra-files">Including optional and extra files</h2>
-</div>
-<p class="leftbar">
-The maximum total number of <em>extra files</em> that may be submitted is 31.
-</p>
-<p class="leftbar">
-An <em>extra file</em> is defined as a file that is not <code>prog.c</code>, <code>prog.alt.c</code>,
-<code>try.sh</code>, <code>try.alt.sh</code>, <code>remarks.md</code>, <code>Makefile</code>, <code>.auth.json</code> and <code>.info.json</code>:
-unless it’s not in the top level directory, in which case it <strong>IS</strong> an <em>extra
-file</em>. The non-extra files are considered <em>free files</em>.
-</p>
-<p class="leftbar">
-Of course any dot file that is not <code>.auth.json</code> and <code>.info.json</code> will result in
-a violation of
-<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>,
-regardless of its depth.
-</p>
-<p>If you use an optional filename for something other than their intended use
-in order to get past the file limit, we will consider that an
-abuse of rules.</p>
-<p class="leftbar">
-For information on the <code>try</code> script files see the
-FAQ on the “<a href="../faq.html#try_script">try.sh script system</a>”
-and for more details on alt code (including the <code>try.alt.sh</code> script) see the
-FAQ on “<a href="../faq.html#alt_code">alt code</a>”.
-</p>
-<p class="leftbar">
-If you really <strong>MUST</strong> include more files than the limit allows, then you may do
-so by including as an extra file, a tarball. This does <strong>NOT</strong> have to pass
-<code>txzchk(1)</code> tests; only the submission tarball must pass the <code>txzchk(1)</code> tests.
-</p>
-<p class="leftbar">
-You <strong>MUST</strong> justify including extra files beyond the limit, should you do so.
-Even so this does not mean it will be considered valid.
-</p>
-<p class="leftbar">
-If you use a tarball for a depth beyond the maximum, you <strong>MUST</strong> justify this
-as well. Even so this does not mean it will be considered valid.
-</p>
-<p>If you <strong>DO</strong> include a tarball, and the build process or the program extracts
-said tarball(s), the make <code>clobber</code> rule <strong>MUST</strong> remove the extracted files.</p>
-<p><strong>IMPORTANT REMINDER</strong>: make <strong>SURE</strong> your tarball does <strong>NOT</strong> reveal who you are!
-The <code>mkiocccentry(1)</code> tool creates a v7 format tarball to prevent this. You can
-do the same like:</p>
-<pre><code>    tar --format=v7 -cJf foo.txz directory</code></pre>
-<p>See
-<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>
-and also the
-FAQ on “<a href="../faq.html#max-files">maximum number of files</a>”.</p>
-<p>If you do not follow these points, you
-are at a great risk of violating
-<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
-<p><strong>NOTE</strong>: if you want to include a test-suite that requires a lot of files,
-please suggest this in your <code>remarks.md</code> and if your submission wins it can
-be done. In other words you should NOT use a tarball for a test-suite unless you
-have a very good reason for this (and if you do, make <strong>SURE</strong> you specify why
-in your <code>remarks.md</code> file).</p>
-<p>See also the
-FAQ on “<a href="../faq.html#txzchk">txzchk</a>”.</p>
-<p>Jump to: <a href="#">top</a></p>
-<div id="fnamchk">
-<h2 id="fnamchk1"><code>fnamchk(1)</code></h2>
-</div>
-<p>As an important part of its algorithm, <a href="#txzchk">txzchk(1)</a> directly executes
-<code>fnamchk(1)</code>. If the filename is invalid (or the filename does not match the
-directory name of the tarball) then it is an <strong>error</strong> and you risk violating
-<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>.
-Nevertheless, you can run the tool manually,
-should you wish to.</p>
-<p>For more information on <code>fnamchk</code> and how to manually validate your submission
-tarball filename, see the
-FAQ on “<a href="../faq.html#fnamchk">fnamchk</a>”.</p>
-<p>It is extremely unlikely that <code>fnamchk(1)</code> reporting an invalid filename is a
-bug in <code>fnamchk(1)</code> and as such, ignoring such an issue risks violating
-<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>
-which is a big risk. Of course, using <code>mkiocccentry(1)</code>
-would prevent this from happening as it would not create such a file anyway. If
-<code>mkiocccentry(1)</code> was used it would rather suggest a bug in one of the tools and
-you should <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the mkiocccentry issues
-page</a>.
-See the
-FAQ on “<a href="../faq.html#mkiocccentry_bugs">reporting mkiocccentry bugs</a>”.</p>
-<p>As you can see, the use of <code>mkiocccentry(1)</code> is <strong>HIGHLY RECOMMENDED</strong>, and at
-the risk of stating the obvious, you run <strong>A VERY BIG RISK</strong> of having
-your submission rejected if you package your own tarball, and there are <strong>ANY
-problems</strong>. For instance, if <code>chksubmit(1)</code> found a problem in your <code>.info.json</code>
-file, the <code>mkiocccentry(1)</code> tool would not package it. But if you were to package
-it manually, you would be violating
-<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>.
-But even if
-everything checks out OK you should <strong>NOT</strong> assume that everything <strong>IS</strong> OK.</p>
-<div id="bugs">
-<h1 id="problems-andor-bugs-in-the-mkiocccentry-toolkit">Problems and/or bugs in the mkiocccentry toolkit</h1>
-</div>
-<p>Although the tools have been tested extensively, it is nonetheless possible for bugs to
-exist in the code, as all programmers know. In this case, <strong>please</strong> ask for help or report what
-you think is a bug via the <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">bug report issues page in the mkiocccentry
-repo</a>.</p>
-<p>Of course, it is also possible for <code>mkiocccentry(1)</code>, or one or more of the
-tools it executes (or another tool executes), to fail, but <strong>NOT</strong> because of a
-bug. An example problem is if there is not enough memory available or if some
-other library or syscall fails. Nonetheless it might be worth reporting as a
-bug; it is a judgement call: if it’s a bug it’ll be addressed and if it’s not
-that’s OK too!</p>
-<div id="make">
-<div id="makefile">
-<h1 id="makefiles">Makefiles</h1>
-</div>
-</div>
-<p>We <strong>recommend</strong> AND <strong>encourage</strong> you to use the example Makefile,
-as the starting point for your submission’s required <code>Makefile</code>:</p>
-<ul>
-<li><a href="https://github.com/ioccc-src/winner/blob/master/next/Makefile.example">view example Makefile</a></li>
-<li><a href="Makefile.example" download="Makefile">download example Makefile</a></li>
-</ul>
-<p>Feel free to modify the <code>Makefile</code> to suit your obfuscation
-needs.</p>
-<p><strong>Please</strong> add a space between the <code>=</code> and the value of variables, in the
-<code>Makefile</code>, making sure that the <code>=</code> comes immediately after the name. See the
-example <code>Makefile</code> for examples.</p>
-<p class="leftbar">
-This helps us fit the Makefile into a winning entry, should your submission win.
-</p>
-<p>The rest of this section and its subsections will assume that you are using some
-variant of the example <code>Makefile</code>, again renamed as <code>Makefile</code>.</p>
-<p>We suggest that you compile your submission with a commonly available
-<code>-std=gnu17</code> (ISO C 2017 with GNU extensions) C compiler, via <code>clang(1)</code>
-and/or <code>gcc(1)</code>.</p>
-<div id="cflags">
-<div id="flags">
-<h2 id="default-compiler-flags">Default compiler flags</h2>
-</div>
-</div>
-<p>Unless you <strong>clearly state</strong> otherwise in your <code>remarks.md</code> file, <strong>AND</strong> put in
-your submission’s <code>Makefile</code>, we <strong>will</strong> compile using <code>-std=gnu17 -O3</code>!</p>
-<p>It <strong>is OK</strong> if you need to require your submission to <strong>NOT be</strong> compiled
-using the default <code>-std=gnu17 -O3</code> settings. Simply <strong>explain why</strong>
-your submission should NOT be compiled using <code>-std=gnu17 -O3</code> in
-your <code>remarks.md</code> file, <strong>AND</strong> adjust your <code>Makefile</code> accordingly.</p>
-<p class="leftbar">
-You really should <strong>NOT</strong> redefine <code>CC</code> because doing so makes it less portable. &lt;– <strong>Hint!</strong>
-</p>
-<p>One reason that you might have to change the flags, is that the optimiser is
-known to break some programs, but there are certainly other possible valid
-reasons. Again, just update the <code>Makefile</code> and explain it in your <code>remarks.md</code>.
-See the <a href="#optimiser">optimiser section</a> for details for changing optimiser
-flags.</p>
-<p>For more fun when it comes to optimisers breaking code, see
-<a href="../1986/marshall/compilers.html">1986/marshall/compilers.html</a>.</p>
-<div id="compilers">
-<h2 id="default-compiler">Default compiler</h2>
-</div>
-<p><strong>IMPORTANT NOTE</strong>: The use of <code>-std=gnu17</code> does <strong>NOT</strong> imply the use of the <code>gcc</code>
-compiler! We often start by compiling using the <strong>clang</strong> C compiler instead.</p>
-<p><strong>PLEASE NOTE</strong>: in macOS, the compiler <code>gcc</code> found at <code>/usr/bin/gcc</code> is
-in truth the <code>clang</code> compiler, as <code>/usr/bin/gcc --version</code> will show!</p>
-<div id="cstd">
-<div id="standard">
-<h2 id="c-standard">C standard</h2>
-</div>
-</div>
-<p>You may change the standard under which your submission is compiled
-by modifying the <code>CSTD</code> Makefile variable. For example, to use <code>c99</code> instead:</p>
-<pre><code>    CSTD= -std=c99</code></pre>
-<div id="opt">
-<div id="optimization">
-<div id="optimisation">
-<div id="optimizer">
-<div id="optimiser">
-<h2 id="default-optimisation-level">Default optimisation level</h2>
-</div>
-</div>
-</div>
-</div>
-</div>
-<p>You may change the level of optimization and compiler debug level
-that your submission is compiled with, by modifying the <code>OPT</code> Makefile variable.
-For example, to compile without optimization, and to include debug symbols:</p>
-<pre><code>    OPT= -O0 -g3</code></pre>
-<div id="warnings">
-<div id="cwarn">
-<h2 id="compiler-warnings">Compiler warnings</h2>
-</div>
-</div>
-<p>The default warning flags are set via the <code>CWARN</code> variable, as shown in the
-example <code>Makefile</code>:</p>
-<pre><code>    # Common C compiler warning flags
-    #
-    CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN}</code></pre>
-<p>For details on <code>CSILENCE</code> and <code>CUNKNOWN</code>, see the <a href="#disabling-warnings">section on disabling
-warnings</a>.</p>
-<div id="weverything">
-<h3 id="the--weverything-option">The <code>-Weverything</code> option</h3>
-</div>
-<p>For compilers, such as <code>clang</code>, that have the <code>-Weverything</code> option,
-while you may wish to try it, you should read our
-FAQ on “<a href="../faq.html#weverything">clang -Weverything</a>”.
-We do <strong>NOT</strong> recommend that you put
-the use of <code>-Weverything</code> into your submission’s <code>Makefile</code> for the reasons
-cited there. This goes even if your version does not trigger a warning as some
-other version might!</p>
-<p>On the other hand, if <code>${CC}</code> has “<code>clang</code>” in the name, the example <code>Makefile</code> will
-automatically enable <code>-Weverything</code>, so you might have to use <code>-Wno-foo</code>
-options anyway, as detailed below. See the
-FAQ on “<a href="../faq.html#weverything">-Weverything</a>”
-for more details.</p>
-<p>If “<code>clang</code>” is NOT in <code>${CC}</code>, the <code>CWARN</code> variable will not be further
-modified.</p>
-<p>There is no real penalty for compiler warnings. Sometimes
-compiler warnings cannot be helped: especially in the case of
-obfuscated C. :-) So if you cannot easily get rid of a compiler
-warning, try not to fret too much.</p>
-<p>We <strong>LIKE</strong> code that has a minimum of warnings, especially under the
-more strict <code>-Wall -Wextra -pedantic</code> mode:</p>
-<pre><code>    CWARN= -Wall -Wextra -pedantic</code></pre>
-<p>The two previous guidelines might be thought by some as being somewhat
-contradictory. Isn’t life, and isn’t trying to satisfy “contradictory customer
-requirements” all too often like that? :-) Try to minimize warnings if you
-can.</p>
-<p>If you manage to produce very few warnings, or perhaps no warnings at
-all under the <code>-Wall -Wextra -pedantic</code> mode, then by all means brag about it in
-your <code>remarks.md</code> file <strong>AND BE SURE TO TELL US</strong> the OS, OS version, compiler
-and compiler version in which you observed this occurring (in case our OS and
-compiler produces a different result: so your submission won’t be penalized for
-not meeting your claims).</p>
-<p>On the other hand, some warnings cannot be disabled and are enabled by compilers
-without any warning option specified. These are sometimes inevitable in
-obfuscated code and even in some non-obfuscated code, and you should not worry
-about this, though it might be worth pointing out.</p>
-<p>For instance, some compilers like to warn about use of pointers as arrays, which seems to
-be dubious, as it obviously can’t (always) be avoided, being a big part of C, so
-you should not worry about this either; this is the warning
-<code>-Wunsafe-buffer-usage</code> and the way to disable it is <code>-Wno-unsafe-buffer-usage</code>.
-See also the
-FAQ on “<a href="../faq.html#forced_warnings">forced warnings</a>”
-and the
-FAQ on “<a href="../faq.html#weverything">-Weverything</a>”.</p>
-<h2 id="disabling-warnings">Disabling warnings</h2>
-<p class="leftbar">
-If you do have to disable warnings due to <code>-Weverything</code> automatically being
-included, you might wish to state this fact in your <code>remarks.md</code> file.
-And even without <code>-Weverything</code> there can be warnings, as noted above.
-</p>
-<p>If your submission issues lots of warnings but is otherwise
-marvelously obfuscated in multiple levels, don’t worry about it. Nevertheless,
-be sure that the warnings do not constitute a potential “<strong>show stopper</strong>”
-compiler problem. Be sure that compilers such as both <code>gcc</code> and <code>clang</code> won’t
-produce a compiler <strong>error</strong> and refuse to compile your code: unless for some
-reason that is what you intend to happen in which case document that too in your
-<code>remarks.md</code> file. :-)</p>
-<p>All other things being equal, a program that must turn off fewer
-warnings will be considered better, for certain values of better.</p>
-<p>To turn off a compiler warning, in your submission’s <code>Makefile</code>,
-try something such as:</p>
-<pre><code>    CSILENCE= -Wno-some-thing -Wno-another-thing</code></pre>
-<p class="leftbar">
-For instance:
-</p>
-<pre><code>    CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation</code></pre>
-<div id="macros">
-<h2 id="defining-macros-in-the-makefile">Defining macros in the Makefile</h2>
-</div>
-<p>If you need to define something on the compile line, use
-the <code>CDEFINE</code> Makefile variable. For example:</p>
-<pre><code>    CDEFINE= -Dfoo -Dbar=baz</code></pre>
-<p><strong>NOTE</strong>: just because we offer a default way to use the <code>-D</code> option, we still
-do not like excess use of <code>-D</code> to get past size limits, especially since you
-could use <code>#define</code> in your code instead.</p>
-<div id="include">
-<h2 id="include-files-in-the-makefile">Include files in the Makefile</h2>
-</div>
-<p>If you need to include a file (as in <code>#include</code>) on the command line, use the
-<code>CINCLUDE</code> Makefile variable. For example:</p>
-<pre><code>    CINCLUDE= -include stdio.h</code></pre>
-<div id="magic">
-<h2 id="magic-in-the-makefile">Magic in the Makefile</h2>
-</div>
-<p>If you need to add other “<strong>magic</strong>” flags to your compile line,
-use the <code>COTHER</code> Makefile variable. For example:</p>
-<pre><code>    COTHER= -fno-math-errno</code></pre>
-<p><strong>NOTE</strong>: <strong>We only recommend using “<em>magic</em>” flags if <em>BOTH</em> <code>gcc</code>
-<em>and</em> <code>clang</code></strong> support it.</p>
-<p>Again, please note that in macOS, <code>/usr/bin/gcc</code> is actually <code>clang</code>!</p>
-<div id="clobber">
-<h2 id="the-clobber-rule">The clobber rule</h2>
-</div>
-<p>When <code>make clobber</code> is invoked, we request that submissions be restored
-to their original submission state. For example, any temporary files
-(<strong>including</strong> the compiled program(s)) created during the build process, or
-during execution should be removed by the <code>clobber</code> rule. In other words, the
-only things that should be in the directory after running <code>make clobber</code> is what
-is in your submission tarball itself.</p>
-<p>While people are free to manage their submission under <code>git(1)</code> or even use a
-GitHub repo, dot-files and dot-directories such as <code>.git</code> are not allowed in a
-submission.</p>
-<p>The <code>mkiocccentry(1)</code> tool will ignore dot-files and dot-directories (such as
-<code>.vimrc</code>, <code>.bashrc</code>, <code>.git</code> and <code>.github</code>) and not put them in the submission’s
-compressed tarball. So while you may use such files and
-directories to help develop your submission, they won’t be included when you run
-the <code>mkiocccentry(1)</code> tool.</p>
-<p>Even if you did manage to get dot files or dot directories in the tarball
-somehow, <code>txzchk(1)</code> will flag it as an error. When the judges run <code>txzchk(1)</code>
-on the uploaded submission compressed tarball, if anything is wrong, for
-instance if you “sneak in” any dot files or dot directories, the submission
-<strong>WILL BE REJECTED</strong> for violating
-<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
-<p>You may use whatever tools you need to develop your submission, including the
-use of <code>git(1)</code> or <code>gh(1)</code>, just be sure that your submission code and your
-submission Makefile don’t depend on such tools.</p>
-<p>Of course if you do use GitHub to work on your submission, you might want to
-make the repo private so you don’t reveal who you are. :-)</p>
-<p class="leftbar">
-In other words, make <strong>SURE</strong> you keep anonymous who submitted the code!
-</p>
-<p class="leftbar">
-Please do <strong>NOT</strong> use these tools to help with the
-<code>clobber</code> rule! For instance, do <strong>NOT</strong> use <code>git clean</code>! Not only does this
-depend on the user having <code>git(1)</code> but it also does not account for the
-submission tarballs. Even worse is when someone does have it in a <code>git(1)</code> repo
-it will remove files that are not under <code>git(1)</code> control! Instead, see the
-<code>clobber</code> rule in the example Makefile to see how to manage this.
-</p>
-<p>In other words, for <code>make clobber</code>, do something like:</p>
-<pre><code>    clobber:
-            ${RM} -f foo bar baz</code></pre>
-<p>and <strong>NOT</strong> something like this:</p>
-<pre><code>    # do NOT do this!
-    clobber:
-            -git clean -f   # WRONG !!!</code></pre>
-<p>And do <strong>NOT</strong> use <code>git</code> for any other <code>Makefile</code> rule either.</p>
-<p><strong>NOTE</strong>: <code>mkiocccentry(1)</code> will directly run <code>make clobber</code> in the submission
-directory. And although it is not an error if this fails, if it fails because the
-Makefile does not have a clobber rule, it will be flagged by <code>mkiocccentry(1)</code>
-(you may ignore this but it does put you at a risk of violating the rules).</p>
-<p>Jump to: <a href="#">top</a></p>
-<div id="likes">
-<div id="dislikes">
-<h1 id="our-likes-and-dislikes">OUR LIKES AND DISLIKES:</h1>
-</div>
-</div>
-<p>We <strong>VERY MUCH LIKE</strong> submissions that use an edited variant of the
-example Makefile, as described and linked to in the <a href="#makefile">Makefile section</a>,
-renamed as <code>Makefile</code> of course. This makes it easier for the <a href="../judges.html">IOCCC judges</a>
-to test your submission. And if your submissions wins, it makes it easier to integrate it into
-the <a href="https://www.ioccc.org/index.html">Official IOCCC winner website</a>.</p>
-<p>We <strong>VERY MUCH LIKE</strong> submissions that have some educational value. This does <strong>NOT</strong> mean
-that your submission should not be obfuscated but rather that the IOCCC has moved away from
-the idea of “spoilers”. You should not encrypt or rot13 content in your <code>remarks.md</code> file.</p>
-<p>It is <strong>VERY MUCH</strong> appreciated if your remarks have some educational
-value. And although educational value is not required, it is an
-<strong>EXCELLENT</strong> bonus.</p>
-<p>We <strong>LIKE</strong> submissions that use an edited version of the
-<code>try.sh</code> example script (and if you have alternate code,
-the same applies with the <code>try.alt.sh</code> script):</p>
-<ul>
-<li><p><a href="https://github.com/ioccc-src/winner/blob/master/next/try.sh">view example try.sh</a></p></li>
-<li><p><a href="try.sh">download example try.sh</a></p></li>
-<li><p><a href="https://github.com/ioccc-src/winner/blob/master/next/try.alt.sh">view example try.alt.sh</a></p></li>
-<li><p><a href="try.alt.sh">download example try.alt.sh</a></p></li>
-</ul>
-<p>Of course, it is quite possible that only one invocation is
-possible, so it is not necessarily detrimental to your submission if you do not
-include one, though we do like interesting and creative uses of submissions. See
-also the
-FAQ on “<a href="../faq.html#try_scripts">submitting try.sh and try.alt.sh scripts</a>”.</p>
-<p class="leftbar">
-Even if it only has one invocation we still <strong>LIKE</strong> the try scripts.
-</p>
-<p class="leftbar">
-If you do include a <code>try.sh</code> then <strong>PLEASE</strong> remove the <code>try</code> rule in the
-Makefile.
-</p>
-<p class="leftbar">
-If you do include a <code>try.alt.sh</code> then <strong>PLEASE</strong> remove the <code>try.alt</code> rule in
-the Makefile.
-</p>
-<p class="leftbar">
-If you don’t have a prog.alt.c, then <strong>PLEASE</strong> remove the <code>try.alt</code> rule as
-well.
-</p>
-<p>Doing masses of <code>#define</code>s to obscure the source has become ‘old’. We
-tend to ‘see thru’ masses of <code>#define</code>s due to our pre-processor tests
-that we apply. Simply abusing <code>#define</code>s or <code>-Dfoo=bar</code> won’t go as far
-as a program that is more well rounded in confusion.</p>
-<p><strong>Many</strong> C compilers <strong>DISLIKE</strong> the following code, and so do we:</p>
-<pre><code>    #define d define
-    #d foo             /* &lt;-- don&#39;t expect this to turn into #define foo */</code></pre>
-<p>In other words, it is a compilation error, and in order to get older
-IOCCC winning entries that did this to compile, we had to update them to not do this.</p>
-<p>When declaring local or global variables, you should declare the type:</p>
-<pre><code>    int this_is_fine;
-    this_is_not;       /* &lt;-- Try to avoid implicit type declarations */</code></pre>
-<p>We tend to <strong>like <em>less</em></strong> a submission that requires either
-<code>gcc</code> <strong>OR</strong> <code>clang</code>. <strong>We <em>prefer</em> submissions</strong> that can compile
-under <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>. <strong>Hint!</strong></p>
-<p>We <strong>RECOMMEND</strong> that the compiler flags you use in your
-submission’s <code>Makefile</code> are supported by <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>.</p>
-<p>We <strong>DISLIKE</strong> the use of obscure compiler flags, especially
-if <code>gcc</code> and/or <code>clang</code> do not support it. We <strong>suggest</strong>
-that you not use any really obscure compiler flags if you can help it.</p>
-<p>One side effect of the above is that you cannot assume the use
-of nested functions such as:</p>
-<pre><code>     int main() {
-|        void please_dont_submit_this() {
-|           printf(&quot;The machine that goes BING!!\n&quot;);
-         }
-|        please_dont_submit_this();
-     }</code></pre>
-<p>On 2012 July 20, the <a href="../judges.html">IOCCC judges</a> rescinded the encouragement of
-nested functions. Such constructions, while interesting and sometimes
-amusing, will have to wait until they are required by a C standard that are
-actually implemented in <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>.</p>
-<p>We <strong>DISLIKE</strong> submissions that require the use of <code>-fnested-functions</code>.</p>
-<p>We prefer programs that do not require a fish license: crayons and
-cat detector vans not withstanding.</p>
-<p>If your submission uses functions that have a variable number of
-arguments, <strong>be careful</strong>. Systems implement <code>va_list</code> in a wide variety
-of ways. Because of this, a number of operations using <code>va_list</code> <strong>are
-not portable and <em>must not</em> be used</strong>:</p>
-<ul>
-<li>assigning a non-<code>va_list</code> variable to/from a <code>va_list</code> variable</li>
-<li>casting a non-<code>va_list</code> variable into/from a <code>va_list</code> variable</li>
-<li>passing a <code>va_list</code> variable to a function expecting a non-<code>va_list</code> arg</li>
-<li>passing a non-<code>va_list</code> variable to a function expecting a <code>va_list</code> arg</li>
-<li>performing arithmetic on <code>va_list</code> variables</li>
-<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>.</p>
-<p>We <strong>DISLIKE</strong> the use of <code>varargs.h</code>. Use <code>stdarg.h</code> instead.</p>
-<p>We <strong>DISLIKE</strong> the use of <code>gets(3)</code>. Use <code>fgets(3)</code> instead.</p>
-<p>We tend to <strong>DISLIKE</strong> the blatant use of tarballs in an attempt to simply get
-around the extra file number limit. We realize there may be cases where a
-tarball containing a number of extra files may be needed. Such a need for a
-tarball <strong>MUST</strong> be explained in the <code>remarks.md</code> file.</p>
-<p class="leftbar">
-Using a mass of <code>goto</code>s to obfuscate your code has become ‘old’ and is unlikely
-to make it through the final rounds, if it even gets that far.
-</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 byte.</p>
-<p>The <code>exit(3)</code> function returns <code>void</code>. Some broken systems have <code>exit(3)</code>
-return <code>int</code>; your submission should assume that <code>exit(3)</code> returns a <code>void</code>.</p>
-<p class="leftbar">
-This <em>guideline</em> has a change mark at the very start of this line.
-</p>
-<p>Small programs are best when they are short, obscure and concise.
-While such programs are not as complex as other winners, they do
-serve a useful purpose: they are often the only program that people
-attempt to completely understand. For this reason, we look for
-programs that are compact, and are instructional.</p>
-<p>While those who are used to temperatures found on <a href="https://science.nasa.gov/dwarf-planets/">dwarf
-planets</a>
-(<strong>yes Virginia, dwarf planets <em>ARE</em> planets!</strong>), such as
-<a href="https://science.nasa.gov/dwarf-planets/pluto/">Pluto</a>, might be able to
-explain to the Walrus why our seas are boiling hot, the question of
-whether pigs have wings is likely to remain a debatable point to most.</p>
-<p>One line programs should be short one line programs: say around <strong>80</strong> to <strong>132</strong>
-bytes long. Going well beyond <strong>132</strong> bytes is a bit too long to be called
-a one-liner in our vague opinion.</p>
-<p>We tend to <strong>DISLIKE</strong> programs that:</p>
-<ul>
-<li>are very hardware specific</li>
-<li>are very OS version specific (<code>index(3)</code>/<code>strchr(3)</code> differences are OK, but
-sockets/streams specific code is likely not to be)</li>
-<li>dump core or have compiler warnings (it is OK only if
-you warn us in your <code>remarks.md</code> file)</li>
-<li>won’t compile or run in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
-Specification</a>
-environment</li>
-<li>depend on a utility or application not normally found
-in systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
-Specification</a></li>
-<li>abuse the build file to get around the size limit</li>
-<li>obfuscate by use of ANSI trigraphs</li>
-<li>obfuscate by use of digraphs</li>
-<li>are larger than they need to be</li>
-<li>have more lines than they need to have</li>
-<li>are “blob-ier” (just a pile of unformatted C code) than they need to be</li>
-<li>are rather similar to <strong><a href="../years.html">previous winners</a></strong> :-(</li>
-<li>are <strong>identical</strong> to <strong><a href="https://en.wikipedia.org/wiki/Null_device">previous losers</a></strong> :-)</li>
-<li>that mandate the exclusive use of a specific Integrated Development Environment (IDE)</li>
-</ul>
-<p>In order to encourage submission portability, we <strong>DISLIKE</strong> submissions that
-fail to build unless one is using an IDE. For example, do not
-mandate that one must use Microsoft Visual Studio to compile
-your submission.</p>
-<p>The program must compile and link cleanly in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
-Specification</a>
-environment. Therefore do not assume the system has a
-<a href="https://en.wikipedia.org/wiki/Windows.h">windows.h</a> include file:</p>
-<pre><code>    #include &lt;windows.h&gt;  /* we DISLIKE this */</code></pre>
-<p>Unless you are cramped for space, or unless you are entering the
-‘<strong>Best one liner</strong>’ category, we suggest that you format your program
-in a more creative way than simply forming excessively long lines.</p>
-<p>At least one judge prefers to maintain the use of the
-<a href="https://en.wikipedia.org/wiki/Leap_second">leap-second</a>
-as part of the world’s time standard. If your code prints time
-with seconds, we prefer that your code be capable of printing the
-time of day during a leap-second where the value in seconds
-after the minute mark is <strong>60</strong>.</p>
-<p>The <code>Makefile</code> should not be used to try and get around the size limit. It is
-one thing to make use of a several <code>-D</code>s on the compile line to help out, but it
-is quite another to use many bytes of <code>-D</code>s in order to try and squeeze the
-source under the size limit.</p>
-<p>Your source code, post-pre-processing, should not exceed the size of
-<a href="https://en.wikipedia.org/wiki/Microsoft_Windows">Microsoft Windows</a>. :-)</p>
-<p>Other windows, on the other hand, might be OK: especially where “<strong>X
-marks the spot</strong>”. Yet on the third hand, windows are best when they are
-“unseen” (i.e., not dirty). :-)</p>
-<p>The <a href="../judges.html">IOCCC judges</a>, as a group, have a history giving wide degree of latitude
-to reasonable submissions. And recently they have had as much longitudinal
-variation as it is possible to have on <a href="https://science.nasa.gov/earth/">Earth</a>. :-)</p>
-<p>You should try to restrict commands used in the build file to commands found in
-<a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
-Specification</a>
-environments and systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
-Specification</a>.</p>
-<p>You may compile and use your own programs. If you do, try to build and execute
-from the current directory. This restriction is not a hard and
-absolute one. The intent is to ensure that the building of your
-program is reasonably portable.</p>
-<p>We prefer programs that are portable across a wide variety of UNIX-like
-operating systems (e.g., Linux, GNU Hurd, BSD, UNIX, etc.).</p>
-<blockquote>
-<p>You are in a maze of twisty <em>guidelines</em>, all different.</p>
-</blockquote>
-<p>There are at least zero <a href="../judges.html">IOCCC judges</a> who think that
-<a href="https://en.wikipedia.org/wiki/Fideism">Fideism</a> has little
-or nothing to do with the IOCCC judging process.</p>
-<p>Don’t forget that the building of your program should be done
-<strong>WITHOUT human intervention</strong>. So don’t do things such as:</p>
-<pre><code>    prog: prog.c
-        #echo this next line requires data from standard input
-        cat &gt; prog.c
-        ${CC} prog.c -o prog</code></pre>
-<p>However, you can do something cute such as making your program
-do something dumb (or cute) when it is built ‘automatically’, and
-when it is run with a human involved, do something more clever.
-For example, one could put in their <code>Makefile</code>:</p>
-<pre><code>    prog: prog.c
-        ${CC} prog.c -DNON_HUMAN_COMPILE -o prog
-        @echo &quot;See remarks section about alternate ways to compile&quot;</code></pre>
-<p>and then include special notes in your <code>remarks.md</code> file for
-alternate / human intervention based building.</p>
-<p>We want to get away from source that is simply a compact blob of
-bytes. <strong>REALLY TRY</strong> to be more creative than blob coding. <strong>HINT!</strong></p>
-<p>Please do not use things like <code>gzip(1)</code> to get around the size limit.
-Please try to be much more creative.</p>
-<p>We really <strong>DISLIKE</strong> submissions that make blatant use of including
-large data files to get around the source code size limit.</p>
-<p class="leftbar">
-We do not recommend submitting <a href="https://systemd.io">systemd</a> source code to the IOCCC,
-if nothing else because that code is likely to exceed
-<a href="rules.html#rule-2---size">Rule 2 - Size</a>.
-This isn’t to say that another highly compact and obfuscated
-replacement of <code>init(8)</code> would not be an interesting submission.
-</p>
-<p>Did we remember to indicate that programs that blatantly use
-some complex state machine to do something simple, are boring?
-We think we did. :-)</p>
-<blockquote>
-<p>All generalizations are false, including this one. – <strong>Mark Twain</strong></p>
-</blockquote>
-<p>Given two versions of the same program, one that is a compact blob
-of code, and the other that is formatted more like a typical C
-program, we tend to favor the second version. Of course, a third
-version of the same program that is formatted in an interesting
-and/or obfuscated way, would definitely win over the first two!
-Remember, you can submit more than one submission. See the
-<a href="rules.html">IOCCC rules</a>
-for details (in particular,
-<a href="rules.html#rule-8---submission">Rule 8 - Submission</a>).</p>
-<p>We suggest that you avoid trying for the ‘<strong>smallest self-replicating</strong>’
-source. The smallest, a <a href="../1994/smr/index.html">zero byte entry</a>, won in
-<a href="../years.html#1994">1994</a>.</p>
-<p>Programs that claim to be the smallest C source that does something, really
-better be the smallest such program or they risk being rejected because
-they do not work as documented.</p>
-<p>Please note that the C source below, besides lacking in obfuscation,
-is <strong>NOT</strong> the smallest C source file that when compiled and run, dumps core:</p>
-<pre><code>    main;</code></pre>
-<p>Unless you specify <code>-fwritable-strings</code> (see <code>COTHER</code> in the example
-Makefile, described in the <a href="#makefile">Makefile section</a>), do not assume this
-sort of code will work:</p>
-<pre><code>    char *T = &quot;So many primes, so little time!&quot;;
-    ...
-    T[14] = &#39;;&#39;;    /* modifying a string requires: -fwritable-strings */</code></pre>
-<p>Even so, one should probably not assume that this is universally accepted.</p>
-<p>Initialized char arrays are OK to write over. For instance, this is OK:</p>
-<pre><code>    char b[] = &quot;Is this OK&quot;;
-    b[9] = &#39;k&#39;;     /* modifying an initialized char array is OK */</code></pre>
-<p>There are more than 1 typos in this very sentence.</p>
-<p>X client submissions should be as portable as possible. Submissions that
-adapt to a wide collection of environments will be favored. For
-example, don’t depend on a particular type or size of display.
-Don’t assume the use of a particular browser. Instead assume a
-generic browser that forms to a widely used <a href="https://www.w3.org/standards/">W3C
-standard</a>.
-Don’t assume a particular sound sub-system or video driver is installed
-in the OS. Instead, make use of a well known and widely available open
-source program (one that actually works) to display audio/visual data.</p>
-<p>X client submissions should avoid using X related libraries and
-software that are not in wide spread use.</p>
-<p>As of Red Hat RHEL9.0, the X.org server is deprecated. See the
-FAQ on “<a href="../faq.html#Xorg_deprecated">Xorg deprecation”</a>”
-for more details. This does not mean that a submission using this will
-necessarily be rejected, but it would be better if it can support Wayland in
-some way or another.</p>
-<p>This could be the only <em>guideline</em> that contains the word
-<a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>.</p>
-<p>However, do you know how to play <a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>?
-You do?!? (Except on Tuesday?)</p>
-<p>OK, there are actually 2 <em>guidelines</em> that contain the word
-<a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>,
-unless you count this one, in which case there are 3. :-)</p>
-<p>We <strong>DISLIKE</strong> submissions that use proprietary toolkits such as the <code>M*tif</code>,
-<code>Xv*ew</code>, or <code>OpenL*ok</code> toolkits, since not everyone has them. Use an
-open source toolkit that is widely and freely available instead.</p>
-<p><strong>NOTE</strong>: The previous <em>guideline</em> in this spot has been replaced by this <em>guideline</em>:</p>
-<p>X client submissions should try to not to depend on particular items in
-<code>.Xdefaults</code>. If you must do so, be sure to note the required lines
-in the your <code>remarks.md</code> file. They should also not depend on any
-particular window manager.</p>
-<p>Try to avoid submissions that play music that some people believe is copyrighted
-music.</p>
-<p>While we recognize that UNIX is not a universal operating system, the contest
-does have a bias towards such systems. In an effort to expand the scope of the
-contest, we phrase our bias to favor the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
-Specification</a>.</p>
-<p>You are <strong>well advised</strong> to submit code that conforms to the <a href="https://unix.org/version4/overview.html">Single UNIX
-Specification Version 4</a>.</p>
-<p>To quote the <a href="../judges.html">IOCCC judges</a>:</p>
-<blockquote>
-<p>You very well might not be completely prohibited from failing to not partly
-misunderstand this particular <em>guideline</em>, but of course, we could not possibly
-comment! :-) Nevertheless, you are neither prohibited, nor are you fully
-required to determine that this or the previous sentence is either false and/or
-perhaps misleading. Therefore, it might be wise for you to not fail to 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
-parliament should you have one.</p>
-<p>We <strong>LIKE</strong> programs that:</p>
-<ul>
-<li>are as concise and small as they need to be</li>
-<li>do something at least quasi-interesting</li>
-<li>are portable</li>
-<li>are unique or novel in their obfuscation style</li>
-<li>make use of a <strong>NUMBER OF DIFFERENT TYPES OF OBFUSCATIONS!</strong> <strong>&lt;== HINT!!</strong></li>
-<li>make us laugh and/or throw up :-) (humor really helps!)</li>
-<li>make us want to eat good chocolate</li>
-</ul>
-<p>Some types of programs can’t excel (anti-tm) in some areas. Your
-program doesn’t have to excel in all areas, but doing well in several
-areas really does help.</p>
-<p>You are better off explaining what your submission does in your
-<code>remarks.md</code> file section rather than leaving it obscure for the
-<a href="../judges.html">IOCCC judges</a> as we might miss something and/or be too tired to
-notice.</p>
-<p>Please avoid this specific individual <em>guideline</em>, if it at all possible.</p>
-<p>We freely admit that interesting, creative or humorous comments in
-your <code>remarks.md</code> file help your chances of winning. If you had to
-read so many twisted submissions, you too would enjoy a good laugh or two.
-We think the readers of the contest winners do as well. We do read
-your <code>remarks.md</code> content during the judging process, so it is worth your
-while to write a remarkable <code>remarks.md</code> file.</p>
-<p>We <strong>DISLIKE</strong> C code with trailing control-M’s (<code>\r</code> or <code>\015</code>) that results
-in compilation failures. Some non-UNIX/non-Linux tools such as
-MS Visual C and MS Visual C++ leave trailing control-M’s on lines.
-Users of such tools should strip off such control-M’s before submitting
-their submissions. In some cases tools have a “Save As” option that will
-prevent such trailing control-M’s being added.</p>
-<p>One should restrict libcurses to portable features found on BSD
-or Linux curses.</p>
-<p class="leftbar">
-If you do <code>#include &lt;curses.h&gt;</code> make <strong>CERTAIN</strong> you link in curses (i.e.
-<code>-lcurses</code>) and not ncurses (i.e. <code>-lncurses</code>).
-</p>
-<p><a href="rules.html#rule-13---newlines">Rule 13 - Newlines</a>
-no longer discourages the use of UTF-8
-characters in C code.</p>
-<p>It is a very good idea to, in your <code>remarks.md</code> file, tell us why you
-think your submission is obfuscated. This is particularly true if
-your submission has some very subtle obfuscations that we might
-otherwise overlook. <strong>&lt;&lt;– Hint!</strong></p>
-<p>Anyone can format their code into a dense blob. A really clever
-author will try format their submission using a “normal” formatting style
-such that at first glance (if you squint and don’t look at the details)
-the code might pass for non-obfuscated C. Deceptive comments,
-and misleading formatting, in some cases, may be a plus. On the
-other hand, a misleading code style requires more source bytes.</p>
-<p>If you do elect to use misleading formatting and comments, we
-suggest you remark on this point in your <code>remarks.md</code> where you talk
-about why you think your submission is obfuscated. On the other hand,
-if you are pushing up against the size limits, you may be forced
-into creating a dense blob. Such are the trade-offs that obfuscators face!</p>
-<p>We prefer code that can run on either a 64-bit or 32-bit
-processor. However, it is <strong>UNWISE </strong>to assume it will run on an
-some Intel-like x86 architecture**.</p>
-<p>We believe that Mark Twain’s quote:</p>
-<blockquote>
-<p>Get your facts first, then you can distort them as you please.</p>
-</blockquote>
-<p>… is a good motto for those writing code for the IOCCC.</p>
-<p>The IOCCC size tool source is not an original work, unless you are <a href="../authors.html#Anthony_C_Howe">Anthony C
-Howe</a>, in which case it is original! :-)
-Submitting source code that uses the contents of
-<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">iocccsize.c</a>,
-<em>unless</em> you are <a href="../authors.html#Anthony_C_Howe">Anthony C Howe</a>, might run the
-risk of violating
-<a href="rules.html#rule-7---original-work">Rule 7 - Original Work</a>.</p>
-<p>The IOCCC submission tarball validator source is not an original work,
-unless you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone Ferguson</a>, in
-which case it is original! :-) Submitting source code that uses the contents of
-<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c">txzchk.c</a>,
-<em>unless</em> you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone Ferguson</a>, might
-run the risk of violating
-<a href="rules.html#rule-7---original-work">Rule 7 - Original Work</a>.</p>
-<p>In addition to the above tools, none of the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
-tools</a>, <em>including, <strong>but not
-limited</strong></em> to
-<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/mkiocccentry.c">mkiocccentry</a>,
-<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/chksubmit.c">chksubmit</a>,
-<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/chksubmit.c">chksubmit</a>,
-<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/test_ioccc/fnamchk.c">fnamchk</a>
-and
-<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/location_main.c">location</a>,
-nor the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/README.md">JSON parser and
-library</a>,
-<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jstrencode.c">jstrencode</a>,
-<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jstrdecode.c">jstrdecode</a>
-or any of the other <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse">jparse
-tools</a>
-(see the <a href="https://github.com/xexyl/jparse/">jparse repo</a>), are original works,
-unless you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone Ferguson</a> or
-<a href="http://www.isthe.com/chongo/index.html">Landon Curt Noll</a>, in which case they
-are original! :-) Submitting source code that uses the content of any of these tools or
-library, <em>unless</em> you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone
-Ferguson</a> or <a href="http://www.isthe.com/chongo/index.html">Landon Curt
-Noll</a>, might run the risk of violating
-<a href="rules.html#rule-7---original-work">Rule 7 - Original Work</a>.</p>
-<p>And unless you are <a href="https://en.wikipedia.org/wiki/Landon_Curt_Noll">Landon Curt Noll</a>,
-the code in
-<a href="https://github.com/ioccc-src/mkiocccentry/tree/master/dbg">dbg</a> and
-<a href="https://github.com/ioccc-src/mkiocccentry/tree/master/dyn_array">dyn_array</a> are
-not original works. Submitting source code that uses the contents of those
-libraries, <em>unless</em> you <a href="https://en.wikipedia.org/wiki/Landon_Curt_Noll">Landon Curt Noll</a>,
-might run the risk of violating
-<a href="rules.html#rule-7---original-work">Rule 7 - Original Work</a>.</p>
-<p><a href="rules.html#rule-7---original-work">Rule 7 - Original Work</a>
-does not prohibit you from writing your own
-obfuscated versions of these tools, unless of course you are <a href="http://www.isthe.com/chongo/index.html">Landon Curt
-Noll</a>, in which case you <em>probably</em>
-won’t win since <a href="../judges.html">IOCCC judges</a> should not enter the IOCCC! :-)
-However, <strong><em>if</em></strong> you do write your own version, you <strong><em>might</em></strong> wish to make it do something
-<strong><em>more</em> interesting</strong> than simply implementing the <a href="../index.html">IOCCC</a>
-tools’ algorithms.</p>
-<p>Even so, we do not recommend you try and submit a JSON parser due to
-the fact it will likely exceed
-<a href="rules.html#rule-2---size">Rule 2 - Size</a>
-and because you likely can’t beat <a href="https://github.com/westes/flex">flex</a> and
-<a href="https://www.gnu.org/software/bison/">bison</a> in obfuscation. This isn’t to
-say that <a href="https://github.com/xexyl/jparse/blob/master/json_README.md#so-called-json-spec">the so-called JSON spec</a> is not
-obfuscated, but unless you have some really clever way to compact and
-obfuscate a JSON parser more than <a href="https://github.com/westes/flex">flex</a> and
-<a href="https://www.gnu.org/software/bison/">bison</a> you will likely not win, either
-because of the
-<a href="rules.html#rule-2---size">Rule 2 - Size</a>
-or because it is not
-as obfuscated as the <a href="https://github.com/westes/flex">flex</a> and <a href="https://www.gnu.org/software/bison/">bison</a>
-generated code of
-<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse">jparse</a>.</p>
-<p>While programs that only run in a specific word size are OK, if you have
-to pick, choose a 64-bit word size.</p>
-<p>If the <a href="../judges.html">IOCCC judges</a> are feeling ornery we
-might choose to compile your program for running on an Arduino or
-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>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>ARCH</code> in the example
-Makefile, described in <a href="#makefile">Makefile section</a>). Do not assume a
-processor word size without specifying <code>-arch</code>. For example:</p>
-<pre><code>    ARCH= -m64</code></pre>
-<p>Note, however, that some platforms will not necessarily support some
-architectures. For instance, more recent versions of <code>macOS</code> do <strong>NOT</strong> support
-32-bit!</p>
-<p>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
-submission factors values up to a certain size, you might want to state:</p>
-<blockquote>
-<p>This submission factors values up <code>2305567963945518424753102147331756070</code>.
-Attempting to factor larger values will produce unpredictable results.</p>
-</blockquote>
-<p>The <a href="../judges.html">IOCCC judges</a> might try to factor the value -5, so you want to might state:</p>
-<blockquote>
-<p>This submission factors positive values up
-<code>2305567963945518424753102147331756070</code>. Attempting to factor large values will
-produce unpredictable results.</p>
-</blockquote>
-<p>However the <a href="../judges.html">IOCCC judges</a> might try to also factor 0, so you want to might state:</p>
-<blockquote>
-<p>This submission factors values between 1 and
-<code>2305567963945518424753102147331756070</code>. Attempting to factor values outside
-that range will produce unpredictable results.</p>
-</blockquote>
-<p>Moreover they might try to also factor 3.5 or 0x7, or Fred, so you want to might state:</p>
-<blockquote>
-<p>This submission factors integers between 1 and
-<code>2305567963945518424753102147331756070</code>. Attempting to factor anything else
-will produce unpredictable results.</p>
-</blockquote>
-<p>You submission might be better off catching the attempt to factor bogus values
-and doing something interesting. So you might want to code accordingly and state:</p>
-<blockquote>
-<p>This submission factors integers between 1 and <code>2305567963945518424753102147331756070</code>.
-Attempting to factor anything else will cause the program to insult your pet fish Eric.</p>
-</blockquote>
-<p>The <a href="../judges.html">IOCCC judges</a> might not have a pet fish named Eric, so you might want to state:</p>
-<blockquote>
-<p>This submission factors integers between 1 and
-<code>2305567963945518424753102147331756070</code>. Attempting to factor anything else
-will cause the program to insult your pet fish Eric, or in the case that you
-lack such a pet, will insult the pet that you do not have.</p>
-</blockquote>
-<p>When all other things are equal, a submission with fewer limitations will be judged
-better than a submission with lots of limitations. So you might want to code accordingly
-and state:</p>
-<blockquote>
-<p>This submission attempts to a factor value of any size provided that the
-program is given enough time and memory. If the value is not a proper integer,
-the program might insult a fish named Eric.</p>
-</blockquote>
-<p>Do not fear if you’re not 100% sure of the significance of
-<code>2305567963945518424753102147331756070</code> as it is not of prime importance: or is
-it? :-)</p>
-<p>We <strong>DISLIKE</strong> the use of ASCII tab characters in markdown files, such as in the required <code>remarks.md</code> file.</p>
-<p>We don’t mind the use of ASCII tab characters in your C code. Feel free
-to use ASCII tab characters if that suits your obfuscation needs. If is
-perfectly <strong>OK</strong> to use tab characters elsewhere in your submission, just not in
-markdown files as this tends annoy us when it comes time to
-rendering your markdown content as it complicates the process.</p>
-<p>If you do use ASCII tab characters in your non-markdown files, be
-aware that some people may use a tab stop that is different than the common 8
-character tab stop.</p>
-<p><strong>PLEASE</strong> observe our <a href="../markdown.html">IOCCC markdown guidelines</a>
-when forming your submission’s <code>remarks.md</code> file. And if your submission
-contains additional markdown files, please follow those same guidelines for
-those files. See also
-<a href="rules.html#rule-4---files">Rule 4 - Files</a>,
-and the
-FAQ on “<a href="../faq.html#markdown">markdown</a>”.</p>
-<p>We <strong>LIKE</strong> reading <code>remarks.md</code> files, especially if they contain
-useful, informative, and even humorous content about your submission. Yes, this
-is a <strong>hint</strong>. :-)</p>
-<p>We <strong>RECOMMEND</strong> you put a reasonable amount effort into the content of the
-<code>remarks.md</code> file: it is a required file for a reason. :-)</p>
-<p>Try to be even more creative!</p>
-<p>Jump to: <a href="#">top</a></p>
-<div id="rules_abuse">
-<div id="abusing_rules">
-<h1 id="abusing-the-rules">ABUSING THE RULES:</h1>
+<div id="guideline11">
+<div id="guideline-11---abuse">
+<h1 id="guidelines-for-rule-11---abuse">Guidelines for <a href="rules.html#rule-11---abuse">Rule 11 - Abuse</a></h1>
 </div>
 </div>
+<p>We try to avoid limiting creativity in our <a href="rules.html">IOCCC rules</a> so
+we leave the contest open for creative rule interpretation.</p>
+<p>We do realize that there are holes in the <a href="rules.html">IOCCC rules</a>, and invite
+submitters to attempt to exploit them.</p>
+<p>We sometime award ‘<strong>Best abuse of the rules</strong>’ or ‘<strong>Worst abuse of the rules</strong>’,
+or some variation to a submission that creatively attempts to exploit a holes in the
+<a href="rules.html">IOCCC rules</a>.</p>
+<p>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.</p>
+<p>Or, maybe not. :-)</p>
 <p>Legal abuse of the <a href="rules.html">IOCCC rules</a> is somewhat encouraged. Legal rule abuse
 may involve, but is not limited to, doing things that are technically allowed by
 the <a href="rules.html">IOCCC rules</a> and yet do not fit the spirit of what we intended to be
@@ -1890,222 +632,751 @@ product management and even from customers themselves on an all too regular basi
 This is one of the reasons why the <a href="rules.html">IOCCC rules</a> and
 <a href="guidelines.html">IOCCC guidelines</a> are written in obfuscated form.</p>
 <p>Jump to: <a href="#">top</a></p>
-<div id="judging">
-<h1 id="judging-process">JUDGING PROCESS:</h1>
+<div id="guideline15">
+<div id="guideline-15---building">
+<h1 id="guidelines-for-rule-15---building">Guidelines for <a href="rules.html#rule-15---building">Rule 15 - Building</a></h1>
 </div>
-<p>Submissions are judged by Leonid A. Broukhis and Landon Curt Noll.</p>
-<p>Each submission submitted is given a random string and subdirectory. The
-submission files including, but not limited to <code>prog.c</code>, <code>Makefile</code>,
-<code>remarks.md</code>, <code>.info.json</code>, <code>.auth.json</code> as well as any data files that you
-submit, are all placed under their own directory and stored and judged from this
-directory.</p>
-<p>Any information about the authors is not read by the <a href="../judges.html">IOCCC judges</a> until
-the judging process is complete, and then only from entries that have
-won an award. Because we do not read this information for entries that
-do not win, we do not know who did not win.</p>
-<p>The above process helps keep us biased for/against any one particular
-individual. Therefore you <strong>MUST</strong> refrain from putting any information
-that reveals your identity in your submission.</p>
-<p>Now some people point out that coding and/or writing style might reveal the
-information about the authors. However we consider this to be simply
-circumstantial and outside the scope of the above paragraph.</p>
-<p>Some people, in the past, have attempted to obfuscate their identity by
-including comments of famous Internet personalities such as <a href="http://www.citi.umich.edu/u/honey">Peter
-Honeyman</a>. The <a href="../judges.html">IOCCC judges</a> are on to this trick
-and therefore consider any obfuscated source or data file claiming to be from
-Honeyman to not be from Honeyman. This of course creates an interesting paradox
-known as the “<strong>obfuscated Peter Honeyman paradox</strong>”. Should Peter Honeyman
-actually submit to the IOCCC, he alone is excluded from the above, as we
-will likely believe it’s just another attempt at confusion. This <em>guideline</em> is
-known as the “<strong>Peter Honeyman is exempt</strong>” <em>guideline</em>.</p>
-<p><strong>BTW</strong>: None of the submissions claiming to be from Peter Honeyman have ever
-won an award. So it is theoretically possible that Peter Honeyman
-did submit to the IOCCC in the past. In the past, Peter had denied
-submitting anything to the IOCCC. Perhaps those submissions were
-submitted by one of his students?</p>
-<p>Hopefully we are <strong>VERY CLEAR</strong> on this point! The rules now strongly state:
-<strong>PLEASE <em>DO NOT</em> put a name of an author</strong>, in an obvious way, into your
-source code, <code>remarks.md</code>, data files, etc., the above “<strong>Peter Honeyman is
-exempt</strong>” notwithstanding.</p>
-<p>We seemed to have digressed again … :-) Returning to the judging process:</p>
-<p>We prefer to be kept in the dark as much as you are until the final
-awards are given. We enjoy the surprise of finding out in the end,
-who won and where they are from.</p>
-<p>We attempt to keep all submissions anonymous, unless they win an award.
-Because the main ‘prize’ of winning is being announced, we make all
-attempts to send non-winners into oblivion. We remove all non-winning
-files, and shred all related printouts. By tradition, we do not even
-reveal the number of submissions that we receive.</p>
-<p>During the judging process, a process that spans multiple sessions over
-a few weeks, we post general updates from our <a href="https://fosstodon.org/@ioccc">Mastodon
-account</a>.</p>
-<p><strong>Make sure you reload the feed</strong> every so often <strong>because unless you
-are mentioned you will NOT get a push notification!</strong></p>
+</div>
+<p>You may use git, or services such as <a href="https://www.github.com">GitHub</a>
+to develop and maintain your submission. However, we <strong>DISLIKE</strong>
+submissions that <strong>require</strong> such services in order to build/compile your submission.</p>
+<p>Submissions will be judged in an environment that has no <strong>IDE</strong>.
+Any submission that fails to compile/build because it requires
+an <strong>IDE</strong> will be rejected.</p>
+<p>We will use the <code>make(1)</code> tool, your <code>Makefile</code>, as well as tools found in the
+<a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a>
+environments, and commonly found on systems that reasonably conform to the
+<a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a>
+in the building and compiling of your submission.</p>
 <p>Jump to: <a href="#">top</a></p>
-<div id="rounds">
-<h2 id="judging-rounds">JUDGING ROUNDS:</h2>
+<div id="guideline17">
+<div id="guideline-17---packaging">
+<h1 id="guidelines-for-rule-17---packaging">Guidelines for <a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a></h1>
 </div>
-<p>Judging consists of a number of elimination rounds. During a round,
-the collection of submissions are divided into two roughly equal piles;
-the pile that advances on to the next round, and the pile that does
-not. We also re-examine the submissions that were eliminated in the
-previous round. Thus, a submission gets at least two readings and
-often more than two.</p>
+</div>
+<p>We <strong>STRONGLY</strong> recommend you <strong>do</strong> install the
+<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
+as use of using older versions of the mkiocccentry toolkit to are <strong>HIGHLY LIKELY</strong> to be <strong>REJECTED</strong>!</p>
+<p>If you submit your own JSON files (other than <code>.auth.json</code> and
+<code>.info.json</code>) then they do <strong>NOT</strong> have to be valid JSON.</p>
+<p>However, if you do provide invalid JSON files, <strong>PLEASE</strong>
+document and <strong>clearly explain</strong> this in your <code>remarks.md</code> file.</p>
+<p class="leftbar">
+An <em>extra file</em> is defined as a file that is not <code>prog.c</code>, <code>prog.alt.c</code>,
+<code>try.sh</code>, <code>try.alt.sh</code>, <code>remarks.md</code>, <code>Makefile</code>, <code>.auth.json</code> and <code>.info.json</code>:
+unless it’s not in the top level directory, in which case it <strong>IS</strong> an <em>extra
+file</em>.
+</p>
+<p class="leftbar">
+The non-extra files (<code>prog.c</code>, <code>prog.alt.c</code>,
+<code>try.sh</code>, <code>try.alt.sh</code>, <code>remarks.md</code>, <code>Makefile</code>, <code>.auth.json</code> and <code>.info.json</code>)
+are considered <em>free files</em>, and to not count towards the
+<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>
+limit of <strong>31</strong> <em>extra files</em>.
+</p>
+<p>If you use an optional filename for something other than their intended use
+in order to get past the file limit, we will consider that an abuse of rules.</p>
+<p>Your tarball does <strong>NOT</strong> reveal who you are! For this reason, the tarball
+<strong>MUST</strong> be a <strong>v7 format</strong> tarball.</p>
+<p>You should NOT use a tarball as an <em>extra file</em> for a test-suite unless you
+have a very good reason for this: if you do include a tarball as an <em>extra file</em>,
+then you <strong>MUST</strong> specify why in your <code>remarks.md</code> file.</p>
+<p>If you <strong>DO</strong> include a tarball an <em>extra file</em>, and the build process or the program extracts
+said tarball(s), the make <code>clobber</code> rule <strong>MUST</strong> remove the extracted files.</p>
+<p>Instead of including a large test-suite that requires a lot of files as part of your submission,
+and your submission doesn’t require the test-suite to be available to run,
+then in your <code>remarks.md</code> a URL where such a test-suite may be downloaded from
+and how to use the test-suite to test your submission.</p>
+<p>See FAQ on “<a href="../faq.html#try_scripts">What should I do with the <code>try.sh</code> and <code>try.alt.sh</code> scripts?</a>”.</p>
+<p>See FAQ on “<a href="../faq.html#auth_json">What is a <code>.auth.json</code> file?</a>”.</p>
+<p>See FAQ on “<a href="../faq.html#info_json">What is a <code>.info.json</code> file?</a>”.</p>
+<p>See FAQ on “<a href="../faq.html#chksubmit">How can I validate my submission directory?</a>”.</p>
+<p>See FAQ on “<a href="../faq.html#file_perms">What permissions may my files be and what if I need different permissions?</a>”.</p>
+<p>See FAQ on “<a href="../faq.html#makefile_details">What are the detailed recommendations for a submission Makefile?</a>”.</p>
+<p>See FAQ on “<a href="../faq.html#rule17">What are the details behind Rule 17 - Packaging?</a>”.</p>
 <p>Jump to: <a href="#">top</a></p>
-<div id="readings">
-<h2 id="judging-readings">JUDGING READINGS:</h2>
+<div id="mkiocccentry">
+<div id="mkiocccentry_toolkit">
+<h1 id="guidelines-for-the-mkiocccentry-toolkit">Guidelines for the mkiocccentry toolkit</h1>
 </div>
-<p>A reading consists of a number of actions:</p>
+</div>
+<p>The <a href="https://submit.ioccc.org">IOCCC submit server</a>, and related services
+use the <strong>most recent version</strong> of the
+<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>:
+submissions that package using older versions of the
+<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
+are <strong>LIKELY</strong> to be <strong>REJECTED</strong>!</p>
+<p>You <strong>REALLY SHOULD</strong> use latest <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
+to package your own submission.</p>
+<p>The <code>mkiocccentry(1)</code> tool runs a number of checks by way of these
+<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
+tools:</p>
 <ul>
-<li>Reading <code>prog.c</code>, the C source and reviewing the <code>remarks.md</code> information</li>
-<li>Briefly looking at any supplied data files</li>
-<li>Passing the source thru the C pre-processor skipping over any <code>#include</code>d files</li>
-<li>Performing a number of C beautify/cleanup edits on the source</li>
-<li>Passing the beautified source thru the C pre-processor skipping over any <code>#include</code>d files</li>
-<li>Compiling/building the source</li>
-<li>Running the program</li>
-<li>Doing other things that only <a href="../judges.html">IOCCC judges</a> know about :-)</li>
+<li>iocccsize(1)</li>
+<li>txzchk(1)</li>
+<li>fnamchk(1)</li>
+<li>chksubmit(1)</li>
+<li>chkentry(1)</li>
 </ul>
-<p>In later rounds, other actions are performed including performing
-miscellaneous tests on the source and binary.</p>
-<p>This is the very <strong>guideline</strong> that goes, <strong>BING!</strong></p>
-<p>Okay, technically that was the <em>second</em> <strong>guideline</strong> that goes <strong>BING</strong>, and this
-is the third. :-)</p>
-<p>Until we reduce the stack of submissions down to about 25 submissions,
-submissions are judged on an individual basis. A submission is set aside because it
-does not, in our opinion, meet the standard established by the round.
-When the number of submissions thins to about 25 submissions, we begin to form
-award categories. Submissions begin to compete with each other for awards.
-A submission will often compete in several categories.</p>
-<p>The actual award category list will vary depending on the types of submissions
-we receive. A typical category list might be:</p>
+<p>Do <strong>NOT</strong> use <code>txzchk(1)</code> command line options that are labeled “<strong>for TESTING purposes</strong>”
+in the <code>txzchk(1)</code> man page.</p>
+<p>Do <strong>NOT</strong> use <code>fnamchk(1)</code> command line options that are labeled “<strong>for TESTING purposes</strong>”
+in the <code>fnamchk(1)</code> man page.</p>
+<p>Do <strong>NOT</strong> use <code>chkentry(1)</code> command line options that are labeled “<strong>for the use by the IOCCC judges only</strong>”
+in the <code>chkentry(1)</code> man page.</p>
+<p>To view <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a> man pages,
+while your current directory is the top of the source tree:</p>
+<pre><code>    man soup/man/man1/mkiocccentry.1
+    man soup/man/man1/iocccsize.1
+    man soup/man/man1/txzchk.1
+    man test_ioccc/man/man1/fnamchk.1
+    man soup/man/man1/chksubmit.1
+    man soup/man/man1/chkentry.1</code></pre>
+<p>The above <code>man(1)</code> commands will show the toolkit man pages without having to install them first.</p>
+<p>So that you do not have to repeatedly answer all the <code>mkiocccentry(1)</code> questions,
+use <code>mkiocccentry -a answers ...</code> to create a file containing the answers you first give,
+that will allow you to later use <code>mkiocccentry -i answers ...</code> to reuse those same answers.</p>
+<p>The <code>mkiocccentry -A answers ..</code> does the same thing except that the <strong>answers file will be overwritten</strong>.</p>
+<p>The <code>mkiocccentry -i answers ..</code> will still be required to confirm “<em>Yes/No</em>” questions.</p>
+<p>Use <code>mkiocccentry -Y -i answers ..</code> to force a yes answers with <strong>great caution</strong>
+because it might force a yes answer to something you do <strong>NOT</strong> want.</p>
+<p>To help with not having to repeatedly enter a UUID, put your UUID into a file and use
+<code>mkiocccentry -u uuidfile ..</code>, or use <code>mkiocccentry -U UUID ..</code> to give the <code>UUID</code>
+on the command line.</p>
+<p>If you wish to <strong>test</strong> that your submission passes the <code>mkiocccentry(1)</code> tests
+without having to type in in answers each time, you can use the <code>-d</code> or <code>-s seed</code>
+option to <code>mkiocccentry</code> for the tool to pseudo-randomly create answers for you.
+For example:</p>
+<pre><code>    mkiocccentry -d workdir topdir</code></pre>
+<p>Do <strong>NOT</strong> submit a tarball formed by <code>mkiocccentry -d ..</code>, <strong>NOR</strong> by <code>mkiocccentry -s seed ..</code>!</p>
+<p>The <code>mkiocccentry(1)</code> tool creates an <code>xz(1)</code> compressed <strong>v7 format</strong> tarball using a <code>tar(1)</code>
+command of the form:</p>
+<pre><code>    cd workdir/UUID-slot_num &amp;&amp; tar --format=v7 -cJf submit.UUID-slot_num.timestamp.txz UUID-slot_num</code></pre>
+<p>In many places the <code>mkiocccentry(1)</code> tool will prompt you to verify what you input, allowing you to
+correct details as you go along.</p>
+<p>Pressing the “<em>enter key</em>” <code>mkiocccentry(1)</code> tool prompts will allow you to proceed with a default,
+however make sure the default is the <strong>CORRECT</strong> answer.</p>
+<p>The <code>mkiocccentry(1)</code> tool will use code from <code>iocccsize(1)</code> which detects a number of
+issues (such as <a href="rules.html#rule-2---size">Rule 2 - Size</a>) that you may ignore,
+however ignoring such issues <strong>comes with a significant level of risk!</strong></p>
+<p>Once the tarball is packaged it will
+run <code>txzchk(1)</code>, which will also run <code>fnamchk(1)</code>, as part of its algorithm.</p>
+<p>The use of <code>mkiocccentry -W ...</code> is <strong>highly discouraged</strong> as this may ignore
+warnings about a problem that may cause your submission to be <strong>REJECTED!</strong>”</p>
+<p>If <code>mkiocccentry</code> encounters an <strong>error</strong>, the program will exit and the xz
+compressed tarball <strong>will NOT be formed</strong>: this is a <strong>feature, not a bug</strong>!</p>
+<p>If you encounter a <strong>bug</strong> with the
+<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
+<strong>PLEASE run the <code>bug_report.sh</code> script to help us out here!</strong></p>
+<p>While you don’t have to install the
+<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>,
+then in order to run a tool outside the repo directory
+you will have to specify <code>mkiocccentry(1)</code> command line options to locate required tools
+such as <code>chkentry(1)</code> (<code>mkiocccentry -C chkentry ..</code>), <code>txzchk(1)</code> (<code>mkiocccentry -T txzchk ..</code>),
+and <code>fnamchk(1)</code> (<code>mkiocccentry -F fnamchk ..</code>).</p>
+<p>The <code>mkiocccentry(1)</code> tool will ignore any filename that begins with a “.” (dot).</p>
+<p>The <code>mkiocccentry(1)</code> tool will ignore any directory tree with a directory name that begins with a “.” (dot).</p>
+<p>The <code>mkiocccentry(1)</code> tool will all files that begin with <code>COPYING</code>, <code>COPYRIGHT</code>, and <code>LICENSE</code>, regardless
+of filename case.</p>
+<p>The <code>mkiocccentry(1)</code> tool will any of the following files if they are found directly under
+the top level directory (<code>topdir</code>):</p>
 <ul>
-<li><strong>best small one line program</strong> (see above about one line programs)</li>
-<li><strong>best small program</strong></li>
-<li><strong>strangest/most creative source layout</strong></li>
-<li><strong>most useful obfuscated program</strong></li>
-<li><strong>best game that is obfuscated</strong></li>
-<li><strong>most creatively obfuscated program</strong></li>
-<li><strong>most deceptive C code</strong> (code with deceptive comments and source code)</li>
-<li><strong>best X program</strong> (see <a href="#likes">OUR LIKES AND DISLIKES</a> and the FAQ on “<a href="../faq.html#Xorg_deprecated">Xorg
-being deprecated</a>”)</li>
-<li><strong>best abuse of ISO C or ANSI C standard</strong> (see above about compilers)</li>
-<li><strong>best abuse of the C preprocessor</strong></li>
-<li><strong>worst/best abuse of the rules</strong> (or some variation)</li>
-<li>(anything else so strange that it deserves an award)</li>
+<li>README.md</li>
+<li>index.html</li>
+<li>prog</li>
+<li>prog.alt</li>
+<li>prog.alt.o</li>
+<li>prog.orig.c</li>
+<li>filenames matching the <code>[0-9][0-9][0-9][0-9]_*.tar.bz2</code> file glob</li>
 </ul>
-<p>We do not limit ourselves to this list. For example, a few submissions are so
-good/bad that they are declared winners at the start of the final round.
-We will invent awards categories for them, if necessary.</p>
-<p>In the final round process, we perform the difficult tasks of
-reducing the remaining submissions (typically about 25) down to to about
-half that number: declaring those remaining to be winners.</p>
-<p>Often we are confident that the submissions that make it into
-the final round are definitely better than the ones that do not
-make it. The selection of the winners out of the final round, is
-less clear cut, however.</p>
-<p>Sometimes a final round submission is good enough to win, but is beat out by a
-similar, but slightly better submission. For this reason, it is sometimes
-worthwhile to resubmit an improved version of a submission that failed to win in
-a previous year, the next year. This assumes, of course, that the submission is
-worth improving in the first place!</p>
-<p>Over the years, more than one <a href="../judges.html">IOCCC judge</a>
-has been known to <strong>bribe</strong> another <a href="../judges.html">IOCCC judge</a> into voting for a
-winning submissions by offering a bit of high quality chocolate, or
-other fun item.</p>
+<p>The files listed in the above list are allowed to exist in sub-directories: just <strong>NOT</strong> directly under
+the top level directory (<code>topdir</code>).</p>
+<p>The <code>mkiocccentry(1)</code> tool evaluates all filenames and directory names in a case independent way:
+this <code>FOO</code>, <code>Foo</code>, and <code>foo</code> are treated as the <strong>SAME</strong> file even if your filesystem doesn’t.</p>
+<p>Having two or more filenames that differ only by case <strong>WILL</strong> lead to problems because of the previous statement.</p>
+<p>When the <code>mkiocccentry(1)</code> tool ignores a file, that file is <strong>NOT</strong> included as part of your submission.</p>
+<p>When the <code>mkiocccentry(1)</code> tool ignores a directory, that directory,
+and everything under that directory is <strong>NOT</strong> included as part of
+your submission.</p>
+<p>The <code>mkiocccentry(1)</code> tool will ignore all symlinks.</p>
+<p>Creating a directory directly under the top level directory (<code>topdir</code>)
+that is normally considered to be a regular file, such as a directory
+named <code>Makefile</code>, <code>prog.alt.c</code>, <code>prog.c</code>, <code>remarks.md</code>, <code>try.alt.sh</code>,
+or <code>try.sh</code> is <strong>NOT</strong> a good idea and will likely cause the
+<code>mkiocccentry(1)</code> tool to abort with a <strong>fatal error</strong>.</p>
+<p>The required <code>Makefile</code>, <code>remarks.md</code> file may <strong>NOT</strong> be an empty file.</p>
+<p>If the optional file <code>try.alt.sh</code>, or <code>try.sh</code> exits and is an empty file,
+the <code>mkiocccentry(1)</code> tool to abort with a <strong>fatal error</strong>.</p>
+<p>If the <code>mkiocccentry(1)</code> tool encounters anything that isn’t a file, isn’t a directory,
+and isn’t a symlink (which the tool ignores), the <code>mkiocccentry(1)</code> tool to abort with a <strong>fatal error</strong>.</p>
+<p>See FAQ on “<a href="../faq.html#mkiocccentry_bugs">How do I report bugs in an <code>mkiocccentry</code> tool?</a>”.</p>
+<p>See <a href="rules.html#rule-11---abuse">Rule 11 - Abuse</a> for warnings about ignoring <code>mkiocccentry(1)</code> tool warnings.</p>
+<p>See FAQ on “<a href="../faq.html#fnamchk">What is the <code>fnamchk</code> tool?</a>”.</p>
+<p>See FAQ on “<a href="../faq.html#about_mkiocccentry">What is mkiocccentry in simple terms?</a>”.</p>
+<p>See FAQ on “<a href="../faq.html#mkiocccentry">What is the mkiocccentry tool, how do I obtain it and how do I use it</a>”.</p>
+<p>Jump to: <a href="#">top</a></p>
+<div id="general">
+<h1 id="general-overall-guidelines">General Overall Guidelines</h1>
+</div>
+<p>These <a href="guidelines.html">guideline</a> are <strong>hints</strong> and <strong>suggestions</strong>, <strong>NOT</strong> <a href="rules.html">IOCCC rules</a>.</p>
+<p>While submissions that violate <a href="guidelines.html">guideline</a> are allowed,
+submissions that remain within the <a href="guidelines.html">IOCCC guidelines</a> are preferred.</p>
+<p>You are encouraged to review the following <a href="../faq.html">FAQs</a>:</p>
+<ul>
+<li><p><a href="../quick-start.html#enter">How to enter the IOCCC</a></p></li>
+<li><p><a href="../faq.html#mkiocccentry">Obtaining and compiling the most recent mkiocccentry toolkit</a></p></li>
+<li><p><a href="../next/submit.html">How to upload your submission</a></p></li>
+</ul>
+<p>While the contest is <strong><a href="../faq.html#open">open</a></strong>, you may modify your
+previously uploaded submission by rebuilding your submission with the
+<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>,
+and then re-uploading it to <strong>the same slot number</strong> on the
+<a href="https://submit.ioccc.org">submit server</a>.</p>
+<p>The <strong>official locale</strong> of the <strong>IOCCC</strong> is <strong>C</strong>.</p>
+<p>You are <strong>encouraged</strong> to examine the <a href="../years.html">winners of previous contests</a>.</p>
+<p>Because <a href="rules.html">rules</a> change from year to year, some <a href="../years.html">winning entries</a>
+of the past may be rejected this year.</p>
+<p>What was <em>was</em> unique and novel one year <em>might be ‘old’ the next year</em>.</p>
+<p>A submission is usually examined in a number of ways. We typically apply
+a number of tests to a submission:</p>
+<ul>
+<li>look at the original source</li>
+<li>C pre-process the source ignoring <code>#include</code> lines</li>
+<li>C pre-process the source ignoring <code>#define</code> <em>and</em> <code>#include</code> lines</li>
+<li>run it through a C beautifier (such as <code>clang-format(1)</code>)</li>
+<li>examine the algorithm</li>
+<li>compile it (with flags to enable all warnings)</li>
+<li>execute it</li>
+</ul>
+<p>You should consider how your submission looks in each of the above tests.
+You should ask yourself if your submission remains obscure after it has been
+‘<em>cleaned up</em>’ by the C pre-processor and a C beautifier.</p>
+<p>Your submission need not pass all of the above tests as in certain cases,
+a test is not important.</p>
+<p>Submissions that compete for the
+‘<strong>strangest/most creative source layout</strong>’ need not do as well as
+others in terms of their algorithm.</p>
+<p>Given two submissions, we are more inclined to pick the submission that
+does something interesting when it’s executed.</p>
+<p><strong>IMPORTANT:</strong> Be sure that <strong>your submission works</strong> as documented in your <code>remarks.md</code> file.</p>
+<p>We sometimes make an effort to debug a submission
+that has a slight problem, particularly in or near the final round.
+On the other hand, we have seen some otherwise excellent submissions
+fall down because they didn’t work as documented.</p>
+<p>If you submission has bugs and/or mis-features, you are <strong>MUCH BETTER</strong> off
+documenting such bugs and/or mis-features in your <code>remarks.md</code> file.</p>
+<p>Consider an example of a <a href="https://en.wikipedia.org/wiki/Prime_number">prime number</a>
+printing program that claims that 16 is a prime number.
+Noting such a bug in your <code>remarks.md</code> file could save your submission:</p>
+<blockquote>
+<p>“<em>this submission sometimes prints the 4th power of a prime by mistake</em>”</p>
+</blockquote>
+<p>Sometimes a strange bug or (mis-)feature can even help the submission! Of course, a correctly
+working submission might be better.</p>
+<p>We tend to look down on a
+<a href="https://en.wikipedia.org/wiki/Prime_number">prime number</a>
+printer that claims that 16 is a prime number.
+Clever people will note that 16 might be prime under certain conditions. ;-)
+Wise people, when submitting something clever
+will <strong>fully explain such cleverness</strong> in their submission’s <code>remarks.md</code> file.</p>
+<p>People who are considering to just use some complex mathematical
+function or state machine to spell out something such as “<em>hello,
+world!</em>” <strong>really really, <em>and we do mean REALLY</em>, do need to be more creative</strong>.</p>
+<p>Consider using misleading or subtle tricks layered on top of or under
+an appropriate level of obfuscation.</p>
+<p>A clean looking program with
+misleading comments and variable names might be a <strong>VERY GOOD START</strong>
+to a great submission!</p>
+<p>Jump to: <a href="#">top</a></p>
+<div id="likes">
+<div id="dislikes">
+<h1 id="our-likes-and-dislikes">OUR LIKES AND DISLIKES:</h1>
+</div>
+</div>
+<p>We <strong>VERY MUCH LIKE</strong> submissions that use an edited variant of the
+example Makefile, as described and linked to in the <a href="#makefile">Makefile section</a>,
+renamed as <code>Makefile</code> of course. This makes it easier for the <a href="../judges.html">IOCCC judges</a>
+to test your submission. And if your submissions wins, it makes it easier to integrate it into
+the <a href="https://www.ioccc.org/index.html">Official IOCCC winner website</a>.</p>
+<p>We <strong>VERY MUCH LIKE</strong> submissions that have some educational value. This does <strong>NOT</strong> mean
+that your submission should not be obfuscated but rather that the IOCCC has moved away from
+the idea of “spoilers”. You should not encrypt or rot13 content in your <code>remarks.md</code> file.</p>
+<p>It is <strong>VERY MUCH</strong> appreciated if your remarks have some educational
+value. And although educational value is not required, it is an
+<strong>EXCELLENT</strong> bonus.</p>
+<p>We <strong>LIKE</strong> submissions that use an edited version of the
+<code>try.sh</code> example script (and if you have alternate code,
+the same applies with the <code>try.alt.sh</code> script):</p>
+<ul>
+<li><p><a href="https://github.com/ioccc-src/winner/blob/master/next/try.sh">view example try.sh</a></p></li>
+<li><p><a href="try.sh">download example try.sh</a></p></li>
+<li><p><a href="https://github.com/ioccc-src/winner/blob/master/next/try.alt.sh">view example try.alt.sh</a></p></li>
+<li><p><a href="try.alt.sh">download example try.alt.sh</a></p></li>
+</ul>
+<p>Of course, it is quite possible that only one invocation is
+possible, so it is not necessarily detrimental to your submission if you do not
+include one, though we do like interesting and creative uses of submissions. See
+also the
+FAQ on “<a href="../faq.html#try_scripts">submitting try.sh and try.alt.sh scripts</a>”.</p>
 <p class="leftbar">
-Over the years some judges have submitted code that had to be rejected once it
-was discovered to be a judge.
-</p>
-<p>One <strong>should NOT</strong> attempt to <strong>bribe</strong> an <a href="../judges.html">IOCCC
-judge</a>, <strong>unless you are an <a href="../judges.html">IOCCC judge</a></strong>,
-because <strong>bribing</strong> an <a href="../judges.html">IOCCC judge</a> by a non-judge
-has been shown to <strong>NOT</strong> be effective when the <strong>person <em>attempting</em>
-the <em>bribe</em> is made known</strong> to the <a href="../judges.html">IOCCC judges</a>
-(i.e., they are not anonymous) AND/OR the <strong>bribe</strong> is otherwise
-associated with a submission to the <a href="../index.html">IOCCC</a>.</p>
-<p>With the previous guideline in mind: <strong>anonymous</strong> gifts
-for the <a href="../judges.html">IOCCC judges</a> that are <strong>NOT ASSOCIATED
-WITH</strong> a submission to the <a href="../index.html">IOCCC</a> may be sent to the
-<a href="../judges.html">IOCCC judges</a> via the
-<a href="https://www.amazon.com/hz/wishlist/ls/3HSNTEL8RQ1M0?ref_=wl_share">IOCCC Amazon wishlist</a>.
-It has been shown that receiving <strong>anonymous</strong> gifts provides the
-<a href="../judges.html">IOCCC judges</a> with a nice
-<a href="https://en.wikipedia.org/wiki/Dopamine">dopamine</a> boost, and happy
-<a href="../judges.html">IOCCC judges</a> help make the <a href="../index.html">IOCCC</a> better for everyone. :-)</p>
-<p>See the
-FAQ on “<a href="../faq.html#support">supporting the IOCCC</a>”.</p>
-<p>More often than not, we select a small submission (usually one line) and a
-strange/creative layout submission. We sometimes also select a
-submission that abuses the <a href="guidelines.html">IOCCC guidelines</a> in an interesting way,
-or that stretches the contest <a href="rules.html">rules</a> that while legal, it
-nevertheless goes against the <strong>intent</strong> of the <a href="rules.html">rules</a>.</p>
-<p>Nevertheless, see
-<a href="rules.html#rule-10---privileges">Rule 10 - Privileges</a>.</p>
-<p>In the end, we traditionally pick one submission as ‘<strong>best</strong>’. Sometimes such
-a submission simply far exceeds any of the other submissions. More often, the
-‘<strong>best</strong>’ is picked because it does well in a number of categories.</p>
-<p>In years past, we renamed the winning submission from <code>prog.c</code> to a
-name related to the author(s)’ names. This is no longer done.
-Winning source is called <code>prog.c</code>. A compiled binary is called <code>prog</code>.</p>
-<p>Jump to: <a href="#">top</a></p>
-<div id="announcements">
-<h1 id="announcement-of-winners">ANNOUNCEMENT OF WINNERS:</h1>
-</div>
-<p>The <a href="../judges.html">IOCCC judges</a> will toot initial announcement of who won, the name
-of their award, and a very brief description (award title) of the winning entry
-from the <a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> Mastodon account</a>.</p>
-<p>We recommend that you follow us on mastodon but <strong>please make sure to
-refresh the feed</strong> every so often (if not more often) because unless you are
-mentioned or someone boosts your post you will not get a push notification.</p>
-<p>Jump to: <a href="#">top</a></p>
-<div id="winners">
-<h2 id="how-the-new-ioccc-winners-will-be-announced">How the new IOCCC winners will be announced</h2>
-</div>
-<p>The <a href="../status.html">current status of the IOCCC</a> will change from
-<strong><a href="../faq.html#judging">judging</a></strong> to <strong><a href="../faq.html#closed">closed</a></strong> .</p>
-<p>The <strong>contest_status</strong> in the <a href="../status.json">status.json</a> file will change
-from <strong>judging</strong> to <strong>closed</strong> as well.</p>
-<p>When the above happens, the winning entries have been selected by the <a href="../judges.html">IOCCC
-judges</a>.</p>
-<p>The <a href="../judges.html">IOCCC judges</a> will begin to prepare to release the source
-code of the new IOCCC winners.</p>
-<p>The <a href="../judges.html">IOCCC judges</a> will commit the winning source to the
-<a href="https://github.com/ioccc-src/winner">IOCCC winner repo</a> which will update the
-<a href="https://www.ioccc.org/index.html">Official IOCCC website</a>.</p>
-<p>The <a href="../news.html">IOCCC news</a> will also contain an announcement of the winners.</p>
-<p>Jump to: <a href="#">top</a></p>
-<div id="mastodon">
-<h2 id="an-important-update-to-how-winners-are-announced">An important update to how winners are announced</h2>
-</div>
-<p class="leftbar">
-The IOCCC no longer uses twitter. Winning IOCCC entries will be announced by a
-<code>git</code> commit to the <a href="https://github.com/ioccc-src/winner">IOCCC entries repo</a>
-that, in turn, updates the <a href="https://www.ioccc.org/index.html">Official IOCCC
-website</a>.
+Even if it only has one invocation we still <strong>LIKE</strong> the try scripts.
 </p>
 <p class="leftbar">
-In addition a note is posted to the <a href="https://fosstodon.org/@ioccc">IOCCC Mastodon account</a>.
+If you do include a <code>try.sh</code> then <strong>PLEASE</strong> remove the <code>try</code> rule in the Makefile.
 </p>
 <p class="leftbar">
-We will also post a notice to the IOCCC discord server.
+If you do include a <code>try.alt.sh</code> then <strong>PLEASE</strong> remove the <code>try.alt</code> rule in the Makefile.
 </p>
-<p>Consider joining the IOCCC discord community via this link:
-<a href="https://discord.gg/Wa42Qujwnw">https://discord.gg/Wa42Qujwnw</a></p>
+<p class="leftbar">
+If you don’t have a prog.alt.c, then <strong>PLEASE</strong> remove the <code>try.alt</code> rule as well.
+</p>
+<p>Doing masses of <code>#define</code>s to obscure the source has become ‘old’. We
+tend to ‘see thru’ masses of <code>#define</code>s due to our pre-processor tests
+that we apply. Simply abusing <code>#define</code>s or <code>-Dfoo=bar</code> won’t go as far
+as a program that is more well rounded in confusion.</p>
+<p><strong>Many</strong> C compilers <strong>DISLIKE</strong> the following code, and so do we:</p>
+<pre><code>    #define d define
+    #d foo             /* &lt;-- don&#39;t expect this to turn into #define foo */</code></pre>
+<p>In other words, it is a compilation error, and in order to get older
+IOCCC winning entries that did this to compile, we had to update them to not do this.</p>
+<p>When declaring local or global variables, you should declare the type:</p>
+<pre><code>    int this_is_fine;
+    this_is_not;       /* &lt;-- Try to avoid implicit type declarations */</code></pre>
+<p>We tend to <strong>like <em>less</em></strong> a submission that requires either
+<code>gcc</code> <strong>OR</strong> <code>clang</code>. <strong>We <em>prefer</em> submissions</strong> that can compile
+under <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>. <strong>Hint!</strong></p>
+<p>We <strong>RECOMMEND</strong> that the compiler flags you use in your
+submission’s <code>Makefile</code> are supported by <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>.</p>
+<p>We <strong>DISLIKE</strong> the use of obscure compiler flags, especially
+if <code>gcc</code> and/or <code>clang</code> do not support it. We <strong>suggest</strong>
+that you not use any really obscure compiler flags if you can help it.</p>
+<p>One side effect of the above is that you cannot assume the use
+of nested functions such as:</p>
+<pre><code>     int main() {
+|        void please_dont_submit_this() {
+|           printf(&quot;The machine that goes BING!!\n&quot;);
+         }
+|        please_dont_submit_this();
+     }</code></pre>
+<p>On 2012 July 20, the <a href="../judges.html">IOCCC judges</a> rescinded the encouragement of
+nested functions. Such constructions, while interesting and sometimes
+amusing, will have to wait until they are required by a C standard that are
+actually implemented in <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>.</p>
+<p>We <strong>DISLIKE</strong> submissions that require the use of <code>-fnested-functions</code>.</p>
+<p>If your submission uses functions that have a variable number of
+arguments, <strong>be careful</strong>. Systems implement <code>va_list</code> in a wide variety
+of ways. Because of this, a number of operations using <code>va_list</code> <strong>are
+not portable and <em>must not</em> be used</strong>:</p>
+<ul>
+<li>assigning a non-<code>va_list</code> variable to/from a <code>va_list</code> variable</li>
+<li>casting a non-<code>va_list</code> variable into/from a <code>va_list</code> variable</li>
+<li>passing a <code>va_list</code> variable to a function expecting a non-<code>va_list</code> arg</li>
+<li>passing a non-<code>va_list</code> variable to a function expecting a <code>va_list</code> arg</li>
+<li>performing arithmetic on <code>va_list</code> variables</li>
+<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>.</p>
+<p>We <strong>DISLIKE</strong> the use of <code>varargs.h</code>. Use <code>stdarg.h</code> instead.</p>
+<p>We <strong>DISLIKE</strong> the use of <code>gets(3)</code>. Use <code>fgets(3)</code> instead.</p>
+<p>We tend to <strong>DISLIKE</strong> the blatant use of tarballs in an attempt to simply get
+around the extra file number limit. We realize there may be cases where a
+tarball containing a number of extra files may be needed. Such a need for a
+tarball <strong>MUST</strong> be explained in the <code>remarks.md</code> file.</p>
+<p class="leftbar">
+Using a mass of <code>goto</code>s to obfuscate your code has become ‘old’ and is unlikely
+to make it through the final rounds, if it even gets that far.
+</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 byte.</p>
+<p>The <code>exit(3)</code> function returns <code>void</code>. Some broken systems have <code>exit(3)</code>
+return <code>int</code>; your submission should assume that <code>exit(3)</code> returns a <code>void</code>.</p>
+<p>Small programs are best when they are short, obscure and concise.
+While such programs are not as complex as other winners, they do
+serve a useful purpose: they are often the only program that people
+attempt to completely understand. For this reason, we look for
+programs that are compact, and are instructional.</p>
+<p>One line programs should be short one line programs: say around <strong>80</strong> to <strong>132</strong>
+bytes long. Going well beyond <strong>132</strong> bytes is a bit too long to be called
+a one-liner in our vague opinion.</p>
+<p>We tend to <strong>DISLIKE</strong> programs that:</p>
+<ul>
+<li>are very hardware specific</li>
+<li>are very OS version specific (<code>index(3)</code>/<code>strchr(3)</code> differences are OK, but
+sockets/streams specific code is likely not to be)</li>
+<li>dump core or have compiler warnings (it is OK only if
+you warn us in your <code>remarks.md</code> file)</li>
+<li>won’t compile or run in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
+Specification</a>
+environment</li>
+<li>depend on a utility or application not normally found
+in systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
+Specification</a></li>
+<li>abuse the build file to get around the size limit</li>
+<li>obfuscate by use of ANSI trigraphs</li>
+<li>obfuscate by use of digraphs</li>
+<li>are larger than they need to be</li>
+<li>have more lines than they need to have</li>
+<li>are “blob-ier” (just a pile of unformatted C code) than they need to be</li>
+<li>are rather similar to <strong><a href="../years.html">previous winners</a></strong> :-(</li>
+<li>are <strong>identical</strong> to <strong><a href="https://en.wikipedia.org/wiki/Null_device">previous losers</a></strong> :-)</li>
+<li>that mandate the exclusive use of a specific Integrated Development Environment (IDE)</li>
+</ul>
+<p>In order to encourage submission portability, we <strong>DISLIKE</strong> submissions that
+fail to build unless one is using an IDE. For example, do not
+mandate that one must use Microsoft Visual Studio to compile
+your submission.</p>
+<p>The program must compile and link cleanly in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
+Specification</a>
+environment. Therefore do not assume the system has a
+<a href="https://en.wikipedia.org/wiki/Windows.h">windows.h</a> include file:</p>
+<pre><code>    #include &lt;windows.h&gt;  /* we DISLIKE this */</code></pre>
+<p>Unless you are cramped for space, or unless you are entering the
+‘<strong>Best one liner</strong>’ category, we suggest that you format your program
+in a more creative way than simply forming excessively long lines.</p>
+<p>The <code>Makefile</code> should not be used to try and get around the size limit. It is
+one thing to make use of a several <code>-D</code>s on the compile line to help out, but it
+is quite another to use many bytes of <code>-D</code>s in order to try and squeeze the
+source under the size limit.</p>
+<p>Your source code, post-pre-processing, should not exceed the size of
+<a href="https://en.wikipedia.org/wiki/Microsoft_Windows">Microsoft Windows</a>. :-)</p>
+<p>You should try to restrict commands used in the build file to commands found in
+<a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
+Specification</a>
+environments and systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
+Specification</a>.</p>
+<p>You may compile and use your own programs. If you do, try to build and execute
+from the current directory. This restriction is not a hard and
+absolute one. The intent is to ensure that the building of your
+program is reasonably portable.</p>
+<p>We prefer programs that are portable across a wide variety of UNIX-like
+operating systems (e.g., Linux, GNU Hurd, BSD, UNIX, etc.).</p>
+<p>Don’t forget that the building of your program should be done
+<strong>WITHOUT human intervention</strong>. So don’t do things such as:</p>
+<pre><code>    prog: prog.c
+        #echo this next line requires data from standard input
+        cat &gt; prog.c
+        ${CC} prog.c -o prog</code></pre>
+<p>However, you can do something cute such as making your program
+do something dumb (or cute) when it is built ‘automatically’, and
+when it is run with a human involved, do something more clever.
+For example, one could put in their <code>Makefile</code>:</p>
+<pre><code>    prog: prog.c
+        ${CC} prog.c -DNON_HUMAN_COMPILE -o prog
+        @echo &quot;See remarks section about alternate ways to compile&quot;</code></pre>
+<p>and then include special notes in your <code>remarks.md</code> file for
+alternate / human intervention based building.</p>
+<p>We want to get away from source that is simply a compact blob of
+bytes. <strong>REALLY TRY</strong> to be more creative than blob coding. <strong>HINT!</strong></p>
+<p>Please do not use things like <code>gzip(1)</code> to get around the size limit.
+Please try to be much more creative.</p>
+<p>We really <strong>DISLIKE</strong> submissions that make blatant use of including
+large data files to get around the source code size limit.</p>
+<p>Did we remember to indicate that programs that blatantly use
+some complex state machine to do something simple, are boring?
+We think we did. :-)</p>
+<p>Given two versions of the same program, one that is a compact blob
+of code, and the other that is formatted more like a typical C
+program, we tend to favor the second version. Of course, a third
+version of the same program that is formatted in an interesting
+and/or obfuscated way, would definitely win over the first two!
+Remember, you can submit more than one submission. See the
+<a href="rules.html">IOCCC rules</a>
+for details (in particular,
+<a href="rules.html#rule-8---submission">Rule 8 - Submission</a>).</p>
+<p>We suggest that you avoid trying for the ‘<strong>smallest self-replicating</strong>’
+source. The smallest, a <a href="../1994/smr/index.html">zero byte entry</a>, won in
+<a href="../years.html#1994">1994</a>.</p>
+<p>Programs that claim to be the smallest C source that does something, really
+better be the smallest such program or they risk being rejected because
+they do not work as documented.</p>
+<p>Please note that the C source below, besides lacking in obfuscation,
+is <strong>NOT</strong> the smallest C source file that when compiled and run, dumps core:</p>
+<pre><code>    main;</code></pre>
+<p>Unless you specify <code>-fwritable-strings</code> (see <code>COTHER</code> in the example
+Makefile, described in the <a href="#makefile">Makefile section</a>), do not assume this
+sort of code will work:</p>
+<pre><code>    char *T = &quot;So many primes, so little time!&quot;;
+    ...
+    T[14] = &#39;;&#39;;    /* modifying a string requires: -fwritable-strings */</code></pre>
+<p>Even so, one should probably not assume that this is universally accepted.</p>
+<p>Initialized char arrays are OK to write over. For instance, this is OK:</p>
+<pre><code>    char b[] = &quot;Is this OK&quot;;
+    b[9] = &#39;k&#39;;     /* modifying an initialized char array is OK */</code></pre>
+<p>X client submissions should be as portable as possible. Submissions that
+adapt to a wide collection of environments will be favored. For
+example, don’t depend on a particular type or size of display.
+Don’t assume the use of a particular browser. Instead assume a
+generic browser that forms to a widely used <a href="https://www.w3.org/standards/">W3C
+standard</a>.
+Don’t assume a particular sound sub-system or video driver is installed
+in the OS. Instead, make use of a well known and widely available open
+source program (one that actually works) to display audio/visual data.</p>
+<p>X client submissions should avoid using X related libraries and
+software that are not in wide spread use.</p>
+<p>As of Red Hat RHEL9.0, the X.org server is deprecated. See the
+FAQ on “<a href="../faq.html#Xorg_deprecated">Xorg deprecation”</a>”
+for more details. This does not mean that a submission using this will
+necessarily be rejected, but it would be better if it can support Wayland in
+some way or another.</p>
+<p>We <strong>DISLIKE</strong> submissions that use proprietary toolkits such as the <code>M*tif</code>,
+<code>Xv*ew</code>, or <code>OpenL*ok</code> toolkits, since not everyone has them. Use an
+open source toolkit that is widely and freely available instead.</p>
+<p>X client submissions should try to not to depend on particular items in
+<code>.Xdefaults</code>. If you must do so, be sure to note the required lines
+in the your <code>remarks.md</code> file. They should also not depend on any
+particular window manager.</p>
+<p>Try to avoid submissions that play music that some people believe is copyrighted
+music.</p>
+<p>While we recognize that UNIX is not a universal operating system, the contest
+does have a bias towards such systems. In an effort to expand the scope of the
+contest, we phrase our bias to favor the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
+Specification</a>.</p>
+<p>You are <strong>well advised</strong> to submit code that conforms to the <a href="https://unix.org/version4/overview.html">Single UNIX
+Specification Version 4</a>.</p>
+<p>To quote the <a href="../judges.html">IOCCC judges</a>:</p>
+<p>We <strong>LIKE</strong> programs that:</p>
+<ul>
+<li>are as concise and small as they need to be</li>
+<li>do something at least quasi-interesting</li>
+<li>are portable</li>
+<li>are unique or novel in their obfuscation style</li>
+<li>make use of a <strong>NUMBER OF DIFFERENT TYPES OF OBFUSCATIONS!</strong> <strong>&lt;== HINT!!</strong></li>
+<li>make us laugh and/or throw up :-) (humor really helps!)</li>
+<li>make us want to eat good chocolate</li>
+</ul>
+<p>Some types of programs can’t excel (anti-tm) in some areas. Your
+program doesn’t have to excel in all areas, but doing well in several
+areas really does help.</p>
+<p>You are better off explaining what your submission does in your
+<code>remarks.md</code> file section rather than leaving it obscure for the
+<a href="../judges.html">IOCCC judges</a> as we might miss something and/or be too tired to
+notice.</p>
+<p>We freely admit that interesting, creative or humorous comments in
+your <code>remarks.md</code> file help your chances of winning. If you had to
+read so many twisted submissions, you too would enjoy a good laugh or two.
+We think the readers of the contest winners do as well. We do read
+your <code>remarks.md</code> content during the judging process, so it is worth your
+while to write a remarkable <code>remarks.md</code> file.</p>
+<p>We <strong>DISLIKE</strong> C code with trailing control-M’s (<code>\r</code> or <code>\015</code>) that results
+in compilation failures. Some non-UNIX/non-Linux tools such as
+MS Visual C and MS Visual C++ leave trailing control-M’s on lines.
+Users of such tools should strip off such control-M’s before submitting
+their submissions. In some cases tools have a “Save As” option that will
+prevent such trailing control-M’s being added.</p>
+<p>One should restrict libcurses to portable features found on BSD
+or Linux curses.</p>
+<p class="leftbar">
+If you do <code>#include &lt;curses.h&gt;</code> make <strong>CERTAIN</strong> you link in curses (i.e.
+<code>-lcurses</code>) and not ncurses (i.e. <code>-lncurses</code>).
+</p>
+<p><a href="rules.html#rule-13---newlines">Rule 13 - Newlines</a>
+no longer discourages the use of UTF-8
+characters in C code.</p>
+<p>It is a very good idea to, in your <code>remarks.md</code> file, tell us why you
+think your submission is obfuscated. This is particularly true if
+your submission has some very subtle obfuscations that we might
+otherwise overlook. <strong>&lt;&lt;– Hint!</strong></p>
+<p>Anyone can format their code into a dense blob. A really clever
+author will try format their submission using a “normal” formatting style
+such that at first glance (if you squint and don’t look at the details)
+the code might pass for non-obfuscated C. Deceptive comments,
+and misleading formatting, in some cases, may be a plus. On the
+other hand, a misleading code style requires more source bytes.</p>
+<p>If you do elect to use misleading formatting and comments, we
+suggest you remark on this point in your <code>remarks.md</code> where you talk
+about why you think your submission is obfuscated. On the other hand,
+if you are pushing up against the size limits, you may be forced
+into creating a dense blob. Such are the trade-offs that obfuscators face!</p>
+<p>We prefer code that can run on either a 64-bit or 32-bit
+processor. However, it is <strong>UNWISE </strong>to assume it will run on an
+some Intel-like x86 architecture**.</p>
+<p>While programs that only run in a specific word size are OK, if you have
+to pick, choose a 64-bit word size.</p>
+<p>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>ARCH</code> in the example
+Makefile, described in <a href="#makefile">Makefile section</a>). Do not assume a
+processor word size without specifying <code>-arch</code>. For example:</p>
+<pre><code>    ARCH= -m64</code></pre>
+<p>Note, however, that some platforms will not necessarily support some
+architectures. For instance, more recent versions of <code>macOS</code> do <strong>NOT</strong> support
+32-bit!</p>
+<p>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
+submission factors values up to a certain size, you might want to state:</p>
+<blockquote>
+<p>This submission factors values up <code>2305567963945518424753102147331756070</code>.
+Attempting to factor larger values will produce unpredictable results.</p>
+</blockquote>
+<p>The <a href="../judges.html">IOCCC judges</a> might try to factor the value -5, so you want to might state:</p>
+<blockquote>
+<p>This submission factors positive values up
+<code>2305567963945518424753102147331756070</code>. Attempting to factor large values will
+produce unpredictable results.</p>
+</blockquote>
+<p>However the <a href="../judges.html">IOCCC judges</a> might try to also factor 0, so you want to might state:</p>
+<blockquote>
+<p>This submission factors values between 1 and
+<code>2305567963945518424753102147331756070</code>. Attempting to factor values outside
+that range will produce unpredictable results.</p>
+</blockquote>
+<p>Moreover they might try to also factor 3.5 or 0x7, or Fred, so you want to might state:</p>
+<blockquote>
+<p>This submission factors integers between 1 and
+<code>2305567963945518424753102147331756070</code>. Attempting to factor anything else
+will produce unpredictable results.</p>
+</blockquote>
+<p>You submission might be better off catching the attempt to factor bogus values
+and doing something interesting. So you might want to code accordingly and state:</p>
+<blockquote>
+<p>This submission factors integers between 1 and <code>2305567963945518424753102147331756070</code>.
+Attempting to factor anything else will cause the program to insult your pet fish Eric.</p>
+</blockquote>
+<p>The <a href="../judges.html">IOCCC judges</a> might not have a pet fish named Eric, so you might want to state:</p>
+<blockquote>
+<p>This submission factors integers between 1 and
+<code>2305567963945518424753102147331756070</code>. Attempting to factor anything else
+will cause the program to insult your pet fish Eric, or in the case that you
+lack such a pet, will insult the pet that you do not have.</p>
+</blockquote>
+<p>When all other things are equal, a submission with fewer limitations will be judged
+better than a submission with lots of limitations. So you might want to code accordingly
+and state:</p>
+<blockquote>
+<p>This submission attempts to a factor value of any size provided that the
+program is given enough time and memory. If the value is not a proper integer,
+the program might insult a fish named Eric.</p>
+</blockquote>
+<p>We <strong>DISLIKE</strong> the use of ASCII tab characters in markdown files, such as in the required <code>remarks.md</code> file.</p>
+<p>We don’t mind the use of ASCII tab characters in your C code. Feel free
+to use ASCII tab characters if that suits your obfuscation needs. If is
+perfectly <strong>OK</strong> to use tab characters elsewhere in your submission, just not in
+markdown files as this tends annoy us when it comes time to
+rendering your markdown content as it complicates the process.</p>
+<p>If you do use ASCII tab characters in your non-markdown files, be
+aware that some people may use a tab stop that is different than the common 8
+character tab stop.</p>
+<p><strong>PLEASE</strong> observe our <a href="../markdown.html">IOCCC markdown guidelines</a>
+when forming your submission’s <code>remarks.md</code> file. And if your submission
+contains additional markdown files, please follow those same guidelines for
+those files. See also
+<a href="rules.html#rule-4---files">Rule 4 - Files</a>,
+and the
+FAQ on “<a href="../faq.html#markdown">markdown</a>”.</p>
+<p>We <strong>LIKE</strong> reading <code>remarks.md</code> files, especially if they contain
+useful, informative, and even humorous content about your submission. Yes, this
+is a <strong>hint</strong>. :-)</p>
+<p>We <strong>RECOMMEND</strong> you put a reasonable amount effort into the content of the
+<code>remarks.md</code> file: it is a required file for a reason. :-)</p>
+<p>Try to be even more creative!</p>
 <p>Jump to: <a href="#">top</a></p>
-<div id="entries">
-<h2 id="back-to-announcement-of-winners">Back to announcement of winners</h2>
+<div id="fun">
+<h1 id="fundamental-guidelines">Fun😄damental Guidelines</h1>
 </div>
-<p>It is pointless to ask the <a href="../judges.html">IOCCC judges</a> how many
-submissions we receive. See <a href="../faq.html#how_many">How many submissions do the judges receive for a
-given IOCCC?</a>.</p>
-<p>Often, winning entries are published in selected magazines from around the
-world. Winners have appeared in books (‘<code>The New Hacker's Dictionary</code>’,
-‘<code>Obfuscated C and Other Mysteries</code>’, ‘<code>Pointers On C</code>’, others) and on t-shirts
-(sometimes by the author(s) themselves). There have been multiple classes
-that have focused in part, on IOCCC winning entries. And more than one winner has been turned
-into a tattoo!</p>
-<p>Last, but not least, <a href="../authors.html">winners</a> receive international fame and flames! :-)</p>
+<p>The reason for the times of day are so that key IOCCC events are <strong>calculated</strong>
+to be a <strong>fun</strong>ctional UTC time. :-)</p>
+<p>At least 2 of several reasons for selecting the prime, 2503, for
+<a href="rules.html#rule-2b---net-size">Rule 2b - Net Size</a>
+may be found on the <a href="https://t5k.org/curios/page.php/2503.html">“Curios!” about 2503</a>.</p>
+<p>The 2503 value for <a href="rules.html#rule-2b---net-size">Rule 2b - Net</a> is a decimal anagram
+of the number of the kernel disk pack of one of the judge’s <a href="https://en.wikipedia.org/wiki/BESM-6">BESM-6</a>.</p>
+<p>There may or may not be fewer than 2^7+1 reasons why these <a href="guidelines.html">IOCCC
+guidelines</a> seem obfuscated.</p>
+<p>Excessively “<em>dotty”</em> use of the <code>chksubmit(1)</code> or <code>chkentry(1)</code> commands suggests that
+either like silly things, or that you”<em>RTFS”</em> with some level of care.</p>
+<p>Some people might question what actually constitutes a valid JSON file, given
+the state of the “<em>so-called</em>” JSON spec.. :-)</p>
+<p>We prefer programs that do not require a fish license: crayons and
+cat detector vans not withstanding.</p>
+<p class="leftbar">
+This <em>guideline</em> has a change mark at the very start of this line.
+</p>
+<p>While those who are used to temperatures found on <a href="https://science.nasa.gov/dwarf-planets/">dwarf
+planets</a>
+(<strong>yes Virginia, dwarf planets <em>ARE</em> planets!</strong>), such as
+<a href="https://science.nasa.gov/dwarf-planets/pluto/">Pluto</a>, might be able to
+explain to the Walrus why our seas are boiling hot, the question of
+whether pigs have wings is likely to remain a debatable point to most.</p>
+<p>At least one judge prefers to maintain the use of the
+<a href="https://en.wikipedia.org/wiki/Leap_second">leap-second</a>
+as part of the world’s time standard. If your code prints time
+with seconds, we prefer that your code be capable of printing the
+time of day during a leap-second where the value in seconds
+after the minute mark is <strong>60</strong>.</p>
+<p>Other windows, on the other hand, might be OK: especially where “<strong>X
+marks the spot</strong>”. Yet on the third hand, windows are best when they are
+“unseen” (i.e., not dirty). :-)</p>
+<p>The <a href="../judges.html">IOCCC judges</a>, as a group, have a history giving wide degree of latitude
+to reasonable submissions. And recently they have had as much longitudinal
+variation as it is possible to have on <a href="https://science.nasa.gov/earth/">Earth</a>. :-)
+Other windows, on the other hand, might be OK: especially where “<strong>X
+marks the spot</strong>”. Yet on the third hand, windows are best when they are
+“unseen” (i.e., not dirty). :-)</p>
+<p>The <a href="../judges.html">IOCCC judges</a>, as a group, have a history giving wide degree of latitude
+to reasonable submissions. And recently they have had as much longitudinal
+variation as it is possible to have on <a href="https://science.nasa.gov/earth/">Earth</a>. :-)</p>
+<blockquote>
+<p>You are in a maze of twisty <em>guidelines</em>, all different.</p>
+</blockquote>
+<p>There are at least zero <a href="../judges.html">IOCCC judges</a> who think that
+<a href="https://en.wikipedia.org/wiki/Fideism">Fideism</a> has little
+or nothing to do with the IOCCC judging process.</p>
+<blockquote>
+<p>All generalizations are false, including this one. – <strong>Mark Twain</strong></p>
+</blockquote>
+<p class="leftbar">
+There are more than about 1 typos in this very sentence.
+</p>
+<p>This could be the only <em>guideline</em> that contains the word
+<a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>.</p>
+<p>However, do you know how to play <a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>?
+You do?!? (Except on Tuesday?)</p>
+<p>OK, there are actually 2 <em>guidelines</em> that contain the word
+<a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>,
+unless you count this one, in which case there are 3. :-)</p>
+<p><strong>NOTE</strong>: The previous <em>guideline</em> in this spot has been replaced by this <em>guideline</em>:</p>
+<p class="leftbar">
+<blockquote>
+<p>You very well might not be completely prohibited from failing to not partly
+misunderstand this particular <em>guideline</em>, but of course, we could not possibly
+comment! :-) Nevertheless, you are neither prohibited, nor are you fully or partly
+required to determine that this or the previous sentence is either false and/or
+perhaps misleading. Therefore, it might be wise for you to not fail to consider
+to not do so, accordingly. Thank you very much (allegedly).</p>
+</blockquote>
+</p>
+<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
+parliament should you have one.</p>
+<p class="leftbar">
+Please try to avoid this specific individual <em>guideline</em>, if it at all possible.
+</p>
+<p>We believe that Mark Twain’s quote:</p>
+<blockquote>
+<p>Get your facts first, then you can distort them as you please.</p>
+</blockquote>
+<p>… is a good motto for those writing code for the IOCCC.</p>
+<p class="leftbar">
+We do not recommend submitting <a href="https://systemd.io">systemd</a> source code to the IOCCC,
+if nothing else because that code is likely to exceed
+<a href="rules.html#rule-2---size">Rule 2 - Size</a>.
+This isn’t to say that another highly compact and obfuscated
+replacement of <code>init(8)</code> would not be an interesting submission.
+</p>
+<p class="leftbar">
+The
+<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
+is not an original work, unless you one of the
+<a href="https://github.com/ioccc-src/mkiocccentry/graphs/contributors">several mkiocccentry toolkit contributors</a>.
+in which case it is original! :-)
+</p>
+<p>If the <a href="../judges.html">IOCCC judges</a> are feeling ornery we
+might choose to compile your program for running on an Arduino or
+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>Do not fear if you’re not 100% sure of the significance of
+<code>2305567963945518424753102147331756070</code> as it is not of prime importance: or is
+it? :-)</p>
 <p>Jump to: <a href="#">top</a></p>
 <div id="more-information">
 <div id="information">
diff --git a/next/guidelines.md b/next/guidelines.md
index 92659405d..37d4cc16b 100644
--- a/next/guidelines.md
+++ b/next/guidelines.md
@@ -26,10 +26,10 @@ app from time to time to view IOCCC mastodon updates.
 
 <!-- END: the next line ends content from: inc/guidelines.closed.hdr -->
 <!-- This is the last line modified by the tool: bin/gen-status.sh -->
-# 28th International Obfuscated C Code Contest Official Guidelines
+# 29th International Obfuscated C Code Contest Official Guidelines
 
 <p class="leftbar">
-Copyright &copy; 2024-2025 Leonid A. Broukhis and Landon Curt Noll.
+Copyright &copy; 2025 Leonid A. Broukhis and Landon Curt Noll.
 </p>
 
 All Rights Reserved.  Permission for personal, education or non-profit use is
@@ -38,200 +38,34 @@ and remains unaltered.  All other uses must receive prior permission in
 writing by [contacting the judges](../contact.html).
 
 
-Jump to: [top](#)
-
-
-<div id="guidelines_version">
-<div id="version">
 # IOCCC Guidelines version
+
+<p class="leftbar">
+These IOCCC guidelines are version **29.00 2025-11-28**.
+</p>
+
+<p class="leftbar">
+The <span style='font-size:28px;'><b>&verbar;</b></span> symbol indicates an **change** from the previous IOCCC.
+</p>
+
+<p class="leftbar">
+Because the **IOCCC29** guidelines was a substantial rewrite, only **important changes** from **IOCCC28** have been marked.
+</p>
+
+Be sure to read the [IOCCC rules](guidelines.html).
+
+
+<div id="guideline2">
+<div id="guideline-2---size">
+# Guidelines for [Rule 2 - Size](rules.html#rule-2---size)
 </div>
 </div>
 
 <p class="leftbar">
-These [IOCCC guidelines](guidelines.html) are version **28.49 2025-11-17**.
+You should pay attention to our observations on
+[code size and Rule 2 remarks for IOCCC28](../2024/index.html#code-size-and-rule-2).
 </p>
 
-The markdown form of these guidelines <a href="guidelines.md"
-download="guidelines.md">is available for download</a>.
-
-**IMPORTANT**: Be **SURE** to read the [IOCCC rules](rules.html).
-
-
-Jump to: [top](#)
-
-
-<div id="change_marks">
-# Change marks
-</div>
-
-<p class="leftbar">**&larr; Lines that start with this symbol indicate a change from the
-previous IOCCC**.
-</p>
-
-Most lines (we sometimes make mistakes) that were modified since the previous
-IOCCC start with a solid 4 pixel black left border (or, in the case of a code
-block or blockquote, just a vertical bar).
-
-
-Jump to: [top](#)
-
-
-<div id="about_guidelines">
-# ABOUT THIS FILE:
-</div>
-
-This file contains _guidelines_ intended to help people who wish to
-participate in the [International Obfuscated C Code Contest
-&lpar;IOCCC&rpar;](https://www.ioccc.org).
-
-These are **NOT the [IOCCC rules](rules.html)**, though it does contain comments
-about them.  The [IOCCC guidelines](guidelines.html) should be viewed as
-**hints** and **suggestions**.  **Submission that violate the
-[guidelines](guidelines.html) _but remain within the [rules](rules.html)_** _are
-allowed_.  Even so, you are safer if you remain within the [IOCCC
-guidelines](guidelines.html).
-
-Of course if a guideline is talking about a rule and you break that guideline,
-you stand a good chance of having your submission rejected for breaking the
-rule, not the guideline.
-
-You **SHOULD read the CURRENT [IOCCC rules](rules.html)**, _prior_ to submitting
-code to the contest.
-
-
-Jump to: [top](#)
-
-
-<div id="new">
-# WHAT'S NEW THIS IOCCC
-</div>
-
-<p class="leftbar">
-This IOCCC runs from **2024-12-29 23:58:13.213455 UTC** to **2025-06-05 04:03:02.010099 UTC**.
-This IOCCC marks the **40th anniversary** of the contest!
-</p>
-
-<p class="leftbar">
-This contest will enter the **[pending](../faq.html#pending)** state on or about
-**2024-12-29 23:58:13.213455 UTC**.
-When this happens, you may begin registering to enter the IOCCC.
-</p>
-
-<p class="leftbar">
-This contest will enter the **[open](../faq.html#open)** state on **2025-03-05 23:19:17.131107 UTC**.
-When this happens, you may begin uploading your submissions to the IOCCC.
-</p>
-
-<p class="leftbar">
-This contest will enter the **[judging](../faq.html#judging)** state on **2025-06-05 04:03:02.010099 UTC**.
-When this happens, you may no longer upload your submissions to the IOCCC.
-</p>
-
-**IMPORTANT NOTE**: Until the contest enters the **[open](../faq.html#open)** state, any or all
-of the above **dates and times may change _AT ANY TIME_**!
-
-<p class="leftbar">
-The reason for the times of day are so that key IOCCC events are **calculated**
-to be a **fun**ctional UTC time.  :-)
-</p>
-
-Until the contest status becomes **[open](../faq.html#open)**,
-the [IOCCC rules](rules.html),
-[IOCCC guidelines](guidelines.html) and the tools in the
-[mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) **SHOULD be
-considered** provisional **BETA** versions and **may be adjusted _AT ANY TIME_**
-before the contest status becomes **[open](../faq.html#open)**.
-
-See the
-FAQ on "[how to register and submit to the IOCCC](../quick-start.html#enter)"
-for instructions on registering and participating in the IOCCC, as the process
-may change from contest to contest.
-
-To assist in the formation of the xz compressed tarball for submission, use the
-`mkiocccentry(1)` tool as found in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
-
-See FAQs regarding:
-
-- [obtaining the latest mkiocccentry tools](../faq.html#obtaining_mkiocccentry)
-- [compiling the mkiocccentry tools](../faq.html#compiling_mkiocccentry)
-- [installing the mkiocccentry tools](../faq.html#install)
-- [using the mkiocccentry tools](../faq.html#using_mkiocccentry)
-
-Uploading a tarball not formed by `mkiocccentry(1)` puts you at a very big risk of
-violating
-[Rule 17 - Packaging](rules.html#rule-17---packaging),
-especially as `mkiocccentry(1)` does a
-great number of things that are required, and it also runs many checks, and if
-any of those checks fail, you are at a very great risk of having your submission
-rejected for violating
-[Rule 17 - Packaging](rules.html#rule-17---packaging).
-
-We **STRONGLY** recommend you **do** install the
-[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry).
-
-**IMPORTANT NOTE**: the tools that require other tools, `mkiocccentry(1)` and
-`txzchk(1)`, will, as of version `2.0.2 2025-03-11`, search under `$PATH`. If
-you have an earlier version and you have not installed the tools and run the
-tools from outside the repo directory, you will have to use the options to the
-tools to set the path to the required tools.
-
-See the
-FAQ on "[obtaining and compiling the most recent mkiocccentry tools](../faq.html#mkiocccentry)"
-and the
-FAQ on "[how to enter the IOCCC](../quick-start.html#enter)"
-as that FAQ has important details on
-[how to register](../next/register.html)
-as well as
-[how to upload your submission](../next/submit.html) to the IOCCC.
-
-While the contest is **[open](../faq.html#open)**, you may modify your
-previously uploaded submission by rebuilding your submission with the
-`mkiocccentry(1)` tool and then re-uploading it to **the same slot number** on the
-[submit server](https://submit.ioccc.org).
-
-**HINT:** so that you do not have to repeatedly answer all the
-questions, the `mkiocccentry(1)` tool has the options `-a answers`, `-A answers`
-and `-i answers`, where `-a` will write to an answers file (if it does not
-already exist), `-A` **WILL OVERWRITE THE FILE** and `-i` will read the answers from
-the file. If you use `-A`, **BE SURE** you don't overwrite another file by accident!
-
-Be aware that even with the `-i answers` you will still be required to confirm
-most if not all `y/n` questions - you just don't have to input the name of the
-submission, the abstract, the author details etc. If you really wish to
-circumvent this you can use the `-Y` option but we do not recommend this because
-if your update breaks a rule or there is some problem, you might not see it.
-
-To help with not having to repeatedly enter a UUID, whether for the same
-submission or multiple submissions, you can use the `-u uuidfile` or `-U UUID`
-option. See the
-FAQ on "[how to avoid re-entering your UUID](../faq.html#uuid)"
-for more details. Note that the `-i answers` option cannot be used with the UUID
-options as the answers file includes the UUID.
-
-The overall size limit (see Rule 2a Gross Size](rules.html#rule-2a-gross-size)) on `prog.c` has been
-**increased from 4096 to 4993** bytes.
-The [Rule 2b Next Size](rules.html#rule-2b-net-size)size was changed from
-**4096** to **4993** to keep the "2b to 2a" size ratio to a
-value similar to the [2001-2012](../faq.html#size_rule2001-2012) and
-[2013-2020](../faq.html#size_rule2013-2020) IOCCC eras.
-
-The [Rule 2b Next Size](rules.html#rule-2b-net-size) size has **increased from 2053 to 2503**
-bytes.
-
-<p class="leftbar">
-However, you should pay especial attention to our remarks in the [IOCCC28
-index.html](../2024/index.html):
-</p>
-
-<p class="leftbar">
-> **IMPORTANT HINT**: Only 3 of the 23 **IOCCC28 winners** came close to the
-[Rule 2 - Size](rules.html#rule-2---size) limit.
-Large code size isn't
-everything.  :-) Those submitting to future contents should **take a careful
-note** of that fact.
-</p>
-
-
 Your submission must satisfy **BOTH** the maximum size
 [Rule 2a Gross Size](rules.html#rule-2a-gross-size)
 **AND**
@@ -253,1569 +87,93 @@ preprocessor keywords) as 1.  The size tool counts all other bytes as 1
 excluding ASCII whitespace, and excluding any '`;`', '`{`' or '`}`' followed by
 ASCII whitespace, and excluding any '`;`', '`{`' or '`}`' byte immediately
 before the end of file.
-
-ASCII whitespace includes ASCII tab, ASCII space, ASCII newline,
-ASCII formfeed, and ASCII carriage return.
-
-When '`;`', '`{`' or '`}`' are within a C string, they may still not be
-counted by the IOCCC size tool.  This is a **feature**, not a bug!
+>
+> ASCII whitespace includes ASCII tab, ASCII space, ASCII newline, ASCII formfeed, and ASCII carriage return.
+>
+> When '`;`', '`{`' or '`}`' are within a C string, they may still not be
+counted by the IOCCC size tool.
 
 In cases where the above summary and the algorithm implemented by
 the IOCCC size tool `iocccsize(1)` conflict, the algorithm implemented
 by the current version of `iocccsize(1)` is preferred by the [IOCCC judges](../judges.html).
 
-In other words, make sure `iocccsize` does not flag any issues with your
-`prog.c`.
+Make sure `iocccsize` does not flag any issues with your `prog.c`.
 
-There are at least 2 other reasons for selecting 2503 as the 2nd limit besides
-the fact that 2503 is a prime. These reasons may be searched for and discovered
-if you are ["Curios!" about 2503](https://t5k.org/curios/page.php/2503.html).
-:-) Moreover, 2053 was the number of the kernel disk pack of one of the judge's
-BESM-6, and 2503 is a decimal anagram of 2053.
-
-Take note that this secondary limit imposed by the IOCCC size tool
-obviates some of the need to `#define` C reserved words in an effort
+There a much less need to `#define` C reserved words in an effort
 to get around the size limits of
-[Rule 2 - Size](rules.html#rule-2---size).
+[Rule 2 - Size](rules.html#rule-2---size)
+because of the `iocccsize(1)` algorithm.
 
-Yes Virginia, **that is a hint**!
-
-The **official locale** of the **IOCCC** is **C**.
-
-<p class="leftbar">
-Did you really think anything else? :-)
-</p>
-
-The [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry),
-as of [Release version 2.4.4 2025-03-15](https://github.com/ioccc-src/mkiocccentry/releases/tag/2.4.4),
-will run with a locale set to **C**.
-</p>
+Yes Virginia, **the previous guideline sentence is an important hint**!
 
 
 Jump to: [top](#)
 
 
-<div id="hints">
-<div id="suggestions">
-# HINTS AND SUGGESTIONS:
+<div id="guideline3">
+<div id="guideline-3---register">
+# Guidelines for [Rule 3 - Register](rules.html#rule-3---register)
 </div>
 </div>
 
-You are **encouraged** to examine the [winners of previous contests](../years.html).
+See FAQ on "[What is an author handle?](../faq.html#author_handle_faq)".
 
-Keep in mind that [rules](rules.html) change from year to year, so some [winning
-entries](../years.html) might not be valid submissions this year; what _was_ unique
-and novel one year _might be 'old' the next year_.
 
-A submission is usually examined in a number of ways.  We typically apply
-a number of tests to a submission:
+Jump to: [top](#)
 
-* look at the original source
-* C pre-process the source ignoring `#include` lines
-* C pre-process the source ignoring `#define` _and_ `#include` lines
-* run it through a C beautifier
-* examine the algorithm
-* compile it (with flags to enable all warnings)
-* execute it
 
-You should consider how your submission looks in each of the above tests.
-You should ask yourself if your submission remains obscure after it has been
-'_cleaned up_' by the C pre-processor and a C beautifier.
+<div id="guideline7">
+<div id="guideline-7---original-work">
+# Guidelines for [Rule 7 - Original Work](rules.html#rule-7---original-work)
+</div>
+</div>
 
-Your submission need not pass all of the above tests.  In certain
-cases, a test is not important.  Submissions that compete for the
-'**strangest/most creative source layout**' need not do as well as
-others in terms of their algorithm.  On the other hand, given
-two such submissions, we are more inclined to pick the submission that
-does something interesting when it's executed.
+While it is **NOT** required, you are allowed to use tools or services such as:
 
-We try to avoid limiting creativity in our [rules](rules.html).  As such, we
-leave the contest open for creative rule interpretation.  As in [real
-life](https://en.wikipedia.org/wiki/Real_life) programming, interpreting a
-requirements document or a customer request is important.  For this reason, we
-often award '**Best abuse of the [rules](rules.html)**' or '**Worst abuse of the
-[rules](rules.html)**' or some variation to a submission that illustrates this
-point in an ironic way.
+* Code generators
+* Static and runtime code analysis tools
+* Machine learning tools
+* natural language models
+* Large language models (LLMs)
+* Code copilot tools
+* So called "_AI services_"
+* etc.
 
 The IOCCC has a rich history of remarkable winning entries created by
 authors who skillfully employed various techniques to develop their code.
-While it is **NOT** required, you are allowed to use tools to develop
-and test your submission.  These tools may include, but are not limited
-to code generators, code analysis tools, static code analysis tools,
-runtime analysis tools, machine learning tools, natural language models,
-code copilot tools, so-called AI services, large language models (LLMS), etc.
+
 If you do make use of such tools or services, then we **ENCOURAGE you to describe
 how you used such tools** in your `remarks.md` file.
 
-You may use git, or services such as [GitHub](https://www.github.com)
-to develop and maintain your submission.  However, we **DISLIKE**
-submissions that **require** them in order to build/compile your submission.
+In short: You created it, you own it, and its an original work, or you have explicit permission.
 
-Submissions will be judged in an environment that has no **IDE**.
-Any submission that fails to compile/build because it requires
-an **IDE** will be rejected.
-
-We will use the `make(1)` tool, your `Makefile`, and other tools found in
-[Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
-environments and systems that conform to the [Single UNIX
-Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
-in the building and compiling of your submission.
-
-We do realize that there are holes in the [rules](rules.html), and invite
-submitters to attempt to exploit them.  We may award '**Worst abuse of the
-[rules](rules.html)**' or '**Best abuse of the [rules](rules.html)**' or some
-variation and then plug the hole next year.
-
-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 fewer than 2^7+1 reasons why these [IOCCC
-guidelines](guidelines.html) seem obfuscated.
-
-**IMPORTANT:** Be sure that **your submission works** as documented in your
-`remarks.md` file.  We sometimes make an effort to debug a submission
-that has a slight problem, particularly in or near the final round.
-On the other hand, we have seen some otherwise excellent submissions
-fall down because they didn't work as documented.
-
-If you submission has bugs and/or mis-features, you are **MUCH BETTER** off
-documenting such bugs and/or mis-features in your `remarks.md` file.
-
-Consider an example of a [prime number](https://en.wikipedia.org/wiki/Prime_number)
-printing program that claims that 16 is a prime number.
-Noting such a bug in your `remarks.md` file could save your submission:
-
-> "_this submission sometimes prints the 4th power of a prime by mistake_"
-
-Sometimes a strange bug or (mis-)feature can even help the submission!  Of course, a correctly
-working submission might be better.
-
-We tend to look down on a [prime
-number](https://en.wikipedia.org/wiki/Prime_number) printer that claims that
-16 is a prime number.
-Clever people will note that 16 might be prime
-under certain conditions.  ;-)  Wise people, when submitting something clever
-will fully explain such cleverness in their submission's `remarks.md` file.
-
-People who are considering to just use some complex mathematical
-function or state machine to spell out something such as "_hello,
-world!_" **really really, _and we do mean REALLY_, do need to be more creative**.
-
-Ultra-obfuscated programs are, in some cases, easier to
-deobfuscate than subtly-obfuscated programs.  Consider using
-misleading or subtle tricks layered on top of or under an
-appropriate level of obfuscation.  A clean looking program with
-misleading comments and variable names might be a **VERY GOOD START**
-to a great submission!
+See FAQ on "[May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?](../faq.html#ai)".
 
 
 Jump to: [top](#)
 
 
-<div id="mkiocccentry">
-# `mkiocccentry`
-</div>
-
-[Rule 17 - Packaging](rules.html#rule-17---packaging)
-(the `mkiocccentry(1)` rule) states that
-you **REALLY SHOULD** use the `mkiocccentry(1)` tool to package your submission tarball.
-
-See the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
-for the `mkiocccentry(1)` tool and below for more details.
-
-**IMPORTANT NOTE**: make **CERTAIN** you have the most recent version of the
-`mkiocccentry` toolkit! See the
-FAQ on "[obtaining the mkiocccentry toolkit](../faq.html#obtaining_mkiocccentry)".
-
-`mkiocccentry` runs a number of checks, by the tool itself and by executing
-other tools, _before_ packaging your xz compressed tarball, including running
-`chksubmit(1)` on the submission directory.
-
-If `mkiocccentry` encounters an **error**, the program will exit and the xz
-compressed tarball **will not be formed**. For instance, if
-[chksubmit](#chksubmit) fails to validate the submission directory, either because
-of a validation error in the `.auth.json` or `.info.json`
-[JSON](https://www.json.org/json-en.html) files or because of
-something else that `mkiocccentry(1)` creates or does, it is an
-**error** and **possibly** a bug that you should [report as a bug at the
-mkiocccentry bug report
-page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E).
-**PLEASE run the `bug_report.sh` script to help us out here!**  See the
-FAQ on "[reporting mkiocccentry bugs](../faq.html#mkiocccentry_bugs)".
-
-Once the tarball is packaged it will
-run `txzchk(1)`, which will also run `fnamchk(1)`, as part of its algorithm.
-
-However, even if `mkiocccentry` or one of the tools it invokes reports an error,
-it **does not** necessarily mean it is a bug in the code. It might be an issue with
-your submission. Thus if you report an error as a bug it might not be something
-that will be fixed as there might not be anything wrong with the tools.
-
-On the other hand, some conditions flagged by `mkiocccentry(1)` are **warnings**
-and it allows you to override these, if you wish. If you're brave enough you can
-use the `-W` option to ignore all warnings but this is a big risk; the `-y`
-option will assume '_yes_' to most questions but this is also a big risk. Using
-`-Y` will say '_yes_' to even more prompts. Needless to say, we do **NOT**
-recommend these options.
-
-In many places it will prompt you to verify what you input, allowing you to
-correct details as you go along. Be advised that there is a default answer and
-if you press enter it will proceed with that default, so make sure you have
-provided the correct answer.
-
-If you wish to **test** that your submission passes the `mkiocccentry(1)` tests
-without having to type in in answers each time, you can use the `-d` or `-s seed`
-option to `mkiocccentry` for the tool to pseudo-randomly create answers for you.
-For example:
-
-``` <!---sh-->
-    mkiocccentry -d workdir topdir
-```
-
-**IMPORTANT NOTE**: if you run an IOCCC related tool outside the repo directory
-(specifying the absolute or relative path to the tool) and you have not
-installed the tools (and we **STRONGLY** recommend you **do** install them),
-then you will have to specify the options (such as paths) for the tools that are required like
-`chksubmit(1)`, `txzchk(1)` and `fnamchk(1)`.
-
-Make sure you have
-the latest version of of the [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
-so that you do not violate
-[Rule 17 - Packaging](rules.html#rule-17---packaging)
-by mistake.
-
-
-Jump to: [top](#)
-
-
-<div id="mkiocccentry-synopsis">
-## `mkiocccentry(1)` synopsis
-</div>
-
-The synopsis of the `mkiocccentry(1)` tool is:
-
-``` <!---sh-->
-    mkiocccentry [options] workdir topdir
-```
-
-To help you with editing a submission, the `mkiocccentry(1)` tool has
-some options to write _OR_ read from an answers file so you do not have to input
-the information about the author(s) and the submission more than once, unless of
-course you need to make some changes, in which case you can use the option that
-overwrites the file. If you do use the overwrite option, **MAKE SURE** you do
-not overwrite another file!
-
-See the
-FAQ on the
-"[mkiocccentry tool](../faq.html#mkiocccentry)"
-for how to use this tool and the
-FAQ on the
-"[finer details of mkiocccentry](../faq.html#mkiocccentry_details)"
-for even more information.
-
-
-<div id="tools">
-# Other mkiocccentry tools
-</div>
-
-The `mkiocccentry(1)` tool will execute a number of tools, some of which will
-execute one or more additional tools.
-
-<div id="iocccsize">
-## `iocccsize`
-</div>
-
-`mkiocccentry(1)` will use code from `iocccsize(1)` which detects a number of
-issues (such as [Rule 2 - Size](rules.html#rule-2---size)) that you may ignore, if you wish, as
-noted above.
-
-In other words, you no longer need to run `iocccsize` manually. However, the
-checks described above are still made but through the `mkiocccentry(1)` tool itself.
-
-Jump to: [top](#)
-
-
-<div id="chksubmit">
-## `chksubmit`
-</div>
-
-`mkiocccentry(1)` will write two JSON files: `.auth.json` and
-`.info.json`. These files contain information about the author(s) and about the
-submission. After these files are formed, the `chksubmit(1)` tool will be run on
-the submission directory; this tool not only validates the two JSON files
-(and runs specific checks on them after validating the JSON), but it also
-verifies that what is in the manifest in `.info.json` matches the contents of
-the directory, in addition to other checks. If `chksubmit(1)` fails to validate
-anything at all, your submission **WILL BE** rejected!
-
-**IMPORTANT**: although `chksubmit(1)` validates the files in the directory, it
-only inspects the contents of the two JSON files; it performs other kinds of
-checks on the other files, and those checks are run on the two JSON files as
-well.
-
-If you submit your own JSON files (other than `.auth.json` and
-`.info.json`) then they do **NOT** have to be valid JSON.
-However, if you do provide such invalid JSON files, **PLEASE**
-document and explain this in your `remarks.md` file.
-
-<p class="leftbar">
-On the other hand, some people might question what actually constitutes a valid
-JSON file. :-)
-</p>
-
-If `chksubmit` does not pass and you used `mkiocccentry(1)` it is **very likely** a
-bug and you should [report it as a bug at the mkiocccentry issues
-page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E).
-**PLEASE** run the command:
-
-``` <!---sh-->
-    make bug_report
-```
-
-from the top level repo directory itself and attach the bug report file (it will
-tell you the name of the file). See also the
-FAQ on "[reporting mkiocccentry bugs](../faq.html#mkiocccentry_bugs)".
-
-Assuming that `chksubmit(1)` successfully validates your submission directory,
-the tarball will be formed and then `txzchk(1)` will be executed on it. In this
-case, there should be no problems, as `mkiocccentry(1)` should **NOT** form a
-tarball if there are any issues.
-
-If `mkiocccentry(1)` is used and `chksubmit(1)` fails to validate your submission
-directory, then unless it is a system specific problem, it could be a bug in
-`mkiocccentry(1)`, `chksubmit(1)` or possibly `jparse`, although this is unlikely.
-Nonetheless, if you believe there is a bug, you may report it as explained above.
-
-If you want to know what `.auth.json` is, see the
-FAQ on "[.auth.json](../faq.html#auth_json)".
-If you want to know what the `.info.json` file is, see the
-FAQ on "[.info.json](../faq.html#info_json)".
-On the other hand, if you want to know a bit more details about `chksubmit(1)`, see the
-FAQ about "[chksubmit](../faq.html#chksubmit)".
-
-`chksubmit` uses the `jparse` library. See the
-[jparse
-README.md](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/README.md)
-in the [mkiocccentry GitHub repo subdirectory
-jparse](https://github.com/ioccc-src/mkiocccentry/tree/master/jparse) as well as
-the [jparse library README.md
-file](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jparse_library_README.md)
-in the [mkiocccentry GitHub repo subdirectory
-jparse](https://github.com/ioccc-src/mkiocccentry/tree/master/jparse), for more
-details.
-
-The `jparse` parser, library and tools were co-developed by [Cody Boone
-Ferguson](../authors.html#Cody_Boone_Ferguson) and [Landon Curt
-Noll](http://www.isthe.com/chongo/index.html) in 2022-2025 and come from the
-[jparse repo](https://github.com/xexyl/jparse). However, the **mkiocccentry
-tools use a _clone_** of the [jparse repo](https://github.com/xexyl/jparse) **at
-a _specific_ release**.  Thus the `mkiocccentry` will at times be behind the
-[jparse repo](https://github.com/xexyl/jparse)!
-
-You do **NOT need to install** `jparse` from the [jparse
-repo](https://github.com/xexyl/jparse)! The `mkiocccentry` tools link in the
-static library from `mkiocccentry`'s _clone_.
-
-The `mkiocccentry` toolkit _also_ has a clone of _both_ the [dbg
-library](https://github.com/lcn2/dbg) and the
-[dyn_array library](https://github.com/lcn2/dyn_array); the [dyn_array
-library](https://github.com/lcn2/dyn_array) uses the [dbg
-library](https://github.com/lcn2/dbg) and the [jparse
-library](https://github.com/xexyl/jparse) uses both libraries but unlike in the
-[jparse repo](https://github.com/xexyl/jparse), the libraries do not need to be
-installed separately, in order to use the tools in `mkiocccentry`.
-
-In other words, `mkiocccentry` **contains everything** you need, and _even if you
-do install_ the libraries from their respective repos, it/they will **not be
-used** when compiling the `mkiocccentry` tools. This is important to
-make sure that you're using the correct versions, which is also verified by
-`chksubmit` (in the JSON files created by `mkiocccentry(1)`). See
-[Rule 17 - Packaging](rules.html#rule-17---packaging)!
-
-<p class="leftbar">
-We **HIGHLY** recommend you install the `mkiocccentry` toolkit, however.
-</p>
-
-Please see the
-FAQ on "[validating your submission directory](../faq.html#chksubmit)
-for more details on `chksubmit(1)`.
-
-You might also wish to see the
-FAQ on "[.auth.json](../faq.html#auth_json)"
-and the
-FAQ on "[.info.json](../faq.html#info_json)"
-for much more information on these files.
-
-
-Jump to: [top](#)
-
-
-<div id="txzchk">
-## `txzchk`
-</div>
-
-`txzchk(1)` performs a wide number of sanity checks on the xz compressed
-tarball; if any issues are found ('`feathers are stuck in the tarball`' :-) )
-**AND if and _ONLY IF_ you used `mkiocccentry(1)`**, then it is **possibly** a
-bug in one of the tools and you might want to [report it as a bug at the
-mkiocccentry bug report
-page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E).
-**PLEASE run the `bug_report.sh` script to help us out here!** You may do this
-by running from the top level directory of the repo `make bug_report`. See the
-FAQ on "[reporting mkiocccentry bugs](../faq.html#mkiocccentry_bugs)".
-
-As part of its algorithm, `txzchk(1)` will run `fnamchk(1)` on the
-_tarball_ to verify that the _filename_ is valid. See the
-FAQ on "[fnamchk](../faq.html#fnamchk)"
-and the [fnamchk section](#fnamchk) below for more details on this tool.
-
-It is beyond the scope of this document to discuss the many tests that
-`txzchk(1)` performs; if you wish to know, we refer you to the [source
-code](https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c) or the man
-page. You might just find a fun option if you do either of these!
-
-Of course, as `txzchk` does not extract the tarball, it is possible that if you
-manually package your submission tarball and/or find and exploit a missing
-check, you could still be violating
-[Rule 17 - Packaging](rules.html#rule-17---packaging).
-
-<div id="extra-files">
-## Including optional and extra files
-</div>
-
-<p class="leftbar">
-The maximum total number of _extra files_ that may be submitted is 31.
-</p>
-
-<p class="leftbar">
-An _extra file_ is defined as a file that is not `prog.c`, `prog.alt.c`,
-`try.sh`, `try.alt.sh`, `remarks.md`, `Makefile`, `.auth.json` and `.info.json`:
-unless it's not in the top level directory, in which case it **IS** an _extra
-file_. The non-extra files are considered _free files_.
-</p>
-
-<p class="leftbar">
-Of course any dot file that is not `.auth.json` and `.info.json` will result in
-a violation of
-[Rule 17 - Packaging](rules.html#rule-17---packaging),
-regardless of its depth.
-</p>
-
-If you use an optional filename for something other than their intended use
-in order to get past the file limit, we will consider that an
-abuse of rules.
-
-<p class="leftbar">
-For information on the `try` script files see the
-FAQ on the "[try.sh script system](../faq.html#try_script)"
-and for more details on alt code (including the `try.alt.sh` script) see the
-FAQ on "[alt code](../faq.html#alt_code)".
-</p>
-
-<p class="leftbar">
-If you really **MUST** include more files than the limit allows, then you may do
-so by including as an extra file, a tarball. This does **NOT** have to pass
-`txzchk(1)` tests; only the submission tarball must pass the `txzchk(1)` tests.
-</p>
-
-<p class="leftbar">
-You **MUST** justify including extra files beyond the limit, should you do so.
-Even so this does not mean it will be considered valid.
-</p>
-
-<p class="leftbar">
-If you use a tarball for a depth beyond the maximum, you **MUST** justify this
-as well. Even so this does not mean it will be considered valid.
-</p>
-
-If you **DO** include a tarball, and the build process or the program extracts
-said tarball(s), the make `clobber` rule **MUST** remove the extracted files.
-
-**IMPORTANT REMINDER**: make **SURE** your tarball does **NOT** reveal who you are!
-The `mkiocccentry(1)` tool creates a v7 format tarball to prevent this. You can
-do the same like:
-
-``` <!---sh-->
-    tar --format=v7 -cJf foo.txz directory
-```
-
-See
-[Rule 17 - Packaging](rules.html#rule-17---packaging)
-and also the
-FAQ on "[maximum number of files](../faq.html#max-files)".
-
-If you do not follow these points, you
-are at a great risk of violating
-[Rule 17 - Packaging](rules.html#rule-17---packaging)!
-
-**NOTE**: if you want to include a test-suite that requires a lot of files,
-please suggest this in your `remarks.md` and if your submission wins it can
-be done. In other words you should NOT use a tarball for a test-suite unless you
-have a very good reason for this (and if you do, make **SURE** you specify why
-in your `remarks.md` file).
-
-See also the
-FAQ on "[txzchk](../faq.html#txzchk)".
-
-Jump to: [top](#)
-
-
-<div id="fnamchk">
-## `fnamchk(1)`
-</div>
-
-As an important part of its algorithm, [txzchk&lpar;1&rpar;](#txzchk) directly executes
-`fnamchk(1)`.  If the filename is invalid (or the filename does not match the
-directory name of the tarball) then it is an **error** and you risk violating
-[Rule 17 - Packaging](rules.html#rule-17---packaging).
-Nevertheless, you can run the tool manually,
-should you wish to.
-
-For more information on `fnamchk` and how to manually validate your submission
-tarball filename, see the
-FAQ on "[fnamchk](../faq.html#fnamchk)".
-
-It is extremely unlikely that `fnamchk(1)` reporting an invalid filename is a
-bug in `fnamchk(1)` and as such, ignoring such an issue risks violating
-[Rule 17 - Packaging](rules.html#rule-17---packaging)
-which is a big risk. Of course, using `mkiocccentry(1)`
-would prevent this from happening as it would not create such a file anyway. If
-`mkiocccentry(1)` was used it would rather suggest a bug in one of the tools and
-you should [report it as a bug at the mkiocccentry issues
-page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E).
-See the
-FAQ on "[reporting mkiocccentry bugs](../faq.html#mkiocccentry_bugs)".
-
-As you can see, the use of `mkiocccentry(1)` is **HIGHLY RECOMMENDED**, and at
-the risk of stating the obvious, you run **A VERY BIG RISK** of having
-your submission rejected if you package your own tarball, and there are **ANY
-problems**. For instance, if `chksubmit(1)` found a problem in your `.info.json`
-file, the `mkiocccentry(1)` tool would not package it. But if you were to package
-it manually, you would be violating
-[Rule 17 - Packaging](rules.html#rule-17---packaging).
-But even if
-everything checks out OK you should **NOT** assume that everything **IS** OK.
-
-<div id="bugs">
-# Problems and/or bugs in the mkiocccentry toolkit
-</div>
-
-Although the tools have been tested extensively, it is nonetheless possible for bugs to
-exist in the code, as all programmers know. In this case, **please** ask for help or report what
-you think is a bug via the [bug report issues page in the mkiocccentry
-repo](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E).
-
-Of course, it is also possible for `mkiocccentry(1)`, or one or more of the
-tools it executes (or another tool executes), to fail, but **NOT** because of a
-bug. An example problem is if there is not enough memory available or if some
-other library or syscall fails. Nonetheless it might be worth reporting as a
-bug; it is a judgement call: if it's a bug it'll be addressed and if it's not
-that's OK too!
-
-
-<div id="make">
-<div id="makefile">
-# Makefiles
+<div id="guideline11">
+<div id="guideline-11---abuse">
+# Guidelines for [Rule 11 - Abuse](rules.html#rule-11---abuse)
 </div>
 </div>
 
-We **recommend** AND **encourage** you to use the example Makefile,
-as the starting point for your submission's required `Makefile`:
+We try to avoid limiting creativity in our [IOCCC rules](rules.html) so
+we leave the contest open for creative rule interpretation.
 
-- [view example Makefile](%%REPO_URL%%/next/Makefile.example)
-- <a href="Makefile.example" download="Makefile">download example Makefile</a>
+We do realize that there are holes in the [IOCCC rules](rules.html), and invite
+submitters to attempt to exploit them.
 
-Feel free to modify the `Makefile` to suit your obfuscation
-needs.
+We sometime award '**Best abuse of the rules**' or '**Worst abuse of the rules**',
+or some variation to a submission that creatively attempts to exploit a holes in the
+[IOCCC rules](rules.html).
 
-**Please** add a space between the `=` and the value of variables, in the
-`Makefile`, making sure that the `=` comes immediately after the name. See the
-example `Makefile` for examples.
+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.
 
-<p class="leftbar">
-This helps us fit the Makefile into a winning entry, should your submission win.
-</p>
-
-The rest of this section and its subsections will assume that you are using some
-variant of the example `Makefile`, again renamed as `Makefile`.
-
-We suggest that you compile your submission with a commonly available
-`-std=gnu17` (ISO C 2017 with GNU extensions) C compiler, via `clang(1)`
-and/or `gcc(1)`.
-
-<div id="cflags">
-<div id="flags">
-## Default compiler flags
-</div>
-</div>
-
-Unless you **clearly state** otherwise in your `remarks.md` file, **AND** put in
-your submission's `Makefile`, we **will** compile using `-std=gnu17 -O3`!
-
-It **is OK** if you need to require your submission to **NOT be** compiled
-using the default `-std=gnu17 -O3` settings.  Simply **explain why**
-your submission should NOT be compiled using `-std=gnu17 -O3` in
-your `remarks.md` file, **AND** adjust your `Makefile` accordingly.
-
-<p class="leftbar">
-You really should **NOT** redefine `CC` because doing so makes it less portable. <-- **Hint!**
-</p>
-
-One reason that you might have to change the flags, is that the optimiser is
-known to break some programs, but there are certainly other possible valid
-reasons. Again, just update the `Makefile` and explain it in your `remarks.md`.
-See the [optimiser section](#optimiser) for details for changing optimiser
-flags.
-
-For more fun when it comes to optimisers breaking code, see
-[1986/marshall/compilers.html](../1986/marshall/compilers.html).
-
-
-<div id="compilers">
-## Default compiler
-</div>
-
-**IMPORTANT NOTE**: The use of `-std=gnu17` does **NOT** imply the use of the `gcc`
-compiler!  We often start by compiling using the **clang** C compiler instead.
-
-**PLEASE NOTE**: in macOS, the compiler `gcc` found at `/usr/bin/gcc` is
-in truth the `clang` compiler, as `/usr/bin/gcc --version` will show!
-
-
-<div id="cstd">
-<div id="standard">
-## C standard
-</div>
-</div>
-
-You may change the standard under which your submission is compiled
-by modifying the `CSTD` Makefile variable.  For example, to use `c99` instead:
-
-``` <!---make-->
-    CSTD= -std=c99
-```
-
-<div id="opt">
-<div id="optimization">
-<div id="optimisation">
-<div id="optimizer">
-<div id="optimiser">
-## Default optimisation level
-</div>
-</div>
-</div>
-</div>
-</div>
-
-You may change the level of optimization and compiler debug level
-that your submission is compiled with, by modifying the `OPT` Makefile variable.
-For example, to compile without optimization, and to include debug symbols:
-
-``` <!---make-->
-    OPT= -O0 -g3
-```
-
-<div id="warnings">
-<div id="cwarn">
-## Compiler warnings
-</div>
-</div>
-
-The default warning flags are set via the `CWARN` variable, as shown in the
-example `Makefile`:
-
-``` <!---make-->
-    # Common C compiler warning flags
-    #
-    CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN}
-```
-
-For details on `CSILENCE` and `CUNKNOWN`, see the [section on disabling
-warnings](#disabling-warnings).
-
-<div id="weverything">
-### The `-Weverything` option
-</div>
-
-For compilers, such as `clang`, that have the `-Weverything` option,
-while you may wish to try it, you should read our
-FAQ on "[clang -Weverything](../faq.html#weverything)".
-We do **NOT** recommend that you put
-the use of `-Weverything` into your submission's `Makefile` for the reasons
-cited there. This goes even if your version does not trigger a warning as some
-other version might!
-
-On the other hand, if `${CC}` has "`clang`" in the name, the example `Makefile` will
-automatically enable `-Weverything`, so you might have to use `-Wno-foo`
-options anyway, as detailed below. See the
-FAQ on "[-Weverything](../faq.html#weverything)"
-for more details.
-
-If "`clang`" is NOT in `${CC}`, the `CWARN` variable will not be further
-modified.
-
-There is no real penalty for compiler warnings.  Sometimes
-compiler warnings cannot be helped: especially in the case of
-obfuscated C.  :-)  So if you cannot easily get rid of a compiler
-warning, try not to fret too much.
-
-We **LIKE** code that has a minimum of warnings, especially under the
-more strict ` -Wall -Wextra -pedantic` mode:
-
-``` <!---make-->
-    CWARN= -Wall -Wextra -pedantic
-```
-
-The two previous guidelines might be thought by some as being somewhat
-contradictory.  Isn't life, and isn't trying to satisfy "contradictory customer
-requirements" all too often like that?  :-)  Try to minimize warnings if you
-can.
-
-If you manage to produce very few warnings, or perhaps no warnings at
-all under the `-Wall -Wextra -pedantic` mode, then by all means brag about it in
-your `remarks.md` file **AND BE SURE TO TELL US** the OS, OS version, compiler
-and compiler version in which you observed this occurring (in case our OS and
-compiler produces a different result: so your submission won't be penalized for
-not meeting your claims).
-
-On the other hand, some warnings cannot be disabled and are enabled by compilers
-without any warning option specified. These are sometimes inevitable in
-obfuscated code and even in some non-obfuscated code, and you should not worry
-about this, though it might be worth pointing out.
-
-For instance, some compilers like to warn about use of pointers as arrays, which seems to
-be dubious, as it obviously can't (always) be avoided, being a big part of C, so
-you should not worry about this either; this is the warning
-`-Wunsafe-buffer-usage` and the way to disable it is `-Wno-unsafe-buffer-usage`.
-See also the
-FAQ on "[forced warnings](../faq.html#forced_warnings)"
-and the
-FAQ on "[-Weverything](../faq.html#weverything)".
-
-<div id="disabling-warnings">
-## Disabling warnings
-</div>
-
-<p class="leftbar">
-If you do have to disable warnings due to `-Weverything` automatically being
-included, you might wish to state this fact in your `remarks.md` file.
-And even without `-Weverything` there can be warnings, as noted above.
-</p>
-
-If your submission issues lots of warnings but is otherwise
-marvelously obfuscated in multiple levels, don't worry about it.  Nevertheless,
-be sure that the warnings do not constitute a potential "**show stopper**"
-compiler problem.  Be sure that compilers such as both `gcc` and `clang` won't
-produce a compiler **error** and refuse to compile your code: unless for some
-reason that is what you intend to happen in which case document that too in your
-`remarks.md` file.  :-)
-
-All other things being equal, a program that must turn off fewer
-warnings will be considered better, for certain values of better.
-
-To turn off a compiler warning, in your submission's `Makefile`,
-try something such as:
-
-``` <!---make-->
-    CSILENCE= -Wno-some-thing -Wno-another-thing
-```
-
-<p class="leftbar">
-For instance:
-</p>
-
-``` <!---make-->
-    CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation
-```
-
-<div id="macros">
-## Defining macros in the Makefile
-</div>
-
-If you need to define something on the compile line, use
-the `CDEFINE` Makefile variable.  For example:
-
-``` <!---make-->
-    CDEFINE= -Dfoo -Dbar=baz
-```
-
-**NOTE**: just because we offer a default way to use the `-D` option, we still
-do not like excess use of `-D` to get past size limits, especially since you
-could use `#define` in your code instead.
-
-<div id="include">
-## Include files in the Makefile
-</div>
-
-If you need to include a file (as in `#include`) on the command line, use the
-`CINCLUDE` Makefile variable.  For example:
-
-``` <!---make-->
-    CINCLUDE= -include stdio.h
-```
-
-
-<div id="magic">
-## Magic in the Makefile
-</div>
-
-If you need to add other "**magic**" flags to your compile line,
-use the `COTHER` Makefile variable.  For example:
-
-``` <!---make-->
-    COTHER= -fno-math-errno
-```
-
-**NOTE**: **We only recommend using "_magic_" flags if _BOTH_ `gcc`
-_and_ `clang`** support it.
-
-Again, please note that in macOS, `/usr/bin/gcc` is actually `clang`!
-
-
-<div id="clobber">
-## The clobber rule
-</div>
-
-When `make clobber` is invoked, we request that submissions be restored
-to their original submission state.  For example, any temporary files
-(**including** the compiled program(s)) created during the build process, or
-during execution should be removed by the `clobber` rule. In other words, the
-only things that should be in the directory after running `make clobber` is what
-is in your submission tarball itself.
-
-While people are free to manage their submission under `git(1)` or even use a
-GitHub repo, dot-files and dot-directories such as `.git` are not allowed in a
-submission.
-
-The `mkiocccentry(1)` tool will ignore dot-files and dot-directories (such as
-`.vimrc`, `.bashrc`, `.git` and `.github`) and not put them in the submission's
-compressed tarball. So while you may use such files and
-directories to help develop your submission, they won't be included when you run
-the `mkiocccentry(1)` tool.
-
-Even if you did manage to get dot files or dot directories in the tarball
-somehow, `txzchk(1)` will flag it as an error. When the judges run `txzchk(1)`
-on the uploaded submission compressed tarball, if anything is wrong, for
-instance if you "sneak in" any dot files or dot directories, the submission
-**WILL BE REJECTED** for violating
-[Rule 17 - Packaging](rules.html#rule-17---packaging)!
-
-You may use whatever tools you need to develop your submission, including the
-use of `git(1)` or `gh(1)`, just be sure that your submission code and your
-submission Makefile don't depend on such tools.
-
-Of course if you do use GitHub to work on your submission, you might want to
-make the repo private so you don't reveal who you are. :-)
-
-<p class="leftbar">
-In other words, make **SURE** you keep anonymous who submitted the code!
-</p>
-
-<p class="leftbar">
-Please do **NOT** use these tools to help with the
-`clobber` rule! For instance, do **NOT** use `git clean`! Not only does this
-depend on the user having `git(1)` but it also does not account for the
-submission tarballs. Even worse is when someone does have it in a `git(1)` repo
-it will remove files that are not under `git(1)` control! Instead, see the
-`clobber` rule in the example Makefile to see how to manage this.
-</p>
-
-In other words, for `make clobber`, do something like:
-
-
-``` <!---makefile-->
-    clobber:
-            ${RM} -f foo bar baz
-```
-
-and **NOT** something like this:
-
-``` <!---makefile-->
-    # do NOT do this!
-    clobber:
-            -git clean -f   # WRONG !!!
-```
-
-And do **NOT** use `git` for any other `Makefile` rule either.
-
-
-**NOTE**: `mkiocccentry(1)` will directly run `make clobber` in the submission
-directory. And although it is not an error if this fails, if it fails because the
-Makefile does not have a clobber rule, it will be flagged by `mkiocccentry(1)`
-(you may ignore this but it does put you at a risk of violating the rules).
-
-
-Jump to: [top](#)
-
-
-<div id="likes">
-<div id="dislikes">
-# OUR LIKES AND DISLIKES:
-</div>
-</div>
-
-We **VERY MUCH LIKE** submissions that use an edited variant of the
-example Makefile, as described and linked to in the [Makefile section](#makefile),
-renamed as `Makefile` of course.  This makes it easier for the [IOCCC judges](../judges.html)
-to test your submission. And if your submissions wins, it makes it easier to integrate it into
-the [Official IOCCC winner website](https://www.ioccc.org/index.html).
-
-We **VERY MUCH LIKE** submissions that have some educational value. This does **NOT** mean
-that your submission should not be obfuscated but rather that the IOCCC has moved away from
-the idea of "spoilers". You should not encrypt or rot13 content in your `remarks.md` file.
-
-It is **VERY MUCH** appreciated if your remarks have some educational
-value. And although educational value is not required, it is an
-**EXCELLENT** bonus.
-
-
-We **LIKE** submissions that use an edited version of the
-`try.sh` example script (and if you have alternate code,
-the same applies with the `try.alt.sh` script):
-
-- [view example try.sh](%%REPO_URL%%/next/try.sh)
-- <a href="try.sh">download example try.sh</a>
-
-- [view example try.alt.sh](%%REPO_URL%%/next/try.alt.sh)
-- <a href="try.alt.sh">download example try.alt.sh</a>
-
-Of course, it is quite possible that only one invocation is
-possible, so it is not necessarily detrimental to your submission if you do not
-include one, though we do like interesting and creative uses of submissions. See
-also the
-FAQ on "[submitting try.sh and try.alt.sh scripts](../faq.html#try_scripts)".
-
-<p class="leftbar">
-Even if it only has one invocation we still **LIKE** the try scripts.
-</p>
-
-<p class="leftbar">
-If you do include a `try.sh` then **PLEASE** remove the `try` rule in the
-Makefile.
-</p>
-
-<p class="leftbar">
-If you do include a `try.alt.sh` then **PLEASE** remove the `try.alt` rule in
-the Makefile.
-</p>
-
-<p class="leftbar">
-If you don't have a prog.alt.c, then **PLEASE** remove the `try.alt` rule as
-well.
-</p>
-
-Doing masses of `#define`s to obscure the source has become 'old'.  We
-tend to 'see thru' masses of `#define`s due to our pre-processor tests
-that we apply.  Simply abusing `#define`s or `-Dfoo=bar` won't go as far
-as a program that is more well rounded in confusion.
-
-**Many** C compilers **DISLIKE** the following code, and so do we:
-
-``` <!---c-->
-    #define d define
-    #d foo             /* <-- don't expect this to turn into #define foo */
-```
-
-In other words, it is a compilation error, and in order to get older
-IOCCC winning entries that did this to compile, we had to update them to not do this.
-
-When declaring local or global variables, you should declare the type:
-
-``` <!---c-->
-    int this_is_fine;
-    this_is_not;       /* <-- Try to avoid implicit type declarations */
-```
-
-We tend to **like _less_** a submission that requires either
-`gcc` **OR** `clang`.  **We _prefer_ submissions** that can compile
-under **BOTH** `gcc` **AND** `clang`. **Hint!**
-
-We **RECOMMEND** that the compiler flags you use in your
-submission's `Makefile` are supported by **BOTH** `gcc` **AND** `clang`.
-
-We **DISLIKE** the use of obscure compiler flags, especially
-if `gcc` and/or `clang` do not support it.  We **suggest**
-that you not use any really obscure compiler flags if you can help it.
-
-One side effect of the above is that you cannot assume the use
-of nested functions such as:
-
-``` <!---c-->
-     int main() {
-|        void please_dont_submit_this() {
-|           printf("The machine that goes BING!!\n");
-         }
-|        please_dont_submit_this();
-     }
-```
-
-On 2012 July 20, the [IOCCC judges](../judges.html) rescinded the encouragement of
-nested functions.  Such constructions, while interesting and sometimes
-amusing, will have to wait until they are required by a C standard that are
-actually implemented in **BOTH** `gcc` **AND** `clang`.
-
-We **DISLIKE** submissions that require the use of `-fnested-functions`.
-
-We prefer programs that do not require a fish license: crayons and
-cat detector vans not withstanding.
-
-If your submission uses functions that have a variable number of
-arguments, **be careful**. Systems implement `va_list` in a wide variety
-of ways.  Because of this, a number of operations using `va_list` **are
-not portable and _must not_ be used**:
-
-* assigning a non-`va_list` variable to/from a `va_list` variable
-* casting a non-`va_list` variable into/from a `va_list` variable
-* passing a `va_list` variable to a function expecting a non-`va_list` arg
-* passing a non-`va_list` variable to a function expecting a `va_list` arg
-* performing arithmetic on `va_list` variables
-* using `va_list` as a structure or union
-
-In particular, do not treat `va_list` variables as if they were a `char **`.
-
-We **DISLIKE** the use of `varargs.h`.  Use `stdarg.h` instead.
-
-We **DISLIKE** the use of `gets(3)`.  Use `fgets(3)` instead.
-
-We tend to **DISLIKE** the blatant use of tarballs in an attempt to simply get
-around the extra file number limit. We realize there may be cases where a
-tarball containing a number of extra files may be needed. Such a need for a
-tarball **MUST** be explained in the `remarks.md` file.
-
-<p class="leftbar">
-Using a mass of `goto`s to obfuscate your code has become 'old' and is unlikely
-to make it through the final rounds, if it even gets that far.
-</p>
-
-On 28 January 2007, the Judges rescinded the requirement that the
-`#` in a C preprocessor directive must be the 1st non-whitespace byte.
-
-The `exit(3)` function returns `void`.  Some broken systems have `exit(3)`
-return `int`; your submission should assume that `exit(3)` returns a `void`.
-
-<p class="leftbar">
-This _guideline_ has a change mark at the very start of this line.
-</p>
-
-Small programs are best when they are short, obscure and concise.
-While such programs are not as complex as other winners, they do
-serve a useful purpose: they are often the only program that people
-attempt to completely understand.  For this reason, we look for
-programs that are compact, and are instructional.
-
-While those who are used to temperatures found on [dwarf
-planets](https://science.nasa.gov/dwarf-planets/)
-(**yes Virginia, dwarf planets _ARE_ planets!**), such as
-[Pluto](https://science.nasa.gov/dwarf-planets/pluto/), might be able to
-explain to the Walrus why our seas are boiling hot, the question of
-whether pigs have wings is likely to remain a debatable point to most.
-
-One line programs should be short one line programs: say around **80** to **132**
-bytes long.  Going well beyond **132** bytes is a bit too long to be called
-a one-liner in our vague opinion.
-
-We tend to **DISLIKE** programs that:
-
-* are very hardware specific
-* are very OS version specific (`index(3)`/`strchr(3)` differences are OK, but
-sockets/streams specific code is likely not to be)
-* dump core or have compiler warnings (it is OK only if
-you warn us in your `remarks.md` file)
-* won't compile or run in a [Single UNIX
-Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
-environment
-* depend on a utility or application not normally found
-in systems that conform to the [Single UNIX
-Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
-* abuse the build file to get around the size limit
-* obfuscate by use of ANSI trigraphs
-* obfuscate by use of digraphs
-* are larger than they need to be
-* have more lines than they need to have
-* are "blob-ier" (just a pile of unformatted C code) than they need to be
-* are rather similar to **[previous winners](../years.html)** :-(
-* are **identical** to **[previous losers](https://en.wikipedia.org/wiki/Null_device)** :-)
-* that mandate the exclusive use of a specific Integrated Development Environment (IDE)
-
-In order to encourage submission portability, we **DISLIKE** submissions that
-fail to build unless one is using an IDE. For example, do not
-mandate that one must use Microsoft Visual Studio to compile
-your submission.
-
-The program must compile and link cleanly in a [Single UNIX
-Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
-environment. Therefore do not assume the system has a
-[windows.h](https://en.wikipedia.org/wiki/Windows.h) include file:
-
-
-``` <!---c-->
-    #include <windows.h>  /* we DISLIKE this */
-```
-
-Unless you are cramped for space, or unless you are entering the
-'**Best one liner**' category, we suggest that you format your program
-in a more creative way than simply forming excessively long lines.
-
-At least one judge prefers to maintain the use of the
-[leap-second](https://en.wikipedia.org/wiki/Leap_second)
-as part of the world's time standard.  If your code prints time
-with seconds, we prefer that your code be capable of printing the
-time of day during a leap-second where the value in seconds
-after the minute mark is **60**.
-
-The `Makefile` should not be used to try and get around the size limit.  It is
-one thing to make use of a several `-D`s on the compile line to help out, but it
-is quite another to use many bytes of `-D`s in order to try and squeeze the
-source under the size limit.
-
-Your source code, post-pre-processing, should not exceed the size of
-[Microsoft Windows](https://en.wikipedia.org/wiki/Microsoft_Windows). :-)
-
-Other windows, on the other hand, might be OK: especially where "**X
-marks the spot**".  Yet on the third hand, windows are best when they are
-"unseen" (i.e., not dirty).  :-)
-
-The [IOCCC judges](../judges.html), as a group, have a history giving wide degree of latitude
-to reasonable submissions.  And recently they have had as much longitudinal
-variation as it is possible to have on [Earth](https://science.nasa.gov/earth/).  :-)
-
-You should try to restrict commands used in the build file to commands found in
-[Single UNIX
-Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
-environments and systems that conform to the [Single UNIX
-Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification).
-
-You may compile and use your own programs.  If you do, try to build and execute
-from the current directory.  This restriction is not a hard and
-absolute one.  The intent is to ensure that the building of your
-program is reasonably portable.
-
-We prefer programs that are portable across a wide variety of UNIX-like
-operating systems (e.g., Linux, GNU Hurd, BSD, UNIX, etc.).
-
-> You are in a maze of twisty _guidelines_, all different.
-
-There are at least zero [IOCCC judges](../judges.html) who think that
-[Fideism](https://en.wikipedia.org/wiki/Fideism) has little
-or nothing to do with the IOCCC judging process.
-
-Don't forget that the building of your program should be done
-**WITHOUT human intervention**.  So don't do things such as:
-
-```
-    prog: prog.c
-        #echo this next line requires data from standard input
-        cat > prog.c
-        ${CC} prog.c -o prog
-```
-
-However, you can do something cute such as making your program
-do something dumb (or cute) when it is built 'automatically', and
-when it is run with a human involved, do something more clever.
-For example, one could put in their `Makefile`:
-
-```
-    prog: prog.c
-        ${CC} prog.c -DNON_HUMAN_COMPILE -o prog
-        @echo "See remarks section about alternate ways to compile"
-```
-
-and then include special notes in your `remarks.md` file for
-alternate / human intervention based building.
-
-We want to get away from source that is simply a compact blob of
-bytes.   **REALLY TRY** to be more creative than blob coding. **HINT!**
-
-Please do not use things like `gzip(1)` to get around the size limit.
-Please try to be much more creative.
-
-We really **DISLIKE** submissions that make blatant use of including
-large data files to get around the source code size limit.
-
-<p class="leftbar">
-We do not recommend submitting [systemd](https://systemd.io) source code to the IOCCC,
-if nothing else because that code is likely to exceed
-[Rule 2 - Size](rules.html#rule-2---size).
-This isn't to say that another highly compact and obfuscated
-replacement of `init(8)` would not be an interesting submission.
-</p>
-
-Did we remember to indicate that programs that blatantly use
-some complex state machine to do something simple, are boring?
-We think we did.  :-)
-
-> All generalizations are false, including this one. -- **Mark Twain**
-
-Given two versions of the same program, one that is a compact blob
-of code, and the other that is formatted more like a typical C
-program, we tend to favor the second version.  Of course, a third
-version of the same program that is formatted in an interesting
-and/or obfuscated way, would definitely win over the first two!
-Remember, you can submit more than one submission.  See the
-[IOCCC rules](rules.html)
-for details (in particular,
-[Rule 8 - Submission](rules.html#rule-8---submission)).
-
-We suggest that you avoid trying for the '**smallest self-replicating**'
-source.  The smallest, a [zero byte entry](../1994/smr/index.html), won in
-[1994](../years.html#1994).
-
-Programs that claim to be the smallest C source that does something, really
-better be the smallest such program or they risk being rejected because
-they do not work as documented.
-
-Please note that the C source below, besides lacking in obfuscation,
-is **NOT** the smallest C source file that when compiled and run, dumps core:
-
-``` <!---c-->
-    main;
-```
-
-Unless you specify `-fwritable-strings` (see `COTHER` in the example
-Makefile, described in the [Makefile section](#makefile)), do not assume this
-sort of code will work:
-
-``` <!---c-->
-    char *T = "So many primes, so little time!";
-    ...
-    T[14] = ';';    /* modifying a string requires: -fwritable-strings */
-```
-
-Even so, one should probably not assume that this is universally accepted.
-
-Initialized char arrays are OK to write over.  For instance, this is OK:
-
-``` <!---c-->
-    char b[] = "Is this OK";
-    b[9] = 'k';     /* modifying an initialized char array is OK */
-```
-
-There are more than 1 typos in this very sentence.
-
-X client submissions should be as portable as possible.  Submissions that
-adapt to a wide collection of environments will be favored.  For
-example, don't depend on a particular type or size of display.
-Don't assume the use of a particular browser.  Instead assume a
-generic browser that forms to a widely used [W3C
-standard](https://www.w3.org/standards/).
-Don't assume a particular sound sub-system or video driver is installed
-in the OS. Instead, make use of a well known and widely available open
-source program (one that actually works) to display audio/visual data.
-
-X client submissions should avoid using X related libraries and
-software that are not in wide spread use.
-
-As of Red Hat RHEL9.0, the X.org server is deprecated. See the
-FAQ on "[Xorg deprecation"](../faq.html#Xorg_deprecated)"
-for more details. This does not mean that a submission using this will
-necessarily be rejected, but it would be better if it can support Wayland in
-some way or another.
-
-This could be the only _guideline_ that contains the word
-[fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin).
-
-However, do you know how to play [fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin)?
-You do?!?  (Except on Tuesday?)
-
-OK, there are actually 2 _guidelines_ that contain the word
-[fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin),
-unless you count this one, in which case there are 3. :-)
-
-We **DISLIKE** submissions that use proprietary toolkits such as the `M*tif`,
-`Xv*ew`, or `OpenL*ok` toolkits, since not everyone has them.  Use an
-open source toolkit that is widely and freely available instead.
-
-**NOTE**: The previous _guideline_ in this spot has been replaced by this _guideline_:
-
-X client submissions should try to not to depend on particular items in
-`.Xdefaults`.  If you must do so, be sure to note the required lines
-in the your `remarks.md` file.  They should also not depend on any
-particular window manager.
-
-Try to avoid submissions that play music that some people believe is copyrighted
-music.
-
-While we recognize that UNIX is not a universal operating system, the contest
-does have a bias towards such systems.  In an effort to expand the scope of the
-contest, we phrase our bias to favor the [Single UNIX
-Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification).
-
-You are **well advised** to submit code that conforms to the [Single UNIX
-Specification Version 4](https://unix.org/version4/overview.html).
-
-To quote the [IOCCC judges](../judges.html):
-
-> You very well might not be completely prohibited from failing to not partly
-misunderstand this particular _guideline_, but of course, we could not possibly
-comment!  :-)  Nevertheless, you are neither prohibited, nor are you fully
-required to determine that this or the previous sentence is either false and/or
-perhaps misleading.  Therefore, it might be wise for you to not fail to 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
-parliament should you have one.
-
-We **LIKE** programs that:
-
-* are as concise and small as they need to be
-* do something at least quasi-interesting
-* are portable
-* are unique or novel in their obfuscation style
-* make use of a **NUMBER OF DIFFERENT TYPES OF OBFUSCATIONS!**  **<== HINT!!**
-* make us laugh and/or throw up  :-)  (humor really helps!)
-* make us want to eat good chocolate
-
-Some types of programs can't excel (anti-tm) in some areas.  Your
-program doesn't have to excel in all areas, but doing well in several
-areas really does help.
-
-You are better off explaining what your submission does in your
-`remarks.md` file section rather than leaving it obscure for the
-[IOCCC judges](../judges.html) as we might miss something and/or be too tired to
-notice.
-
-Please avoid this specific individual _guideline_, if it at all possible.
-
-We freely admit that interesting, creative or humorous comments in
-your `remarks.md` file help your chances of winning.  If you had to
-read so many twisted submissions, you too would enjoy a good laugh or two.
-We think the readers of the contest winners do as well.  We do read
-your `remarks.md` content during the judging process, so it is worth your
-while to write a remarkable `remarks.md` file.
-
-We **DISLIKE** C code with trailing control-M's (`\r` or `\015`) that results
-in compilation failures.  Some non-UNIX/non-Linux tools such as
-MS Visual C and MS Visual C++ leave trailing control-M's on lines.
-Users of such tools should strip off such control-M's before submitting
-their submissions.  In some cases tools have a "Save As" option that will
-prevent such trailing control-M's being added.
-
-One should restrict libcurses to portable features found on BSD
-or Linux curses.
-
-<p class="leftbar">
-If you do `#include <curses.h>` make **CERTAIN** you link in curses (i.e.
-`-lcurses`) and not ncurses (i.e. `-lncurses`).
-</p>
-
-[Rule 13 - Newlines](rules.html#rule-13---newlines)
-no longer discourages the use of UTF-8
-characters in C code.
-
-It is a very good idea to, in your `remarks.md` file, tell us why you
-think your submission is obfuscated.  This is particularly true if
-your submission has some very subtle obfuscations that we might
-otherwise overlook.  **<<-- Hint!**
-
-Anyone can format their code into a dense blob.  A really clever
-author will try format their submission using a "normal" formatting style
-such that at first glance (if you squint and don't look at the details)
-the code might pass for non-obfuscated C.  Deceptive comments,
-and misleading formatting, in some cases, may be a plus.  On the
-other hand, a misleading code style requires more source bytes.
-
-If you do elect to use misleading formatting and comments, we
-suggest you remark on this point in your `remarks.md` where you talk
-about why you think your submission is obfuscated.  On the other hand,
-if you are pushing up against the size limits, you may be forced
-into creating a dense blob. Such are the trade-offs that obfuscators face!
-
-We prefer code that can run on either a 64-bit or 32-bit
-processor.  However, it is **UNWISE **to assume it will run on an
-some Intel-like x86 architecture**.
-
-We believe that Mark Twain's quote:
-
-> Get your facts first, then you can distort them as you please.
-
-... is a good motto for those writing code for the IOCCC.
-
-The IOCCC size tool source is not an original work, unless you are [Anthony C
-Howe](../authors.html#Anthony_C_Howe), in which case it is original!  :-)
-Submitting source code that uses the contents of
-[iocccsize.c](https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c),
-_unless_ you are [Anthony C Howe](../authors.html#Anthony_C_Howe), might run the
-risk of violating
-[Rule 7 - Original Work](rules.html#rule-7---original-work).
-
-The IOCCC submission tarball validator source is not an original work,
-unless you are [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson), in
-which case it is original!  :-) Submitting source code that uses the contents of
-[txzchk.c](https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c),
-_unless_ you are [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson), might
-run the risk of violating
-[Rule 7 - Original Work](rules.html#rule-7---original-work).
-
-In addition to the above tools, none of the [mkiocccentry
-tools](https://github.com/ioccc-src/mkiocccentry), _including, **but not
-limited**_ to
-[mkiocccentry](https://github.com/ioccc-src/mkiocccentry/blob/master/mkiocccentry.c),
-[chksubmit](https://github.com/ioccc-src/mkiocccentry/blob/master/chksubmit.c),
-[chksubmit](https://github.com/ioccc-src/mkiocccentry/blob/master/chksubmit.c),
-[fnamchk](https://github.com/ioccc-src/mkiocccentry/blob/master/test_ioccc/fnamchk.c)
-and
-[location](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/location_main.c),
-nor the [JSON parser and
-library](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/README.md),
-[jstrencode](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jstrencode.c),
-[jstrdecode](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jstrdecode.c)
-or any of the other [jparse
-tools](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse)
-(see the [jparse repo](https://github.com/xexyl/jparse/)), are original works,
-unless you are [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson) or
-[Landon Curt Noll](http://www.isthe.com/chongo/index.html), in which case they
-are original!  :-) Submitting source code that uses the content of any of these tools or
-library, _unless_ you are [Cody Boone
-Ferguson](../authors.html#Cody_Boone_Ferguson) or [Landon Curt
-Noll](http://www.isthe.com/chongo/index.html), might run the risk of violating
-[Rule 7 - Original Work](rules.html#rule-7---original-work).
-
-And unless you are [Landon Curt Noll](https://en.wikipedia.org/wiki/Landon_Curt_Noll),
-the code in
-[dbg](https://github.com/ioccc-src/mkiocccentry/tree/master/dbg) and
-[dyn_array](https://github.com/ioccc-src/mkiocccentry/tree/master/dyn_array) are
-not original works. Submitting source code that uses the contents of those
-libraries, _unless_ you [Landon Curt Noll](https://en.wikipedia.org/wiki/Landon_Curt_Noll),
-might run the risk of violating
-[Rule 7 - Original Work](rules.html#rule-7---original-work).
-
-[Rule 7 - Original Work](rules.html#rule-7---original-work)
-does not prohibit you from writing your own
-obfuscated versions of these tools, unless of course you are [Landon Curt
-Noll](http://www.isthe.com/chongo/index.html), in which case you _probably_
-won't win since [IOCCC judges](../judges.html) should not enter the IOCCC! :-)
-However, **_if_** you do write your own version, you **_might_** wish to make it do something
-**_more_ interesting** than simply implementing the [IOCCC](../index.html)
-tools' algorithms.
-
-Even so, we do not recommend you try and submit a JSON parser due to
-the fact it will likely exceed
-[Rule 2 - Size](rules.html#rule-2---size)
-and because you likely can't beat [flex](https://github.com/westes/flex) and
-[bison](https://www.gnu.org/software/bison/) in obfuscation. This isn't to
-say that [the so-called JSON spec](https://github.com/xexyl/jparse/blob/master/json_README.md#so-called-json-spec) is not
-obfuscated, but unless you have some really clever way to compact and
-obfuscate a JSON parser more than [flex](https://github.com/westes/flex) and
-[bison](https://www.gnu.org/software/bison/) you will likely not win, either
-because of the
-[Rule 2 - Size](rules.html#rule-2---size)
-or because it is not
-as obfuscated as the [flex](https://github.com/westes/flex) and [bison](https://www.gnu.org/software/bison/)
-generated code of
-[jparse](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse).
-
-While programs that only run in a specific word size are OK, if you have
-to pick, choose a 64-bit word size.
-
-If the [IOCCC judges](../judges.html) are feeling ornery we
-might choose to compile your program for running on an Arduino or
-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 :-)
-
-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 `ARCH` in the example
-Makefile, described in [Makefile section](#makefile)).  Do not assume a
-processor word size without specifying `-arch`.  For example:
-
-``` <!---make-->
-    ARCH= -m64
-```
-
-Note, however, that some platforms will not necessarily support some
-architectures. For instance, more recent versions of `macOS` do **NOT** support
-32-bit!
-
-If there are limitations in your submission, you are highly encouraged
-to note such limitations in your `remarks.md` file.  For example if your
-submission factors values up to a certain size, you might want to state:
-
->   This submission factors values up `2305567963945518424753102147331756070`.
-Attempting to factor larger values will produce unpredictable results.
-
-The [IOCCC judges](../judges.html) might try to factor the value -5, so you want to might state:
-
->   This submission factors positive values up
-`2305567963945518424753102147331756070`. Attempting to factor large values will
-produce unpredictable results.
-
-However the [IOCCC judges](../judges.html) might try to also factor 0, so you want to might state:
-
->   This submission factors values between 1 and
-`2305567963945518424753102147331756070`.  Attempting to factor values outside
-that range will produce unpredictable results.
-
-Moreover they might try to also factor 3.5 or 0x7, or Fred, so you want to might state:
-
->   This submission factors integers between 1 and
-`2305567963945518424753102147331756070`.  Attempting to factor anything else
-will produce unpredictable results.
-
-You submission might be better off catching the attempt to factor bogus values
-and doing something interesting.  So you might want to code accordingly and state:
-
->   This submission factors integers between 1 and `2305567963945518424753102147331756070`.
->   Attempting to factor anything else will cause the program to insult your pet fish Eric.
-
-The [IOCCC judges](../judges.html) might not have a pet fish named Eric, so you might want to state:
-
->   This submission factors integers between 1 and
-`2305567963945518424753102147331756070`.  Attempting to factor anything else
-will cause the program to insult your pet fish Eric, or in the case that you
-lack such a pet, will insult the pet that you do not have.
-
-When all other things are equal, a submission with fewer limitations will be judged
-better than a submission with lots of limitations.  So you might want to code accordingly
-and state:
-
->   This submission attempts to a factor value of any size provided that the
-program is given enough time and memory.  If the value is not a proper integer,
-the program might insult a fish named Eric.
-
-Do not fear if you're not 100% sure of the significance of
-`2305567963945518424753102147331756070` as it is not of prime importance: or is
-it?  :-)
-
-We **DISLIKE** the use of ASCII tab characters in markdown files, such as in the required `remarks.md` file.
-
-We don't mind the use of ASCII tab characters in your C code.  Feel free
-to use ASCII tab characters if that suits your obfuscation needs.  If is
-perfectly **OK** to use tab characters elsewhere in your submission, just not in
-markdown files as this tends annoy us when it comes time to
-rendering your markdown content as it complicates the process.
-
-If you do use ASCII tab characters in your non-markdown files, be
-aware that some people may use a tab stop that is different than the common 8
-character tab stop.
-
-**PLEASE** observe our [IOCCC markdown guidelines](../markdown.html)
-when forming your submission's `remarks.md` file.  And if your submission
-contains additional markdown files, please follow those same guidelines for
-those files. See also
-[Rule 4 - Files](rules.html#rule-4---files),
-and the
-FAQ on "[markdown](../faq.html#markdown)".
-
-We **LIKE** reading `remarks.md` files, especially if they contain
-useful, informative, and even humorous content about your submission.  Yes, this
-is a **hint**.  :-)
-
-We **RECOMMEND** you put a reasonable amount effort into the content of the
-`remarks.md` file: it is a required file for a reason.  :-)
-
-Try to be even more creative!
-
-
-Jump to: [top](#)
-
-
-<div id="rules_abuse">
-<div id="abusing_rules">
-# ABUSING THE RULES:
-</div>
-</div>
+Or, maybe not. :-)
 
 Legal abuse of the [IOCCC rules](rules.html) is somewhat encouraged.  Legal rule abuse
 may involve, but is not limited to, doing things that are technically allowed by
@@ -1883,293 +241,996 @@ This is one of the reasons why the [IOCCC rules](rules.html) and
 Jump to: [top](#)
 
 
-<div id="judging">
-# JUDGING PROCESS:
+<div id="guideline15">
+<div id="guideline-15---building">
+# Guidelines for [Rule 15 - Building](rules.html#rule-15---building)
+</div>
 </div>
 
-Submissions are judged by Leonid A. Broukhis and Landon Curt Noll.
+You may use git, or services such as [GitHub](https://www.github.com)
+to develop and maintain your submission.  However, we **DISLIKE**
+submissions that **require** such services in order to build/compile your submission.
 
-Each submission submitted is given a random string and subdirectory.  The
-submission files including, but not limited to `prog.c`, `Makefile`,
-`remarks.md`, `.info.json`, `.auth.json` as well as any data files that you
-submit, are all placed under their own directory and stored and judged from this
-directory.
+Submissions will be judged in an environment that has no **IDE**.
+Any submission that fails to compile/build because it requires
+an **IDE** will be rejected.
 
-Any information about the authors is not read by the [IOCCC judges](../judges.html) until
-the judging process is complete, and then only from entries that have
-won an award.  Because we do not read this information for entries that
-do not win, we do not know who did not win.
-
-The above process helps keep us biased for/against any one particular
-individual.  Therefore you **MUST** refrain from putting any information
-that reveals your identity in your submission.
-
-Now some people point out that coding and/or writing style might reveal the
-information about the authors.  However we consider this to be simply
-circumstantial and outside the scope of the above paragraph.
-
-Some people, in the past, have attempted to obfuscate their identity by
-including comments of famous Internet personalities such as [Peter
-Honeyman](http://www.citi.umich.edu/u/honey).  The [IOCCC judges](../judges.html) are on to this trick
-and therefore consider any obfuscated source or data file claiming to be from
-Honeyman to not be from Honeyman.  This of course creates an interesting paradox
-known as the "**obfuscated Peter Honeyman paradox**".  Should Peter Honeyman
-actually submit to the IOCCC, he alone is excluded from the above, as we
-will likely believe it's just another attempt at confusion.  This _guideline_ is
-known as the "**Peter Honeyman is exempt**" _guideline_.
-
-**BTW**: None of the submissions claiming to be from Peter Honeyman have ever
-won an award.  So it is theoretically possible that Peter Honeyman
-did submit to the IOCCC in the past.  In the past, Peter had denied
-submitting anything to the IOCCC.  Perhaps those submissions were
-submitted by one of his students?
-
-Hopefully we are **VERY CLEAR** on this point!  The rules now strongly state:
-**PLEASE _DO NOT_ put a name of an author**, in an obvious way, into your
-source code, `remarks.md`, data files, etc., the above "**Peter Honeyman is
-exempt**" notwithstanding.
-
-We seemed to have digressed again ... :-)  Returning to the judging process:
-
-We prefer to be kept in the dark as much as you are until the final
-awards are given.  We enjoy the surprise of finding out in the end,
-who won and where they are from.
-
-We attempt to keep all submissions anonymous, unless they win an award.
-Because the main 'prize' of winning is being announced, we make all
-attempts to send non-winners into oblivion.  We remove all non-winning
-files, and shred all related printouts.  By tradition, we do not even
-reveal the number of submissions that we receive.
-
-During the judging process, a process that spans multiple sessions over
-a few weeks, we post general updates from our [Mastodon
-account](https://fosstodon.org/@ioccc).
-
-**Make sure you reload the feed** every so often **because unless you
-are mentioned you will NOT get a push notification!**
+We will use the `make(1)` tool, your `Makefile`, as well as tools found in the
+[Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
+environments, and commonly found on systems that reasonably conform to the
+[Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
+in the building and compiling of your submission.
 
 
 Jump to: [top](#)
 
 
-<div id="rounds">
-## JUDGING ROUNDS:
+<div id="guideline17">
+<div id="guideline-17---packaging">
+# Guidelines for [Rule 17 - Packaging](rules.html#rule-17---packaging)
+</div>
 </div>
 
-Judging consists of a number of elimination rounds.  During a round,
-the collection of submissions are divided into two roughly equal piles;
-the pile that advances on to the next round, and the pile that does
-not.  We also re-examine the submissions that were eliminated in the
-previous round.  Thus, a submission gets at least two readings and
-often more than two.
+We **STRONGLY** recommend you **do** install the
+[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
+as use of using older versions of the mkiocccentry toolkit to are **HIGHLY LIKELY** to be **REJECTED**!
 
+If you submit your own JSON files (other than `.auth.json` and
+`.info.json`) then they do **NOT** have to be valid JSON.
 
-Jump to: [top](#)
-
-
-<div id="readings">
-## JUDGING READINGS:
-</div>
-
-A reading consists of a number of actions:
-
-* Reading `prog.c`, the C source and reviewing the `remarks.md` information
-* Briefly looking at any supplied data files
-* Passing the source thru the C pre-processor skipping over any `#include`d files
-* Performing a number of C beautify/cleanup edits on the source
-* Passing the beautified source thru the C pre-processor skipping over any `#include`d files
-* Compiling/building the source
-* Running the program
-* Doing other things that only [IOCCC judges](../judges.html) know about :-)
-
-In later rounds, other actions are performed including performing
-miscellaneous tests on the source and binary.
-
-This is the very **guideline** that goes, **BING!**
-
-Okay, technically that was the _second_ **guideline** that goes **BING**, and this
-is the third. :-)
-
-Until we reduce the stack of submissions down to about 25 submissions,
-submissions are judged on an individual basis.  A submission is set aside because it
-does not, in our opinion, meet the standard established by the round.
-When the number of submissions thins to about 25 submissions, we begin to form
-award categories.  Submissions begin to compete with each other for awards.
-A submission will often compete in several categories.
-
-The actual award category list will vary depending on the types of submissions
-we receive.  A typical category list might be:
-
-* **best small one line program** (see above about one line programs)
-* **best small program**
-* **strangest/most creative source layout**
-* **most useful obfuscated program**
-* **best game that is obfuscated**
-* **most creatively obfuscated program**
-* **most deceptive C code** (code with deceptive comments and source code)
-* **best X program** (see [OUR LIKES AND DISLIKES](#likes) and the FAQ on "[Xorg
-being deprecated](../faq.html#Xorg_deprecated)")
-* **best abuse of ISO C or ANSI C standard** (see above about compilers)
-* **best abuse of the C preprocessor**
-* **worst/best abuse of the rules** (or some variation)
-* (anything else so strange that it deserves an award)
-
-We do not limit ourselves to this list.  For example, a few submissions are so
-good/bad that they are declared winners at the start of the final round.
-We will invent awards categories for them, if necessary.
-
-In the final round process, we perform the difficult tasks of
-reducing the remaining submissions (typically about 25) down to to about
-half that number: declaring those remaining to be winners.
-
-Often we are confident that the submissions that make it into
-the final round are definitely better than the ones that do not
-make it.  The selection of the winners out of the final round, is
-less clear cut, however.
-
-Sometimes a final round submission is good enough to win, but is beat out by a
-similar, but slightly better submission.  For this reason, it is sometimes
-worthwhile to resubmit an improved version of a submission that failed to win in
-a previous year, the next year.  This assumes, of course, that the submission is
-worth improving in the first place!
-
-Over the years, more than one [IOCCC judge](../judges.html)
-has been known to **bribe** another [IOCCC judge](../judges.html) into voting for a
-winning submissions by offering a bit of high quality chocolate, or
-other fun item.
+However, if you do provide invalid JSON files, **PLEASE**
+document and **clearly explain** this in your `remarks.md` file.
 
 <p class="leftbar">
-Over the years some judges have submitted code that had to be rejected once it
-was discovered to be a judge.
-</p>
-
-One **should NOT** attempt to **bribe** an [IOCCC
-judge](../judges.html), **unless you are an [IOCCC judge](../judges.html)**,
-because **bribing** an [IOCCC judge](../judges.html) by a non-judge
-has been shown to **NOT** be effective when the **person _attempting_
-the _bribe_ is made known** to the [IOCCC judges](../judges.html)
-(i.e., they are not anonymous) AND/OR the **bribe** is otherwise
-associated with a submission to the [IOCCC](../index.html).
-
-With the previous guideline in mind: **anonymous** gifts
-for the [IOCCC judges](../judges.html) that are **NOT ASSOCIATED
-WITH** a submission to the [IOCCC](../index.html) may be sent to the
-[IOCCC judges](../judges.html) via the
-[IOCCC Amazon wishlist](https://www.amazon.com/hz/wishlist/ls/3HSNTEL8RQ1M0?ref_=wl_share).
-It has been shown that receiving  **anonymous** gifts provides the
-[IOCCC judges](../judges.html) with a nice
-[dopamine](https://en.wikipedia.org/wiki/Dopamine) boost, and happy
-[IOCCC judges](../judges.html) help make the [IOCCC](../index.html) better for everyone. :-)
-
-See the
-FAQ on "[supporting the IOCCC](../faq.html#support)".
-
-More often than not, we select a small submission (usually one line) and a
-strange/creative layout submission.  We sometimes also select a
-submission that abuses the [IOCCC guidelines](guidelines.html) in an interesting way,
-or that stretches the contest [rules](rules.html) that while legal, it
-nevertheless goes against the **intent** of the [rules](rules.html).
-
-Nevertheless, see
-[Rule 10 - Privileges](rules.html#rule-10---privileges).
-
-
-In the end, we traditionally pick one submission as '**best**'.  Sometimes such
-a submission simply far exceeds any of the other submissions.  More often, the
-'**best**' is picked because it does well in a number of categories.
-
-In years past, we renamed the winning submission from `prog.c` to a
-name related to the author(s)' names.  This is no longer done.
-Winning source is called `prog.c`. A compiled binary is called `prog`.
-
-
-Jump to: [top](#)
-
-
-<div id="announcements">
-# ANNOUNCEMENT OF WINNERS:
-</div>
-
-The [IOCCC judges](../judges.html) will toot initial announcement of who won, the name
-of their award, and a very brief description (award title) of the winning entry
-from the [@IOCCC Mastodon account](https://fosstodon.org/@ioccc).
-
-We recommend that you follow us on mastodon but **please make sure to
-refresh the feed** every so often (if not more often) because unless you are
-mentioned or someone boosts your post you will not get a push notification.
-
-
-Jump to: [top](#)
-
-
-<div id="winners">
-## How the new IOCCC winners will be announced
-</div>
-
-The [current status of the IOCCC](../status.html) will change from
-**[judging](../faq.html#judging)** to **[closed](../faq.html#closed)** .
-
-The **contest_status** in the [status.json](../status.json) file will change
-from **judging** to **closed** as well.
-
-When the above happens, the winning entries have been selected by the [IOCCC
-judges](../judges.html).
-
-The [IOCCC judges](../judges.html) will begin to prepare to release the source
-code of the new IOCCC winners.
-
-The [IOCCC judges](../judges.html) will commit the winning source to the
-[IOCCC winner repo](https://github.com/ioccc-src/winner) which will update the
-[Official IOCCC website](https://www.ioccc.org/index.html).
-
-The [IOCCC news](../news.html) will also contain an announcement of the winners.
-
-
-Jump to: [top](#)
-
-
-<div id="mastodon">
-## An important update to how winners are announced
-</div>
-
-<p class="leftbar">
-The IOCCC no longer uses twitter.  Winning IOCCC entries will be announced by a
-`git` commit to the [IOCCC entries repo](https://github.com/ioccc-src/winner)
-that, in turn, updates the [Official IOCCC
-website](https://www.ioccc.org/index.html).
+An _extra file_ is defined as a file that is not `prog.c`, `prog.alt.c`,
+`try.sh`, `try.alt.sh`, `remarks.md`, `Makefile`, `.auth.json` and `.info.json`:
+unless it's not in the top level directory, in which case it **IS** an _extra
+file_.
 </p>
 
 <p class="leftbar">
-In addition a note is posted to the [IOCCC Mastodon account](https://fosstodon.org/@ioccc).
+The non-extra files (`prog.c`, `prog.alt.c`,
+`try.sh`, `try.alt.sh`, `remarks.md`, `Makefile`, `.auth.json` and `.info.json`)
+are considered _free files_, and to not count towards the
+[Rule 17 - Packaging](rules.html#rule-17---packaging)
+limit of **31** _extra files_.
 </p>
 
-<p class="leftbar">
-We will also post a notice to the IOCCC discord server.
-</p>
+If you use an optional filename for something other than their intended use
+in order to get past the file limit, we will consider that an abuse of rules.
 
-Consider joining the IOCCC discord community via this link:
-[https://discord.gg/Wa42Qujwnw](https://discord.gg/Wa42Qujwnw)
+Your tarball does **NOT** reveal who you are!  For this reason, the tarball
+**MUST** be a **v7 format** tarball.
+
+You should NOT use a tarball as an _extra file_ for a test-suite unless you
+have a very good reason for this: if you do include a tarball as an _extra file_,
+then you **MUST** specify why in your `remarks.md` file.
+
+If you **DO** include a tarball an _extra file_, and the build process or the program extracts
+said tarball(s), the make `clobber` rule **MUST** remove the extracted files.
+
+Instead of including a large test-suite that requires a lot of files as part of your submission,
+and your submission doesn't require the test-suite to be available to run,
+then in your `remarks.md` a URL where such a test-suite may be downloaded from
+and how to use the test-suite to test your submission.
+
+See FAQ on "[What should I do with the `try.sh` and `try.alt.sh` scripts?](../faq.html#try_scripts)".
+
+See FAQ on "[What is a `.auth.json` file?](../faq.html#auth_json)".
+
+See FAQ on "[What is a `.info.json` file?](../faq.html#info_json)".
+
+See FAQ on "[How can I validate my submission directory?](../faq.html#chksubmit)".
+
+See FAQ on "[What permissions may my files be and what if I need different permissions?](../faq.html#file_perms)".
+
+See FAQ on "[What are the detailed recommendations for a submission Makefile?](../faq.html#makefile_details)".
+
+See FAQ on "[What are the details behind Rule 17 - Packaging?](../faq.html#rule17)".
 
 
 Jump to: [top](#)
 
 
-<div id="entries">
-## Back to announcement of winners
+<div id="mkiocccentry">
+<div id="mkiocccentry_toolkit">
+# Guidelines for the mkiocccentry toolkit
+</div>
 </div>
 
-It is pointless to ask the [IOCCC judges](../judges.html) how many
-submissions we receive.  See [How many submissions do the judges receive for a
-given IOCCC?](../faq.html#how_many).
+The [IOCCC submit server](https://submit.ioccc.org), and related services
+use the **most recent version** of the
+[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry):
+submissions that package using older versions of the
+[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
+are **LIKELY** to be **REJECTED**!
 
-Often, winning entries are published in selected magazines from around the
-world.  Winners have appeared in books ('`The New Hacker's Dictionary`',
-'`Obfuscated C and Other Mysteries`', '`Pointers On C`', others) and on t-shirts
-(sometimes by the author(s) themselves).  There have been multiple classes
-that have focused in part, on IOCCC winning entries.  And more than one winner has been turned
-into a tattoo!
+You **REALLY SHOULD** use latest [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
+to package your own submission.
 
-Last, but not least, [winners](../authors.html) receive international fame and flames!  :-)
+The `mkiocccentry(1)` tool runs a number of checks by way of these
+[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
+tools:
+
+* iocccsize(1)
+* txzchk(1)
+* fnamchk(1)
+* chksubmit(1)
+* chkentry(1)
+
+Do **NOT** use `txzchk(1)` command line options that are labeled "**for TESTING purposes**"
+in the `txzchk(1)` man page.
+
+Do **NOT** use `fnamchk(1)` command line options that are labeled "**for TESTING purposes**"
+in the `fnamchk(1)` man page.
+
+Do **NOT** use `chkentry(1)` command line options that are labeled "**for the use by the IOCCC judges only**"
+in the `chkentry(1)` man page.
+
+To view [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) man pages,
+while your current directory is the top of the source tree:
+
+``` <!---sh-->
+    man soup/man/man1/mkiocccentry.1
+    man soup/man/man1/iocccsize.1
+    man soup/man/man1/txzchk.1
+    man test_ioccc/man/man1/fnamchk.1
+    man soup/man/man1/chksubmit.1
+    man soup/man/man1/chkentry.1
+```
+
+The above `man(1)` commands will show the toolkit man pages without having to install them first.
+
+So that you do not have to repeatedly answer all the `mkiocccentry(1)` questions,
+use `mkiocccentry -a answers ...` to create a file containing the answers you first give,
+that will allow you to later use `mkiocccentry -i answers ...` to reuse those same answers.
+
+The `mkiocccentry -A answers ..` does the same thing except that the **answers file will be overwritten**.
+
+The `mkiocccentry -i answers ..` will still be required to confirm "_Yes/No_" questions.
+
+Use `mkiocccentry -Y -i answers ..` to force a yes answers with **great caution**
+because it might force a yes answer to something you do **NOT** want.
+
+To help with not having to repeatedly enter a UUID, put your UUID into a file and use
+`mkiocccentry -u uuidfile ..`, or use `mkiocccentry -U UUID ..` to give the `UUID`
+on the command line.
+
+If you wish to **test** that your submission passes the `mkiocccentry(1)` tests
+without having to type in in answers each time, you can use the `-d` or `-s seed`
+option to `mkiocccentry` for the tool to pseudo-randomly create answers for you.
+For example:
+
+``` <!---sh-->
+    mkiocccentry -d workdir topdir
+```
+
+Do **NOT** submit a tarball formed by `mkiocccentry -d ..`, **NOR** by `mkiocccentry -s seed ..`!
+
+The `mkiocccentry(1)` tool creates an `xz(1)` compressed **v7 format** tarball using a `tar(1)`
+command of the form:
+
+``` <!---sh-->
+    cd workdir/UUID-slot_num && tar --format=v7 -cJf submit.UUID-slot_num.timestamp.txz UUID-slot_num
+```
+
+In many places the `mkiocccentry(1)` tool will prompt you to verify what you input, allowing you to
+correct details as you go along.
+
+Pressing the "_enter key_" `mkiocccentry(1)` tool prompts will allow you to proceed with a default,
+however make sure the default is the **CORRECT** answer.
+
+The `mkiocccentry(1)` tool will use code from `iocccsize(1)` which detects a number of
+issues (such as [Rule 2 - Size](rules.html#rule-2---size)) that you may ignore,
+however ignoring such issues **comes with a significant level of risk!**
+
+Once the tarball is packaged it will
+run `txzchk(1)`, which will also run `fnamchk(1)`, as part of its algorithm.
+
+The use of `mkiocccentry -W ...` is **highly discouraged** as this may ignore
+warnings about a problem that may cause your submission to be **REJECTED!**"
+
+If `mkiocccentry` encounters an **error**, the program will exit and the xz
+compressed tarball **will NOT be formed**: this is a **feature, not a bug**!
+
+If you encounter a **bug** with the
+[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
+**PLEASE run the `bug_report.sh` script to help us out here!**
+
+While you don't have to install the
+[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry),
+then in order to run a tool outside the repo directory
+you will have to specify `mkiocccentry(1)` command line options to locate required tools
+such as `chkentry(1)` (`mkiocccentry -C chkentry ..`), `txzchk(1)` (`mkiocccentry -T txzchk ..`),
+and `fnamchk(1)` (`mkiocccentry -F fnamchk ..`).
+
+The `mkiocccentry(1)` tool will ignore any filename that begins with a "." (dot).
+
+The `mkiocccentry(1)` tool will ignore any directory tree with a directory name that begins with a "." (dot).
+
+The `mkiocccentry(1)` tool will all files that begin with `COPYING`, `COPYRIGHT`, and `LICENSE`, regardless
+of filename case.
+
+The `mkiocccentry(1)` tool will any of the following files if they are found directly under
+the top level directory (`topdir`):
+
+* README.md
+* index.html
+* prog
+* prog.alt
+* prog.alt.o
+* prog.orig.c
+* filenames matching the `[0-9][0-9][0-9][0-9]_*.tar.bz2` file glob
+
+The files listed in the above list are allowed to exist in sub-directories: just **NOT** directly under
+the top level directory (`topdir`).
+
+The `mkiocccentry(1)` tool evaluates all filenames and directory names in a case independent way:
+this `FOO`, `Foo`, and `foo` are treated as the **SAME** file even if your filesystem doesn't.
+
+Having two or more filenames that differ only by case **WILL** lead to problems because of the previous statement.
+
+When the `mkiocccentry(1)` tool ignores a file, that file is **NOT** included as part of your submission.
+
+When the `mkiocccentry(1)` tool ignores a directory, that directory,
+and everything under that directory is **NOT** included as part of
+your submission.
+
+The `mkiocccentry(1)` tool will ignore all symlinks.
+
+Creating a directory directly under the top level directory (`topdir`)
+that is normally considered to be a regular file, such as a directory
+named `Makefile`, `prog.alt.c`, `prog.c`, `remarks.md`, `try.alt.sh`,
+or `try.sh` is **NOT** a good idea and will likely cause the
+`mkiocccentry(1)` tool to abort with a **fatal error**.
+
+The required `Makefile`, `remarks.md` file may **NOT** be an empty file.
+
+If the optional file `try.alt.sh`, or `try.sh` exits and is an empty file,
+the `mkiocccentry(1)` tool to abort with a **fatal error**.
+
+If the `mkiocccentry(1)` tool encounters anything that isn't a file, isn't a directory,
+and isn't a symlink (which the tool ignores), the `mkiocccentry(1)` tool to abort with a **fatal error**.
+
+See FAQ on "[How do I report bugs in an `mkiocccentry` tool?](../faq.html#mkiocccentry_bugs)".
+
+See [Rule 11 - Abuse](rules.html#rule-11---abuse) for warnings about ignoring `mkiocccentry(1)` tool warnings.
+
+See FAQ on "[What is the `fnamchk` tool?](../faq.html#fnamchk)".
+
+See FAQ on "[What is mkiocccentry in simple terms?](../faq.html#about_mkiocccentry)".
+
+See FAQ on "[What is the mkiocccentry tool, how do I obtain it and how do I use it](../faq.html#mkiocccentry)".
+
+
+Jump to: [top](#)
+
+
+<div id="general">
+# General Overall Guidelines
+</div>
+
+These [guideline](guidelines.html) are **hints** and **suggestions**, **NOT** [IOCCC rules](rules.html).
+
+While submissions that violate [guideline](guidelines.html) are allowed,
+submissions that remain within the [IOCCC guidelines](guidelines.html) are preferred.
+
+You are encouraged to review the following [FAQs](../faq.html):
+
+* [How to enter the IOCCC](../quick-start.html#enter)
+
+* [Obtaining and compiling the most recent mkiocccentry toolkit](../faq.html#mkiocccentry)
+
+* [How to upload your submission](../next/submit.html)
+
+While the contest is **[open](../faq.html#open)**, you may modify your
+previously uploaded submission by rebuilding your submission with the
+[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry),
+and then re-uploading it to **the same slot number** on the
+[submit server](https://submit.ioccc.org).
+
+The **official locale** of the **IOCCC** is **C**.
+
+You are **encouraged** to examine the [winners of previous contests](../years.html).
+
+Because [rules](rules.html) change from year to year, some [winning entries](../years.html)
+of the past may be rejected this year.
+
+What was _was_ unique and novel one year _might be 'old' the next year_.
+
+A submission is usually examined in a number of ways.  We typically apply
+a number of tests to a submission:
+
+* look at the original source
+* C pre-process the source ignoring `#include` lines
+* C pre-process the source ignoring `#define` _and_ `#include` lines
+* run it through a C beautifier (such as `clang-format(1)`)
+* examine the algorithm
+* compile it (with flags to enable all warnings)
+* execute it
+
+You should consider how your submission looks in each of the above tests.
+You should ask yourself if your submission remains obscure after it has been
+'_cleaned up_' by the C pre-processor and a C beautifier.
+
+Your submission need not pass all of the above tests as in certain cases,
+a test is not important.
+
+Submissions that compete for the
+'**strangest/most creative source layout**' need not do as well as
+others in terms of their algorithm.
+
+Given two submissions, we are more inclined to pick the submission that
+does something interesting when it's executed.
+
+**IMPORTANT:** Be sure that **your submission works** as documented in your `remarks.md` file.
+
+We sometimes make an effort to debug a submission
+that has a slight problem, particularly in or near the final round.
+On the other hand, we have seen some otherwise excellent submissions
+fall down because they didn't work as documented.
+
+If you submission has bugs and/or mis-features, you are **MUCH BETTER** off
+documenting such bugs and/or mis-features in your `remarks.md` file.
+
+Consider an example of a [prime number](https://en.wikipedia.org/wiki/Prime_number)
+printing program that claims that 16 is a prime number.
+Noting such a bug in your `remarks.md` file could save your submission:
+
+> "_this submission sometimes prints the 4th power of a prime by mistake_"
+
+Sometimes a strange bug or (mis-)feature can even help the submission!  Of course, a correctly
+working submission might be better.
+
+We tend to look down on a
+[prime number](https://en.wikipedia.org/wiki/Prime_number)
+printer that claims that 16 is a prime number.
+Clever people will note that 16 might be prime under certain conditions.  ;-)
+Wise people, when submitting something clever
+will **fully explain such cleverness** in their submission's `remarks.md` file.
+
+People who are considering to just use some complex mathematical
+function or state machine to spell out something such as "_hello,
+world!_" **really really, _and we do mean REALLY_, do need to be more creative**.
+
+Consider using misleading or subtle tricks layered on top of or under
+an appropriate level of obfuscation.
+
+A clean looking program with
+misleading comments and variable names might be a **VERY GOOD START**
+to a great submission!
+
+
+Jump to: [top](#)
+
+
+<div id="likes">
+<div id="dislikes">
+# OUR LIKES AND DISLIKES:
+</div>
+</div>
+
+We **VERY MUCH LIKE** submissions that use an edited variant of the
+example Makefile, as described and linked to in the [Makefile section](#makefile),
+renamed as `Makefile` of course.  This makes it easier for the [IOCCC judges](../judges.html)
+to test your submission. And if your submissions wins, it makes it easier to integrate it into
+the [Official IOCCC winner website](https://www.ioccc.org/index.html).
+
+We **VERY MUCH LIKE** submissions that have some educational value. This does **NOT** mean
+that your submission should not be obfuscated but rather that the IOCCC has moved away from
+the idea of "spoilers". You should not encrypt or rot13 content in your `remarks.md` file.
+
+It is **VERY MUCH** appreciated if your remarks have some educational
+value. And although educational value is not required, it is an
+**EXCELLENT** bonus.
+
+We **LIKE** submissions that use an edited version of the
+`try.sh` example script (and if you have alternate code,
+the same applies with the `try.alt.sh` script):
+
+- [view example try.sh](%%REPO_URL%%/next/try.sh)
+- <a href="try.sh">download example try.sh</a>
+
+- [view example try.alt.sh](%%REPO_URL%%/next/try.alt.sh)
+- <a href="try.alt.sh">download example try.alt.sh</a>
+
+Of course, it is quite possible that only one invocation is
+possible, so it is not necessarily detrimental to your submission if you do not
+include one, though we do like interesting and creative uses of submissions. See
+also the
+FAQ on "[submitting try.sh and try.alt.sh scripts](../faq.html#try_scripts)".
+
+<p class="leftbar">
+Even if it only has one invocation we still **LIKE** the try scripts.
+</p>
+
+<p class="leftbar">
+If you do include a `try.sh` then **PLEASE** remove the `try` rule in the Makefile.
+</p>
+
+<p class="leftbar">
+If you do include a `try.alt.sh` then **PLEASE** remove the `try.alt` rule in the Makefile.
+</p>
+
+<p class="leftbar">
+If you don't have a prog.alt.c, then **PLEASE** remove the `try.alt` rule as well.
+</p>
+
+Doing masses of `#define`s to obscure the source has become 'old'.  We
+tend to 'see thru' masses of `#define`s due to our pre-processor tests
+that we apply.  Simply abusing `#define`s or `-Dfoo=bar` won't go as far
+as a program that is more well rounded in confusion.
+
+**Many** C compilers **DISLIKE** the following code, and so do we:
+
+``` <!---c-->
+    #define d define
+    #d foo             /* <-- don't expect this to turn into #define foo */
+```
+
+In other words, it is a compilation error, and in order to get older
+IOCCC winning entries that did this to compile, we had to update them to not do this.
+
+When declaring local or global variables, you should declare the type:
+
+``` <!---c-->
+    int this_is_fine;
+    this_is_not;       /* <-- Try to avoid implicit type declarations */
+```
+
+We tend to **like _less_** a submission that requires either
+`gcc` **OR** `clang`.  **We _prefer_ submissions** that can compile
+under **BOTH** `gcc` **AND** `clang`. **Hint!**
+
+We **RECOMMEND** that the compiler flags you use in your
+submission's `Makefile` are supported by **BOTH** `gcc` **AND** `clang`.
+
+We **DISLIKE** the use of obscure compiler flags, especially
+if `gcc` and/or `clang` do not support it.  We **suggest**
+that you not use any really obscure compiler flags if you can help it.
+
+One side effect of the above is that you cannot assume the use
+of nested functions such as:
+
+``` <!---c-->
+     int main() {
+|        void please_dont_submit_this() {
+|           printf("The machine that goes BING!!\n");
+         }
+|        please_dont_submit_this();
+     }
+```
+
+On 2012 July 20, the [IOCCC judges](../judges.html) rescinded the encouragement of
+nested functions.  Such constructions, while interesting and sometimes
+amusing, will have to wait until they are required by a C standard that are
+actually implemented in **BOTH** `gcc` **AND** `clang`.
+
+We **DISLIKE** submissions that require the use of `-fnested-functions`.
+
+If your submission uses functions that have a variable number of
+arguments, **be careful**. Systems implement `va_list` in a wide variety
+of ways.  Because of this, a number of operations using `va_list` **are
+not portable and _must not_ be used**:
+
+* assigning a non-`va_list` variable to/from a `va_list` variable
+* casting a non-`va_list` variable into/from a `va_list` variable
+* passing a `va_list` variable to a function expecting a non-`va_list` arg
+* passing a non-`va_list` variable to a function expecting a `va_list` arg
+* performing arithmetic on `va_list` variables
+* using `va_list` as a structure or union
+
+In particular, do not treat `va_list` variables as if they were a `char **`.
+
+We **DISLIKE** the use of `varargs.h`.  Use `stdarg.h` instead.
+
+We **DISLIKE** the use of `gets(3)`.  Use `fgets(3)` instead.
+
+We tend to **DISLIKE** the blatant use of tarballs in an attempt to simply get
+around the extra file number limit. We realize there may be cases where a
+tarball containing a number of extra files may be needed. Such a need for a
+tarball **MUST** be explained in the `remarks.md` file.
+
+<p class="leftbar">
+Using a mass of `goto`s to obfuscate your code has become 'old' and is unlikely
+to make it through the final rounds, if it even gets that far.
+</p>
+
+On 28 January 2007, the Judges rescinded the requirement that the
+`#` in a C preprocessor directive must be the 1st non-whitespace byte.
+
+The `exit(3)` function returns `void`.  Some broken systems have `exit(3)`
+return `int`; your submission should assume that `exit(3)` returns a `void`.
+
+Small programs are best when they are short, obscure and concise.
+While such programs are not as complex as other winners, they do
+serve a useful purpose: they are often the only program that people
+attempt to completely understand.  For this reason, we look for
+programs that are compact, and are instructional.
+
+One line programs should be short one line programs: say around **80** to **132**
+bytes long.  Going well beyond **132** bytes is a bit too long to be called
+a one-liner in our vague opinion.
+
+We tend to **DISLIKE** programs that:
+
+* are very hardware specific
+* are very OS version specific (`index(3)`/`strchr(3)` differences are OK, but
+sockets/streams specific code is likely not to be)
+* dump core or have compiler warnings (it is OK only if
+you warn us in your `remarks.md` file)
+* won't compile or run in a [Single UNIX
+Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
+environment
+* depend on a utility or application not normally found
+in systems that conform to the [Single UNIX
+Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
+* abuse the build file to get around the size limit
+* obfuscate by use of ANSI trigraphs
+* obfuscate by use of digraphs
+* are larger than they need to be
+* have more lines than they need to have
+* are "blob-ier" (just a pile of unformatted C code) than they need to be
+* are rather similar to **[previous winners](../years.html)** :-(
+* are **identical** to **[previous losers](https://en.wikipedia.org/wiki/Null_device)** :-)
+* that mandate the exclusive use of a specific Integrated Development Environment (IDE)
+
+In order to encourage submission portability, we **DISLIKE** submissions that
+fail to build unless one is using an IDE. For example, do not
+mandate that one must use Microsoft Visual Studio to compile
+your submission.
+
+The program must compile and link cleanly in a [Single UNIX
+Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
+environment. Therefore do not assume the system has a
+[windows.h](https://en.wikipedia.org/wiki/Windows.h) include file:
+
+
+``` <!---c-->
+    #include <windows.h>  /* we DISLIKE this */
+```
+
+Unless you are cramped for space, or unless you are entering the
+'**Best one liner**' category, we suggest that you format your program
+in a more creative way than simply forming excessively long lines.
+
+The `Makefile` should not be used to try and get around the size limit.  It is
+one thing to make use of a several `-D`s on the compile line to help out, but it
+is quite another to use many bytes of `-D`s in order to try and squeeze the
+source under the size limit.
+
+Your source code, post-pre-processing, should not exceed the size of
+[Microsoft Windows](https://en.wikipedia.org/wiki/Microsoft_Windows). :-)
+
+You should try to restrict commands used in the build file to commands found in
+[Single UNIX
+Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
+environments and systems that conform to the [Single UNIX
+Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification).
+
+You may compile and use your own programs.  If you do, try to build and execute
+from the current directory.  This restriction is not a hard and
+absolute one.  The intent is to ensure that the building of your
+program is reasonably portable.
+
+We prefer programs that are portable across a wide variety of UNIX-like
+operating systems (e.g., Linux, GNU Hurd, BSD, UNIX, etc.).
+
+Don't forget that the building of your program should be done
+**WITHOUT human intervention**.  So don't do things such as:
+
+```
+    prog: prog.c
+        #echo this next line requires data from standard input
+        cat > prog.c
+        ${CC} prog.c -o prog
+```
+
+However, you can do something cute such as making your program
+do something dumb (or cute) when it is built 'automatically', and
+when it is run with a human involved, do something more clever.
+For example, one could put in their `Makefile`:
+
+```
+    prog: prog.c
+        ${CC} prog.c -DNON_HUMAN_COMPILE -o prog
+        @echo "See remarks section about alternate ways to compile"
+```
+
+and then include special notes in your `remarks.md` file for
+alternate / human intervention based building.
+
+We want to get away from source that is simply a compact blob of
+bytes.   **REALLY TRY** to be more creative than blob coding. **HINT!**
+
+Please do not use things like `gzip(1)` to get around the size limit.
+Please try to be much more creative.
+
+We really **DISLIKE** submissions that make blatant use of including
+large data files to get around the source code size limit.
+
+Did we remember to indicate that programs that blatantly use
+some complex state machine to do something simple, are boring?
+We think we did.  :-)
+
+Given two versions of the same program, one that is a compact blob
+of code, and the other that is formatted more like a typical C
+program, we tend to favor the second version.  Of course, a third
+version of the same program that is formatted in an interesting
+and/or obfuscated way, would definitely win over the first two!
+Remember, you can submit more than one submission.  See the
+[IOCCC rules](rules.html)
+for details (in particular,
+[Rule 8 - Submission](rules.html#rule-8---submission)).
+
+We suggest that you avoid trying for the '**smallest self-replicating**'
+source.  The smallest, a [zero byte entry](../1994/smr/index.html), won in
+[1994](../years.html#1994).
+
+Programs that claim to be the smallest C source that does something, really
+better be the smallest such program or they risk being rejected because
+they do not work as documented.
+
+Please note that the C source below, besides lacking in obfuscation,
+is **NOT** the smallest C source file that when compiled and run, dumps core:
+
+``` <!---c-->
+    main;
+```
+
+Unless you specify `-fwritable-strings` (see `COTHER` in the example
+Makefile, described in the [Makefile section](#makefile)), do not assume this
+sort of code will work:
+
+``` <!---c-->
+    char *T = "So many primes, so little time!";
+    ...
+    T[14] = ';';    /* modifying a string requires: -fwritable-strings */
+```
+
+Even so, one should probably not assume that this is universally accepted.
+
+Initialized char arrays are OK to write over.  For instance, this is OK:
+
+``` <!---c-->
+    char b[] = "Is this OK";
+    b[9] = 'k';     /* modifying an initialized char array is OK */
+```
+
+X client submissions should be as portable as possible.  Submissions that
+adapt to a wide collection of environments will be favored.  For
+example, don't depend on a particular type or size of display.
+Don't assume the use of a particular browser.  Instead assume a
+generic browser that forms to a widely used [W3C
+standard](https://www.w3.org/standards/).
+Don't assume a particular sound sub-system or video driver is installed
+in the OS. Instead, make use of a well known and widely available open
+source program (one that actually works) to display audio/visual data.
+
+X client submissions should avoid using X related libraries and
+software that are not in wide spread use.
+
+As of Red Hat RHEL9.0, the X.org server is deprecated. See the
+FAQ on "[Xorg deprecation"](../faq.html#Xorg_deprecated)"
+for more details. This does not mean that a submission using this will
+necessarily be rejected, but it would be better if it can support Wayland in
+some way or another.
+
+We **DISLIKE** submissions that use proprietary toolkits such as the `M*tif`,
+`Xv*ew`, or `OpenL*ok` toolkits, since not everyone has them.  Use an
+open source toolkit that is widely and freely available instead.
+
+X client submissions should try to not to depend on particular items in
+`.Xdefaults`.  If you must do so, be sure to note the required lines
+in the your `remarks.md` file.  They should also not depend on any
+particular window manager.
+
+Try to avoid submissions that play music that some people believe is copyrighted
+music.
+
+While we recognize that UNIX is not a universal operating system, the contest
+does have a bias towards such systems.  In an effort to expand the scope of the
+contest, we phrase our bias to favor the [Single UNIX
+Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification).
+
+You are **well advised** to submit code that conforms to the [Single UNIX
+Specification Version 4](https://unix.org/version4/overview.html).
+
+To quote the [IOCCC judges](../judges.html):
+
+We **LIKE** programs that:
+
+* are as concise and small as they need to be
+* do something at least quasi-interesting
+* are portable
+* are unique or novel in their obfuscation style
+* make use of a **NUMBER OF DIFFERENT TYPES OF OBFUSCATIONS!**  **<== HINT!!**
+* make us laugh and/or throw up  :-)  (humor really helps!)
+* make us want to eat good chocolate
+
+Some types of programs can't excel (anti-tm) in some areas.  Your
+program doesn't have to excel in all areas, but doing well in several
+areas really does help.
+
+You are better off explaining what your submission does in your
+`remarks.md` file section rather than leaving it obscure for the
+[IOCCC judges](../judges.html) as we might miss something and/or be too tired to
+notice.
+
+We freely admit that interesting, creative or humorous comments in
+your `remarks.md` file help your chances of winning.  If you had to
+read so many twisted submissions, you too would enjoy a good laugh or two.
+We think the readers of the contest winners do as well.  We do read
+your `remarks.md` content during the judging process, so it is worth your
+while to write a remarkable `remarks.md` file.
+
+We **DISLIKE** C code with trailing control-M's (`\r` or `\015`) that results
+in compilation failures.  Some non-UNIX/non-Linux tools such as
+MS Visual C and MS Visual C++ leave trailing control-M's on lines.
+Users of such tools should strip off such control-M's before submitting
+their submissions.  In some cases tools have a "Save As" option that will
+prevent such trailing control-M's being added.
+
+One should restrict libcurses to portable features found on BSD
+or Linux curses.
+
+<p class="leftbar">
+If you do `#include <curses.h>` make **CERTAIN** you link in curses (i.e.
+`-lcurses`) and not ncurses (i.e. `-lncurses`).
+</p>
+
+[Rule 13 - Newlines](rules.html#rule-13---newlines)
+no longer discourages the use of UTF-8
+characters in C code.
+
+It is a very good idea to, in your `remarks.md` file, tell us why you
+think your submission is obfuscated.  This is particularly true if
+your submission has some very subtle obfuscations that we might
+otherwise overlook.  **<<-- Hint!**
+
+Anyone can format their code into a dense blob.  A really clever
+author will try format their submission using a "normal" formatting style
+such that at first glance (if you squint and don't look at the details)
+the code might pass for non-obfuscated C.  Deceptive comments,
+and misleading formatting, in some cases, may be a plus.  On the
+other hand, a misleading code style requires more source bytes.
+
+If you do elect to use misleading formatting and comments, we
+suggest you remark on this point in your `remarks.md` where you talk
+about why you think your submission is obfuscated.  On the other hand,
+if you are pushing up against the size limits, you may be forced
+into creating a dense blob. Such are the trade-offs that obfuscators face!
+
+We prefer code that can run on either a 64-bit or 32-bit
+processor.  However, it is **UNWISE **to assume it will run on an
+some Intel-like x86 architecture**.
+
+While programs that only run in a specific word size are OK, if you have
+to pick, choose a 64-bit word size.
+
+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 `ARCH` in the example
+Makefile, described in [Makefile section](#makefile)).  Do not assume a
+processor word size without specifying `-arch`.  For example:
+
+``` <!---make-->
+    ARCH= -m64
+```
+
+Note, however, that some platforms will not necessarily support some
+architectures. For instance, more recent versions of `macOS` do **NOT** support
+32-bit!
+
+If there are limitations in your submission, you are highly encouraged
+to note such limitations in your `remarks.md` file.  For example if your
+submission factors values up to a certain size, you might want to state:
+
+>   This submission factors values up `2305567963945518424753102147331756070`.
+Attempting to factor larger values will produce unpredictable results.
+
+The [IOCCC judges](../judges.html) might try to factor the value -5, so you want to might state:
+
+>   This submission factors positive values up
+`2305567963945518424753102147331756070`. Attempting to factor large values will
+produce unpredictable results.
+
+However the [IOCCC judges](../judges.html) might try to also factor 0, so you want to might state:
+
+>   This submission factors values between 1 and
+`2305567963945518424753102147331756070`.  Attempting to factor values outside
+that range will produce unpredictable results.
+
+Moreover they might try to also factor 3.5 or 0x7, or Fred, so you want to might state:
+
+>   This submission factors integers between 1 and
+`2305567963945518424753102147331756070`.  Attempting to factor anything else
+will produce unpredictable results.
+
+You submission might be better off catching the attempt to factor bogus values
+and doing something interesting.  So you might want to code accordingly and state:
+
+>   This submission factors integers between 1 and `2305567963945518424753102147331756070`.
+>   Attempting to factor anything else will cause the program to insult your pet fish Eric.
+
+The [IOCCC judges](../judges.html) might not have a pet fish named Eric, so you might want to state:
+
+>   This submission factors integers between 1 and
+`2305567963945518424753102147331756070`.  Attempting to factor anything else
+will cause the program to insult your pet fish Eric, or in the case that you
+lack such a pet, will insult the pet that you do not have.
+
+When all other things are equal, a submission with fewer limitations will be judged
+better than a submission with lots of limitations.  So you might want to code accordingly
+and state:
+
+>   This submission attempts to a factor value of any size provided that the
+program is given enough time and memory.  If the value is not a proper integer,
+the program might insult a fish named Eric.
+
+We **DISLIKE** the use of ASCII tab characters in markdown files, such as in the required `remarks.md` file.
+
+We don't mind the use of ASCII tab characters in your C code.  Feel free
+to use ASCII tab characters if that suits your obfuscation needs.  If is
+perfectly **OK** to use tab characters elsewhere in your submission, just not in
+markdown files as this tends annoy us when it comes time to
+rendering your markdown content as it complicates the process.
+
+If you do use ASCII tab characters in your non-markdown files, be
+aware that some people may use a tab stop that is different than the common 8
+character tab stop.
+
+**PLEASE** observe our [IOCCC markdown guidelines](../markdown.html)
+when forming your submission's `remarks.md` file.  And if your submission
+contains additional markdown files, please follow those same guidelines for
+those files. See also
+[Rule 4 - Files](rules.html#rule-4---files),
+and the
+FAQ on "[markdown](../faq.html#markdown)".
+
+We **LIKE** reading `remarks.md` files, especially if they contain
+useful, informative, and even humorous content about your submission.  Yes, this
+is a **hint**.  :-)
+
+We **RECOMMEND** you put a reasonable amount effort into the content of the
+`remarks.md` file: it is a required file for a reason.  :-)
+
+Try to be even more creative!
+
+
+Jump to: [top](#)
+
+
+<div id="fun">
+# Fun😄damental Guidelines
+</div>
+
+The reason for the times of day are so that key IOCCC events are **calculated**
+to be a **fun**ctional UTC time.  :-)
+
+At least 2 of several reasons for selecting the prime, 2503, for
+[Rule 2b - Net Size](rules.html#rule-2b---net-size)
+may be found on the ["Curios!" about 2503](https://t5k.org/curios/page.php/2503.html).
+
+The 2503 value for [Rule 2b - Net](rules.html#rule-2b---net-size) is a decimal anagram
+of the number of the kernel disk pack of one of the judge's [BESM-6](https://en.wikipedia.org/wiki/BESM-6).
+
+There may or may not be fewer than 2^7+1 reasons why these [IOCCC
+guidelines](guidelines.html) seem obfuscated.
+
+Excessively "_dotty"_ use of the `chksubmit(1)` or `chkentry(1)` commands suggests that
+either like silly things, or that you "_RTFS"_ with some level of care.
+
+Some people might question what actually constitutes a valid JSON file, given
+the state of the "_so-called_" JSON spec.. :-)
+
+We prefer programs that do not require a fish license: crayons and
+cat detector vans not withstanding.
+
+<p class="leftbar">
+This _guideline_ has a change mark at the very start of this line.
+</p>
+
+While those who are used to temperatures found on [dwarf
+planets](https://science.nasa.gov/dwarf-planets/)
+(**yes Virginia, dwarf planets _ARE_ planets!**), such as
+[Pluto](https://science.nasa.gov/dwarf-planets/pluto/), might be able to
+explain to the Walrus why our seas are boiling hot, the question of
+whether pigs have wings is likely to remain a debatable point to most.
+
+At least one judge prefers to maintain the use of the
+[leap-second](https://en.wikipedia.org/wiki/Leap_second)
+as part of the world's time standard.  If your code prints time
+with seconds, we prefer that your code be capable of printing the
+time of day during a leap-second where the value in seconds
+after the minute mark is **60**.
+
+Other windows, on the other hand, might be OK: especially where "**X
+marks the spot**".  Yet on the third hand, windows are best when they are
+"unseen" (i.e., not dirty).  :-)
+
+The [IOCCC judges](../judges.html), as a group, have a history giving wide degree of latitude
+to reasonable submissions.  And recently they have had as much longitudinal
+variation as it is possible to have on [Earth](https://science.nasa.gov/earth/).  :-)
+Other windows, on the other hand, might be OK: especially where "**X
+marks the spot**".  Yet on the third hand, windows are best when they are
+"unseen" (i.e., not dirty).  :-)
+
+The [IOCCC judges](../judges.html), as a group, have a history giving wide degree of latitude
+to reasonable submissions.  And recently they have had as much longitudinal
+variation as it is possible to have on [Earth](https://science.nasa.gov/earth/).  :-)
+
+> You are in a maze of twisty _guidelines_, all different.
+
+There are at least zero [IOCCC judges](../judges.html) who think that
+[Fideism](https://en.wikipedia.org/wiki/Fideism) has little
+or nothing to do with the IOCCC judging process.
+
+> All generalizations are false, including this one. -- **Mark Twain**
+
+<p class="leftbar">
+There are more than about 1 typos in this very sentence.
+</p>
+
+This could be the only _guideline_ that contains the word
+[fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin).
+
+However, do you know how to play [fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin)?
+You do?!?  (Except on Tuesday?)
+
+OK, there are actually 2 _guidelines_ that contain the word
+[fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin),
+unless you count this one, in which case there are 3. :-)
+
+**NOTE**: The previous _guideline_ in this spot has been replaced by this _guideline_:
+
+<p class="leftbar">
+> You very well might not be completely prohibited from failing to not partly
+misunderstand this particular _guideline_, but of course, we could not possibly
+comment!  :-)  Nevertheless, you are neither prohibited, nor are you fully or partly
+required to determine that this or the previous sentence is either false and/or
+perhaps misleading.  Therefore, it might be wise for you to not fail to consider
+to not do so, accordingly.  Thank you very much (allegedly).
+</p>
+
+Any complaints about the above _guideline_ could be addressed to the
+Speaker of the House of Commons, or to the speaker of your national
+parliament should you have one.
+
+<p class="leftbar">
+Please try to avoid this specific individual _guideline_, if it at all possible.
+</p>
+
+We believe that Mark Twain's quote:
+
+> Get your facts first, then you can distort them as you please.
+
+... is a good motto for those writing code for the IOCCC.
+
+<p class="leftbar">
+We do not recommend submitting [systemd](https://systemd.io) source code to the IOCCC,
+if nothing else because that code is likely to exceed
+[Rule 2 - Size](rules.html#rule-2---size).
+This isn't to say that another highly compact and obfuscated
+replacement of `init(8)` would not be an interesting submission.
+</p>
+
+<p class="leftbar">
+The
+[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
+is not an original work, unless you one of the
+[several mkiocccentry toolkit contributors](https://github.com/ioccc-src/mkiocccentry/graphs/contributors).
+in which case it is original!  :-)
+</p>
+
+If the [IOCCC judges](../judges.html) are feeling ornery we
+might choose to compile your program for running on an Arduino or
+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 :-)
+
+Do not fear if you're not 100% sure of the significance of
+`2305567963945518424753102147331756070` as it is not of prime importance: or is
+it?  :-)
 
 
 Jump to: [top](#)
diff --git a/next/rules.html b/next/rules.html
index d326d1fa0..7af92541f 100644
--- a/next/rules.html
+++ b/next/rules.html
@@ -480,16 +480,22 @@ granted provided this copyright and notice are included in its entirety
 and remains unaltered. All other uses <strong>MUST</strong> receive prior permission in
 writing by <a href="../contact.html">contacting the judges</a>.</p>
 <h2 id="rules-version">Rules Version</h2>
-<p>These IOCCC Rules are version <strong>29.05 2025-11-21</strong>.</p>
+<p>These IOCCC Rules are version <strong>29.08 2025-11-28</strong>.</p>
 <p>Be sure to read the <a href="guidelines.html">IOCCC guidelines</a>.</p>
 <div id="rule0">
 <h2 id="rule-0---dates">Rule 0 - Dates</h2>
 </div>
-<p>This IOCCC runs from ${START_DATE_TIME} UTC to ${CLOSE_DATE_TIME} UTC.</p>
-<p>This contest will enter the open state on ${OPEN_DATE_TIME} UTC.</p>
-<p>This contest will enter the judging state on ${JUDGMENT_DATE_TIME} UTC.</p>
-<p>The above dates are subject to change until the contest is officially open.</p>
-<p><strong>NOTE</strong>: As of this draft, the above dates are TBD (to be determined).</p>
+<p>This IOCCC runs from <strong>2025-12-03 20:25:12.045045 UTC</strong> to <strong>2026-03-13 17:19:23.293137 UTC</strong>.</p>
+<p>This contest will enter the <strong>pending state</strong> on <strong>2025-12-03 20:25:12.045045 UTC</strong>,
+allowing people to register for the IOCCC.</p>
+<p>This contest will enter the <strong>open state</strong> on <strong>2025-12-15 18:21:24.273033 UTC</strong>,
+allowing people to upload submissions to the <a href="https://submit.ioccc.org">IOCCC submit server</a>.</p>
+<p>This contest will enter the <strong>judging state</strong> on <strong>2026-03-13 17:19:23.293137 UTC</strong>,
+when people will no longer be allowed to upload submissions.</p>
+<p>Until the contest enters the <strong>open</strong> state, any or all
+of the above <strong>dates and times may change <em>AT ANY TIME</em></strong>!</p>
+<p>The above timestamps are in “<em>YYYY-MM-DD HH:MM:SS.micros UTC</em>” format.</p>
+<p>See <a href="../status.html">Current status of the IOCCC</a>.</p>
 <div id="rule1">
 <h2 id="rule-1---program">Rule 1 - Program</h2>
 </div>
@@ -503,11 +509,13 @@ and
 <a href="rules.html#rule-2b-net-size">Rule 2b Next Size</a>.
 During development this can be checked using <code>iocccsize(1)</code>:</p>
 <p>iocccsize prog.c</p>
+<p>See <a href="guidelines.html#guideline-2---size">Guidelines for Rule 2 - Size</a>.</p>
 <div id="rule2a">
 <h3 id="rule-2a---gross-size">Rule 2a - Gross Size</h3>
 </div>
 <p>The overall maximum size of your <code>prog.c</code> program source <strong>MUST NOT</strong>
 exceed <strong>4993</strong> bytes.</p>
+<p>See <a href="../quick-start.html#enter">Entering the IOCCC: the bare minimum you need to know</a>.</p>
 <div id="rule2b">
 <h3 id="rule-2b---net-size">Rule 2b - Net Size</h3>
 </div>
@@ -531,6 +539,7 @@ to register! The judges are <strong>NOT</strong> responsible for delayed or lost
 email or for those who wait until the last minute to try to register!</p>
 <p>See <a href="../quick-start.html#enter">Entering the IOCCC: the bare minimum you need to know</a>.</p>
 <p>See <a href="rules.html#rule-8---submission">Rule 8 - Submission</a>.</p>
+<p>See <a href="guidelines.html#guideline-3---register">Guidelines for Rule 3 - Register</a>.</p>
 <div id="rule4">
 <h2 id="rule-4---files">Rule 4 - Files</h2>
 </div>
@@ -574,6 +583,9 @@ a case insensitive filesystem.</p></li>
 <p>The <code>remarks.md</code> and <code>Makefile</code> are explained in more detail in the Guidelines.</p>
 <p>See <a href="../markdown.html">IOCCC markdown guidelines</a>.</p>
 <p>See <a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p>
+<p>See FAQ on “<a href="../faq.html#file_perms">What permissions may my files be and what if I need different permissions?</a>”.</p>
+<p>See <a href="guidelines.html#mkiocccentry_toolkit">Guidelines for the mkiocccentry toolkit</a>.</p>
+<p>See <a href="guidelines.html#makefile">Guidelines for the Makefile</a>.</p>
 <div id="rule5">
 <h2 id="rule-5---integrity">Rule 5 - Integrity</h2>
 </div>
@@ -602,22 +614,14 @@ original form, including the removal of any created files and directories.</p>
 <div id="rule7">
 <h2 id="rule-7---original-work">Rule 7 - Original Work</h2>
 </div>
-<p>In short: You wrote it, you own it, and its an original work.</p>
 <p>You, the author(s), <strong>MUST</strong> own the contents of your submission, or you <strong>MUST</strong>
 have permission from the original owner(s) to its use. If you submit
 any content that is owned by others, you <strong>MUST</strong> detail that ownership,
 i.e., who owns what, and document the permission you obtained from them
 in your <code>remarks.md</code> file.</p>
-<p>The IOCCC has a rich history of remarkable winning entries created by
-authors who skilfully employed various techniques to develop their code.
-While it isn’t required, you are allowed to use tools to develop and
-test your submission. These tools may include, but aren’t limited to
-code generators, code analysis tools, static code analysis tools, runtime
-analysis tools, machine learning tools, natural language models, code
-copilot tools, so-called AI services, large language models (LLMs), etc.
-If you do make use of such tools or services, then we encourage you to
-describe what tools and how you used those tools, in your <code>remarks.md</code> file.</p>
+<p>You are permitted to use tools to write your code.</p>
 <p>See <a href="rules.html#rule-16---anonymous">Rule 16 - Anonymous</a>.</p>
+<p>See <a href="guidelines.html#guideline-7---original-work">Guidelines for Rule 7 - Original Work</a>.</p>
 <div id="rule8">
 <h2 id="rule-8---submission">Rule 8 - Submission</h2>
 </div>
@@ -641,12 +645,12 @@ and
 permitted. However, see the guidelines. Each entry <strong>MUST</strong> automate the
 build process using <code>bash</code>, <code>gmake</code>, <code>gcc</code>, <code>clang</code>, under a
 <a href="https://pubs.opengroup.org/onlinepubs/9799919799/">SUS environment</a>.</p>
-<p>Note references to <code>gmake</code> can be any GNU Make compatible tool.</p>
+<p><strong>NOTE</strong>: The references to <code>gmake(1)</code> can be any GNU Make compatible tool.</p>
 <p>See <a href="rules.html#rule-15---building">Rule 15 - Building</a>.</p>
 <div id="rule10">
 <h2 id="rule-10---privileges">Rule 10 - Privileges</h2>
 </div>
-<p>Programs that require special privileges (setuid(2), setgid(2),
+<p>Programs that require special privileges (<code>setuid(2)</code>, <code>setgid(2)</code>,
 super-user, special owner, special group, etc.) are <strong>HIGHLY DISCOURAGED</strong>.
 We do <strong>NOT</strong> guarantee these functions will behave as you expect on our
 test platforms. If your program needs special permissions you <strong>MUST</strong>
@@ -679,6 +683,7 @@ is rejected.</p>
 version, please indicate that in your <code>remarks.md</code> file of your non-rule
 abusing version so that the Judges don’t think you uploaded a duplicate
 into a wrong slot by mistake.</p>
+<p>See <a href="guidelines.html#guideline-11---abuse">Guidelines for Rule 11 - Abuse</a>.</p>
 <div id="rule12">
 <h2 id="rule-12---utf-8">Rule 12 - UTF-8</h2>
 </div>
@@ -732,6 +737,8 @@ environments and systems are available in the search
 GNU long name options <code>--example</code> or extensions like <code>grep -P</code>.</p>
 <p>Do <strong>NOT</strong> assume that <code>.</code> (current directory) is in the <code>$PATH</code> environment variable.</p>
 <p>See <a href="rules.html#rule-4---files">Rule 4 - Files</a>.</p>
+<p>See FAQ on “<a href="../faq.html#makefile_details">What are the detailed recommendations for a submission Makefile?</a>”.</p>
+<p>See <a href="guidelines.html#guideline-15---building">Guidelines for Rule 15 - Building</a>.</p>
 <div id="rule16">
 <h2 id="rule-16---anonymous">Rule 16 - Anonymous</h2>
 </div>
@@ -754,27 +761,33 @@ directory depths of <strong>4</strong>. The maximum number of files, excluding
 <code>prog.c</code>, <code>remarks.md</code>, <code>Makefile</code>, <code>prog.alt.c</code>, <code>try.sh</code>, <code>try.alt.sh</code>,
 <code>.info.json</code> and <code>.auth.json</code> is <strong>31</strong>. And the maximum file-path
 component is <strong>38</strong> and maximum path length is <strong>60</strong>.</p>
-<p>The submission <strong>MUST</strong> be a <code>.txz</code> compressed tarball as constructed by
-<code>mkiocccentry(1)</code>, which <strong>MUST</strong> be within <strong>[1..3999971]</strong> bytes in size.
-The sum of all file lengths, after unpacking from the tarball, <strong>MUST</strong> be
-less than <code>27651*1024</code> bytes.</p>
-<p>The tarball file <strong>MUST</strong> pass all <code>txzchk(1)</code> checks and the tarball
-filename <strong>MUST</strong> pass all <code>fnamchk(1)</code> checks. You may <strong>NOT</strong> submit a tarball
-created by the <code>-d</code> or <code>-s</code> seed options of <code>mkiocccentry(1)</code>.</p>
+<p>The submission <strong>MUST</strong> be a <code>.txz</code> compressed tarball (i.e., tarball compressed by <code>xz(1)</code>)
+as constructed by <code>mkiocccentry(1)</code>, which <strong>MUST</strong> be within <strong>[1..3999971]</strong> bytes in size.</p>
+<p>The tarball <strong>MUST</strong> be a <strong>v7 format</strong> tarball.</p>
+<p>The sum of all file lengths, after unpacking from the tarball, <strong>MUST</strong> be
+less than <code>27651*1024</code> (<strong>28314624</strong>) bytes.</p>
+<p>The submission <strong>MUST</strong> be a tarball file that <strong>MUST</strong> pass all <code>txzchk(1)</code> checks, and the tarball
+filename <strong>MUST</strong> pass all <code>fnamchk(1)</code> checks.</p>
+<p>You may <strong>NOT</strong> submit a tarball created by the <code>-d</code>, <code>-e</code>, <strong>NOR</strong> by the <code>-s seed</code> options of <code>mkiocccentry(1)</code>.</p>
 <p>The unpacked submission directory <strong>MUST</strong> pass the checks performed by the
 current version of <code>chksubmit(1)</code>.</p>
+<p>Submissions may <strong>NOT</strong> use a
+<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
+command line options that labeled as “<strong>for TESTING purposes</strong>”,
+<strong>NOR</strong> labeled as “<strong>for the use by the IOCCC judges only</strong>”,
+in their respective man pages.</p>
+<p>Submissions may <strong>ONLY</strong> use
+<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
+command lines that confirm to the command’s <code>-h</code> “<em>print help message</em>”.</p>
 <p>The <code>prog.c</code> file <strong>MUST</strong> pass the <a href="rules.html#rule-2---size">Rule 2 - Size</a>
 size checks performed by <code>iocccsize(1)</code>.</p>
-<p>The <code>.auth.json</code> and <code>.info.json</code> files <strong>MUST</strong> be compatible with what
-<code>mkiocccentry(1)</code> generates.</p>
-<p>Submissions that package using older versions of the mkiocccentry
-toolkit to are <strong>HIGHLY LIKELY</strong> to be <strong>REJECTED</strong>! Be sure
-that you are using the latest tools from the
+<p>The <code>.auth.json</code> and <code>.info.json</code> files <strong>MUST</strong> be compatible with what <code>chksubmit(1)</code> generates.</p>
+<p>Any submission that fails to pass the checks performed by the most recent version of the
 <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
-GitHub repo.</p>
-<p>In summary: it is best to use <code>mkioccentry(1)</code> to package your submission,
-rather than roll-it-by-hand.</p>
+<strong>WILL be rejected</strong>!</p>
 <p>See <a href="rules.html#rule-4---files">Rule 4 - Files</a>.</p>
+<p>See FAQ on “<a href="../faq.html#mkiocccentry">What is the mkiocccentry tool, how do I obtain it and how do I use it?</a>”.</p>
+<p>See <a href="guidelines.html#guideline-17---packaging">Guidelines for Rule 17 - Packaging</a>.</p>
 <div id="rule18">
 <h2 id="rule-18---license">Rule 18 - License</h2>
 </div>
@@ -789,14 +802,15 @@ Additional rules, both humorous and otherwise, may be added
 below this rule in future contests.</p>
 <p>See <a href="rules.html#rule-6---free">Rule 6 - Free</a>.</p>
 <h2 id="further-reading">Further Reading</h2>
+<p>Please read the <a href="guidelines.html">Guidelines</a> next for further commentary on these rules.</p>
 <p>Read the
 <a href="https://www.ioccc.org/quick-start.html#enter">Entering the IOCCC: the bare minimum you need to know</a>
 for an overview of how to enter the contest.</p>
-<p>Please read the <a href="guidelines.html">Guidelines</a> next for further commentary on The Rules.</p>
 <p>See also the <a href="../faq.html">FAQ</a>.</p>
+<p>And now <a href="guidelines.html#fun">for something completely different</a></p>
 <p>Consider joining the <a href="https://discord.com/invite/Wa42Qujwnw">IOCCC Discord Server</a>
 for discussions about The Rules, questions for the Judges, and <code>C</code> in general.</p>
-<p>Leonid A. Broukhis<br />
+<p>Leonid A. Broukhis
 chongo (Landon Curt Noll) /\cc/\
 <!-- AFTER: last line of markdown file: next/rules.md --></p>
 
diff --git a/next/rules.md b/next/rules.md
index df55cda95..4ed0bc1eb 100644
--- a/next/rules.md
+++ b/next/rules.md
@@ -39,7 +39,7 @@ writing by [contacting the judges](../contact.html).
 
 ## Rules Version
 
-These IOCCC Rules are version **29.05 2025-11-21**.
+These IOCCC Rules are version **29.08 2025-11-28**.
 
 Be sure to read the [IOCCC guidelines](guidelines.html).
 
@@ -48,15 +48,23 @@ Be sure to read the [IOCCC guidelines](guidelines.html).
 ## Rule 0 - Dates
 </div>
 
-This IOCCC runs from ${START_DATE_TIME} UTC to ${CLOSE_DATE_TIME} UTC.
+This IOCCC runs from **2025-12-03 20:25:12.045045 UTC** to **2026-03-13 17:19:23.293137 UTC**.
 
-This contest will enter the open state on ${OPEN_DATE_TIME} UTC.
+This contest will enter the **pending state** on **2025-12-03 20:25:12.045045 UTC**,
+allowing people to register for the IOCCC.
 
-This contest will enter the judging state on ${JUDGMENT_DATE_TIME} UTC.
+This contest will enter the **open state** on **2025-12-15 18:21:24.273033 UTC**,
+allowing people to upload submissions to the [IOCCC submit server](https://submit.ioccc.org).
 
-The above dates are subject to change until the contest is officially open.
+This contest will enter the **judging state** on **2026-03-13 17:19:23.293137 UTC**,
+when people will no longer be allowed to upload submissions.
 
-**NOTE**: As of this draft, the above dates are TBD (to be determined).
+Until the contest enters the **open** state, any or all
+of the above **dates and times may change _AT ANY TIME_**!
+
+The above timestamps are in "_YYYY-MM-DD HH:MM:SS.micros UTC_" format.
+
+See [Current status of the IOCCC](../status.html).
 
 
 <div id="rule1">
@@ -78,6 +86,9 @@ During development this can be checked using `iocccsize(1)`:
 
     iocccsize prog.c
 
+See [Guidelines for Rule 2 - Size](guidelines.html#guideline-2---size).
+
+
 <div id="rule2a">
 ### Rule 2a - Gross Size
 </div>
@@ -85,6 +96,8 @@ During development this can be checked using `iocccsize(1)`:
 The overall maximum size of your `prog.c` program source **MUST NOT**
 exceed **4993** bytes.
 
+See [Entering the IOCCC: the bare minimum you need to know](../quick-start.html#enter).
+
 
 <div id="rule2b">
 ### Rule 2b - Net Size
@@ -118,6 +131,8 @@ See [Entering the IOCCC: the bare minimum you need to know](../quick-start.html#
 
 See [Rule 8 - Submission](rules.html#rule-8---submission).
 
+See [Guidelines for Rule 3 - Register](guidelines.html#guideline-3---register).
+
 
 <div id="rule4">
 ## Rule 4 - Files
@@ -177,6 +192,12 @@ See [IOCCC markdown guidelines](../markdown.html).
 
 See [Rule 17 - Packaging](rules.html#rule-17---packaging).
 
+See FAQ on "[What permissions may my files be and what if I need different permissions?](../faq.html#file_perms)".
+
+See [Guidelines for the mkiocccentry toolkit](guidelines.html#mkiocccentry_toolkit).
+
+See [Guidelines for the Makefile](guidelines.html#makefile).
+
 
 <div id="rule5">
 ## Rule 5 - Integrity
@@ -219,26 +240,18 @@ See [Rule 19 - Prime](rules.html#rule-19---prime).
 ## Rule 7 - Original Work
 </div>
 
-In short: You wrote it, you own it, and its an original work.
-
 You, the author(s), **MUST** own the contents of your submission, or you **MUST**
 have permission from the original owner(s) to its use.  If you submit
 any content that is owned by others, you **MUST** detail that ownership,
 i.e., who owns what, and document the permission you obtained from them
 in your `remarks.md` file.
 
-The IOCCC has a rich history of remarkable winning entries created by
-authors who skilfully employed various techniques to develop their code.
-While it isn't required, you are allowed to use tools to develop and
-test your submission.  These tools may include, but aren't limited to
-code generators, code analysis tools, static code analysis tools, runtime
-analysis tools, machine learning tools, natural language models, code
-copilot tools, so-called AI services, large language models (LLMs), etc.
-If you do make use of such tools or services, then we encourage you to
-describe what tools and how you used those tools, in your `remarks.md` file.
+You are permitted to use tools to write your code.
 
 See [Rule 16 - Anonymous](rules.html#rule-16---anonymous).
 
+See [Guidelines for Rule 7 - Original Work](guidelines.html#guideline-7---original-work).
+
 
 <div id="rule8">
 ## Rule 8 - Submission
@@ -271,7 +284,7 @@ permitted. However, see the guidelines.  Each entry **MUST** automate the
 build process using `bash`, `gmake`, `gcc`, `clang`, under a
 [SUS environment](https://pubs.opengroup.org/onlinepubs/9799919799/).
 
-Note references to `gmake` can be any GNU Make compatible tool.
+**NOTE**: The references to `gmake(1)` can be any GNU Make compatible tool.
 
 See [Rule 15 - Building](rules.html#rule-15---building).
 
@@ -280,7 +293,7 @@ See [Rule 15 - Building](rules.html#rule-15---building).
 ## Rule 10 - Privileges
 </div>
 
-Programs that require special privileges (setuid(2), setgid(2),
+Programs that require special privileges (`setuid(2)`, `setgid(2)`,
 super-user, special owner, special group, etc.) are **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**
@@ -322,6 +335,8 @@ version, please indicate that in your `remarks.md` file of your non-rule
 abusing version so that the Judges don't think you uploaded a duplicate
 into a wrong slot by mistake.
 
+See [Guidelines for Rule 11 - Abuse](guidelines.html#guideline-11---abuse).
+
 
 <div id="rule12">
 ## Rule 12 - UTF-8
@@ -397,6 +412,10 @@ Do **NOT** assume that `.` (current directory) is in the `$PATH` environment var
 
 See [Rule 4 - Files](rules.html#rule-4---files).
 
+See FAQ on "[What are the detailed recommendations for a submission Makefile?](../faq.html#makefile_details)".
+
+See [Guidelines for Rule 15 - Building](guidelines.html#guideline-15---building).
+
 
 <div id="rule16">
 ## Rule 16 - Anonymous
@@ -426,35 +445,47 @@ directory depths of **4**.  The maximum number of files, excluding
 `.info.json` and `.auth.json` is **31**.  And the maximum file-path
 component is **38** and maximum path length is **60**.
 
-The submission **MUST** be a `.txz` compressed tarball as constructed by
-`mkiocccentry(1)`, which **MUST** be within **[1..3999971]** bytes in size.
-The sum of all file lengths, after unpacking from the tarball, **MUST** be
-less than `27651*1024` bytes.
+The submission **MUST** be a `.txz` compressed tarball (i.e., tarball compressed by `xz(1)`)
+as constructed by `mkiocccentry(1)`, which **MUST** be within **[1..3999971]** bytes in size.
 
-The tarball file **MUST** pass all `txzchk(1)` checks and the tarball
-filename **MUST** pass all `fnamchk(1)` checks.  You may **NOT** submit a tarball
-created by the `-d` or `-s` seed options of `mkiocccentry(1)`.
+The tarball **MUST** be a **v7 format** tarball.
+
+The sum of all file lengths, after unpacking from the tarball, **MUST** be
+less than `27651*1024` (**28314624**) bytes.
+
+The submission **MUST** be a tarball file that **MUST** pass all `txzchk(1)` checks, and the tarball
+filename **MUST** pass all `fnamchk(1)` checks.
+
+You may **NOT** submit a tarball created by the `-d`, `-e`, **NOR** by the `-s seed` options of `mkiocccentry(1)`.
 
 The unpacked submission directory **MUST** pass the checks performed by the
 current version of `chksubmit(1)`.
 
+Submissions may **NOT** use a
+[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
+command line options that labeled as "**for TESTING purposes**",
+**NOR** labeled as "**for the use by the IOCCC judges only**",
+in their respective man pages.
+
+Submissions may **ONLY** use
+[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
+command lines that confirm to the command's `-h` "_print help message_".
+
 The `prog.c` file **MUST** pass the [Rule 2 - Size](rules.html#rule-2---size)
 size checks performed by `iocccsize(1)`.
 
-The `.auth.json` and `.info.json` files **MUST** be compatible with what
-`mkiocccentry(1)` generates.
+The `.auth.json` and `.info.json` files **MUST** be compatible with what `chksubmit(1)` generates.
 
-Submissions that package using older versions of the mkiocccentry
-toolkit to are **HIGHLY LIKELY** to be **REJECTED**!  Be sure
-that you are using the latest tools from the
+Any submission that fails to pass the checks performed by the most recent version of the
 [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
-GitHub repo.
-
-In summary: it is best to use `mkioccentry(1)` to package your submission,
-rather than roll-it-by-hand.
+**WILL be rejected**!
 
 See [Rule 4 - Files](rules.html#rule-4---files).
 
+See FAQ on "[What is the mkiocccentry tool, how do I obtain it and how do I use it?](../faq.html#mkiocccentry)".
+
+See [Guidelines for Rule 17 - Packaging](guidelines.html#guideline-17---packaging).
+
 
 <div id="rule18">
 ## Rule 18 - License
@@ -480,16 +511,18 @@ See [Rule 6 - Free](rules.html#rule-6---free).
 
 ## Further Reading
 
+Please read the [Guidelines](guidelines.html) next for further commentary on these rules.
+
 Read the
 [Entering the IOCCC: the bare minimum you need to know](https://www.ioccc.org/quick-start.html#enter)
 for an overview of how to enter the contest.
 
-Please read the [Guidelines](guidelines.html) next for further commentary on The Rules.
-
 See also the [FAQ](../faq.html).
 
+And now [for something completely different](guidelines.html#fun)
+
 Consider joining the [IOCCC Discord Server](https://discord.com/invite/Wa42Qujwnw)
 for discussions about The Rules, questions for the Judges, and `C` in general.
 
-Leonid A. Broukhis  
+Leonid A. Broukhis
 chongo (Landon Curt Noll) /\\cc/\\
diff --git a/sitemap.xml b/sitemap.xml
index 5bcb30d33..ac85cfafb 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -16758,11 +16758,11 @@
 </url>
 <url>
     <loc>https://www.ioccc.org/faq.html</loc>
-    <lastmod>2025-11-24T13:29:41+00:00</lastmod>
+    <lastmod>2025-11-29T08:08:30+00:00</lastmod>
 </url>
 <url>
     <loc>https://www.ioccc.org/faq.md</loc>
-    <lastmod>2025-11-24T13:29:41+00:00</lastmod>
+    <lastmod>2025-11-29T08:08:21+00:00</lastmod>
 </url>
 <url>
     <loc>https://www.ioccc.org/inc/index.html</loc>
@@ -16826,11 +16826,11 @@
 </url>
 <url>
     <loc>https://www.ioccc.org/next/guidelines.html</loc>
-    <lastmod>2025-11-29T04:32:18+00:00</lastmod>
+    <lastmod>2025-11-29T07:45:34+00:00</lastmod>
 </url>
 <url>
     <loc>https://www.ioccc.org/next/guidelines.md</loc>
-    <lastmod>2025-11-29T04:32:18+00:00</lastmod>
+    <lastmod>2025-11-29T07:45:29+00:00</lastmod>
 </url>
 <url>
     <loc>https://www.ioccc.org/next/index.html</loc>
@@ -16870,11 +16870,11 @@
 </url>
 <url>
     <loc>https://www.ioccc.org/next/rules.html</loc>
-    <lastmod>2025-11-29T04:32:18+00:00</lastmod>
+    <lastmod>2025-11-29T07:45:34+00:00</lastmod>
 </url>
 <url>
     <loc>https://www.ioccc.org/next/rules.md</loc>
-    <lastmod>2025-11-29T04:32:18+00:00</lastmod>
+    <lastmod>2025-11-29T07:45:14+00:00</lastmod>
 </url>
 <url>
     <loc>https://www.ioccc.org/next/submit.html</loc>
@@ -16938,7 +16938,7 @@
 </url>
 <url>
     <loc>https://www.ioccc.org/status.html</loc>
-    <lastmod>2025-11-28T05:02:53+00:00</lastmod>
+    <lastmod>2025-11-29T08:12:55+00:00</lastmod>
 </url>
 <url>
     <loc>https://www.ioccc.org/status.json</loc>