mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #243 from xexyl/rules

Browse Source
This commit is contained in:
Landon Curt Noll authored and GitHub committed 2025-11-29 12:20:25 -08:00
2 parents d91f0d62a4 6c49bc8955
commit 24d6d0bb7f
14 files changed
+665 -2670
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

2024/README.md
+3 -3
View File
@@ -77,7 +77,7 @@ become more skilled in the programming in the C language.
We were pleased to observe that while the [IOCCC size limit](../faq.html#size_rule_history)
increased by about 21%, we received many submissions that were well under the new
[Rule 2 Size](../next/rules.html#rule-2-size) including a fair number of quality
[Rule 2](rules.html#rule2) including a fair number of quality
small and medium sized submissions. Half of the **IOCCC28 winners** were less than
_2/3 of the size limit_, and 10 of the **IOCCC28 winners** were less than
_1/2 of the size limit_!
@@ -85,10 +85,10 @@ _1/2 of the size limit_!
**IMPORTANT NOTE**: The [IOCCC size limit](../faq.html#size_rule_history) increase for **IOCCC28**
was the first size increase in over 10 years. Given the quality of submissions we received
that were well under the limit, we do **NOT** expect to change the
[Rule 2 Size](../next/rules.html#rule-2-size) for **at least another 10 years** (and likely longer).
[Rule 2](rules.html#rule2) for **at least another 10 years** (and likely longer).
**IMPORTANT HINT**: Only 3 of the 23 **IOCCC28 winners** came close to the [Rule
2 Size](../next/rules.html#rule-2-size). Large code size isn't everything. :-)
2](rules.html#rule2). Large code size isn't everything. :-)
Those submitting to future contents should **take a careful note** of that fact.
2024/index.html
+4 -4
View File
@@ -513,16 +513,16 @@ become more skilled in the programming in the C language.</p>
<h3 id="code-size-and-rule-2">Code size and Rule 2</h3>
<p>We were pleased to observe that while the <a href="../faq.html#size_rule_history">IOCCC size limit</a>
increased by about 21%, we received many submissions that were well under the new
<a href="../next/rules.html#rule-2-size">Rule 2 Size</a> including a fair number of quality
<a href="rules.html#rule2">Rule 2</a> including a fair number of quality
small and medium sized submissions. Half of the <strong>IOCCC28 winners</strong> were less than
<em>2/3 of the size limit</em>, and 10 of the <strong>IOCCC28 winners</strong> were less than
<em>1/2 of the size limit</em>!</p>
<p><strong>IMPORTANT NOTE</strong>: The <a href="../faq.html#size_rule_history">IOCCC size limit</a> increase for <strong>IOCCC28</strong>
was the first size increase in over 10 years. Given the quality of submissions we received
that were well under the limit, we do <strong>NOT</strong> expect to change the
<a href="../next/rules.html#rule-2-size">Rule 2 Size</a> for <strong>at least another 10 years</strong> (and likely longer).</p>
<p><strong>IMPORTANT HINT</strong>: Only 3 of the 23 <strong>IOCCC28 winners</strong> came close to the <a href="../next/rules.html#rule-2-size">Rule
2 Size</a>. Large code size isn’t everything. :-)
<a href="rules.html#rule2">Rule 2</a> for <strong>at least another 10 years</strong> (and likely longer).</p>
<p><strong>IMPORTANT HINT</strong>: Only 3 of the 23 <strong>IOCCC28 winners</strong> came close to the <a href="rules.html#rule2">Rule
2</a>. Large code size isn’t everything. :-)
Those submitting to future contents should <strong>take a careful note</strong> of that fact.</p>
<h3 id="rules-and-guidelines-for-this-contest">Rules and Guidelines for this contest</h3>
<p>Here are the final versions of the IOCCC rules and guidelines that were in
faq.html
+73 -106
View File
@@ -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>29.01 2025-11-28</strong>.</p>
<p>This is FAQ version <strong>29.02 2025-11-29</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>
@@ -480,7 +480,7 @@
<li><strong>Q 1.4</strong>: <a class="normal" href="#mkiocccentry_test">How can I check if my submission passes tests without having to answer questions?</a></li>
<li><strong>Q 1.5</strong>: <a class="normal" href="#extra-files">What are extra files and how may I include additional files beyond the max allowed?</a></li>
<li><strong>Q 1.6</strong>: <a class="normal" href="#ai">May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?</a></li>
<li><strong>Q 1.7</strong>: <a class="normal" href="#rule17">What are the details behind Rule 17 - Packaging?</a></li>
<li><strong>Q 1.7</strong>: <a class="normal" href="#rule17">What are the details behind Rule 17 - use mkiocccentry?</a></li>
<li><strong>Q 1.8</strong>: <a class="normal" href="#uuid">How can I avoid re-entering my UUID to mkiocccentry?</a></li>
<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>
@@ -493,7 +493,7 @@
<li><strong>Q 2.1</strong>: <a class="normal" href="#feedback">How can I comment or make a suggestion on IOCCC rules, guidelines and tools?</a></li>
<li><strong>Q 2.2</strong>: <a class="normal" href="#warnings">Are there any compiler warnings that I should not worry about in my submissions?</a></li>
<li><strong>Q 2.3</strong>: <a class="normal" href="#frequent-themes">What types of entries have been frequently submitted to the IOCCC?</a></li>
<li><strong>Q 2.4</strong>: <a class="normal" href="#rule_2_broken">How did an entry win the IOCCC that breaks Rule 2 - Size?</a></li>
<li><strong>Q 2.4</strong>: <a class="normal" href="#rule_2_broken">How did an entry win the IOCCC that breaks Rule 2 - Size Limit?</a></li>
<li><strong>Q 2.5</strong>: <a class="normal" href="#submissions">How many submissions do the judges receive for a given IOCCC?</a></li>
<li><strong>Q 2.6</strong>: <a class="normal" href="#judging_time">How much time does it take to judge the contest?</a></li>
<li><strong>Q 2.7</strong>: <a class="normal" href="#judging_rounds">How many judging rounds do you have?</a></li>
@@ -590,10 +590,7 @@
<li><strong>Q 10.3</strong>: <a class="normal" href="#dot_files"> What is the purpose of the <code>.top</code>, <code>.allyear</code>, <code>.year</code> and <code>.path</code> files?</a></li>
<li><strong>Q 10.4</strong>: <a class="normal" href="#terms"> What is the current meaning of the IOCCC terms Author, Entry, and Submission?</a></li>
<li><strong>Q 10.5</strong>: <a class="normal" href="#licence">Am I allowed to use IOCCC content?</a></li>
<li><strong>Q 10.6</strong>: <a class="normal" href="#try_mastodon">What is Mastodon and why does the IOCCC use it?</a>
<ul>
<li><strong>Q 10.6.1</strong>: <a class="normal" href="#mastodon_notifications">How can I get push notifications when the judges post something on mastodon?</a></li>
</ul></li>
<li><strong>Q 10.6</strong>: <a class="normal" href="#try_mastodon">What is Mastodon and why does the IOCCC use it?</a></li>
<li><strong>Q 10.7</strong>: <a class="normal" href="#tabstops">How do I set certain tabstops for viewing source code in vi(m)?</a></li>
<li><strong>Q 10.8</strong>: <a class="normal" href="#menus">How do the menus on the website work and what can I do if they don’t work?</a></li>
<li><strong>Q 10.9</strong>: <a class="normal" href="#author-information">How do I find more information about a winning author of an entry?</a></li>
@@ -659,7 +656,7 @@
repo</a> and it is <strong>required</strong> that you
use it to package your submission. Not doing so puts you at a great risk of
violating the <a href="next/rules.html">Rules</a> and in particular
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="about_mkiocccentry">
<h4 id="q-0.1.1-what-is-mkiocccentry-in-simple-terms">Q 0.1.1: What is <code>mkiocccentry</code> in simple terms?</h4>
@@ -774,7 +771,7 @@ directory</strong> will be created, with the name based on your IOCCC registrati
username, which is <strong>in the form of a UUID</strong>, and submission number along with
the timestamp; see the <a href="next/rules.html">rules</a> for more details on this, and in
particular
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</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
@@ -938,7 +935,7 @@ rounds; we look at the author name only if an entry wins. See the
<li>leaving the remark section empty (which would also indicate that you did not
use <code>mkiocccentry(1)</code>, as it requires it to not be of size 0, though if you only
include whitespace you would still be violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>).</li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>).</li>
</ul>
<p>Jump to: <a href="#">top</a></p>
<div id="try_scripts">
@@ -982,11 +979,12 @@ for more details.</p>
<p>See the
FAQ on “<a href="#rule17">Rule 17</a>”
and
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>
itself.</p>
<p>Do remember that if your submission requires different filenames, then you
<strong>MUST</strong> make a <strong>COPY</strong> of them in your <code>Makefile</code>. See also
<a href="next/rules.html#rule-5---integrity">Rule 5 - Integrity</a>.</p>
<a href="next/rules.html#rule5-modifying-files">Rule 5 - Do NOT modify submitted files or filenames or parent
directories</a>.</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">
@@ -1130,12 +1128,12 @@ level directory.</p>
itself is an extra file, meaning it counts <strong>AS</strong> an extra file.
This file does <strong>NOT</strong> need to pass the <code>txzchk(1)</code> tests; only your submission
tarball needs to pass these tests. However see below if you do do this.</p>
<p>Please pay careful attention to <a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a> and in
<p>Please pay careful attention to <a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a> and in
particular the part about the maximum number of files per
submission, which not only discusses the maximum
number of files but also specific rules you must follow
if you do include a tarball. Not following these points puts you at great risk
of violating <a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
of violating <a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p>
<p>Also, remember what the <a href="next/guidelines.html">guidelines</a> say:</p>
<blockquote>
<p><strong>IMPORTANT REMINDER</strong>: make <strong>SURE</strong> your tarball does <strong>NOT</strong> reveal who you are!
@@ -1159,7 +1157,7 @@ ultimate author of the code you submit.</p>
you used as well as how you used them to help write your submission.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="rule17">
<h3 id="q-1.7-what-are-details-behind-rule-17---packaging">Q 1.7: What are details behind Rule 17 - Packaging?</h3>
<h3 id="q-1.7-what-are-details-behind-rule-17---use-mkiocccentry">Q 1.7: What are details behind Rule 17 - Use mkiocccentry?</h3>
</div>
<h3 id="tldr-rule-17---use-mkiocccentry1">TL;DR Rule 17 - Use <code>mkiocccentry(1)</code></h3>
<p>This is a <strong>COMPLEX</strong> rule. <strong>Violating this rule WILL CAUSE YOUR SUBMISSION TO
@@ -1178,7 +1176,7 @@ contains <strong>IMPORTANT</strong> tools and libraries such as:</p>
<li><code>chksubmit(1)</code> (which uses <code>jparse(3)</code> and is a wrapper to <code>chkentry(1)</code>)</li>
</ul>
<p>The above mentioned tools will help you verify that your submission
conforms to <a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>. Each of these tool has a <code>-h</code>
conforms to <a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>. Each of these tool has a <code>-h</code>
option that provides command line help. For additional details of each tool, see
its man page, and in some cases, the <a href="next/guidelines.html">IOCCC guidelines</a>.</p>
<p>The maximum number of <strong>extra files</strong> is 31. See the
@@ -1228,7 +1226,7 @@ for help.</p>
<p>The <code>remarks.md</code> <strong>MUST</strong> be a <strong>non</strong>-empty file in markdown format
(<code>mkiocccentry(1)</code> only checks the file size but if you do not have any text in
it you still risk violating this rule). See also
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>
and our
FAQ on “<a href="#remarks_md">remarks.md</a>”,
our
@@ -1322,16 +1320,17 @@ permissions and <code>mkiocccentry(1)</code> does this for you. In particular: d
<code>-r-xr-xr-x</code> (i.e. <code>0555</code>); and all other files <strong>MUST</strong> be <code>-r--r--r--</code> (i.e.
<code>0444</code>). If any file or directory does not have the correct permissions, your
submission <strong>WILL</strong> be rejected for violating
<a href="next/rules.html#rule17">Rule 17 - Packaging</a>!</p>
<a href="next/rules.html#rule17">Rule 17 - Use mkiocccentry</a>!</p>
<p>After <code>mkiocccentry(1)</code> creates the directories and copies the files with these
modes, it also verifies them after the fact and if they are not correct it is an
<strong>error</strong>.</p>
<p>If you do need different permissions, then see the
FAQ on “<a href="#file_perms">file permissions</a>”. Also keep in mind
<a href="next/rules.html#rule-4---files">Rule 4 - Files</a>,
<a href="next/rules.html#rule-5---integrity">Rule 5 - Integrity</a>,
<a href="next/rules.html#rule4-required-files">Rule 4 - Required files</a>,
<a href="next/rules.html#rule5-modifying-files">Rule 5 - Do NOT modify submitted files or filenames or parent
directories</a>,
and
<a href="next/rules.html#rule-16---anonymous">Rule 16 - Anonymous</a>.</p>
<a href="next/rules.html#rule16-anonymous-judging">Rule 16 - Anonymous judging</a>.</p>
<p>The <code>txzchk(1)</code> tool will also verify file/directory permissions (and many other
things) for you, and so will <code>chksubmit(1)</code> (along with other checks on files and
directories in your submission directory, including the two required JSON files,
@@ -1344,18 +1343,18 @@ page</a>.</p>
will run <code>fnamchk(1)</code> as part of its algorithm. If you use <code>mkiocccentry(1)</code>
there should be no problem but if you were to package things manually it is
possible there could be a problem and this poses a big risk of violating
<a href="next/rules.html#rule-4---files">Rule 4 - Files</a>
<a href="next/rules.html#rule4-required-files">Rule 4 - Required files</a>
or
<a href="next/rules.html#rule17">Rule 17 - Packaging</a>.</p>
<a href="next/rules.html#rule17">Rule 17 - Use mkiocccentry</a>.</p>
<p>The <code>fnamchk(1)</code>, which <code>txzchk(1)</code> executes, will verify that the
filename is correct. But if you do package your tarball manually, and you have a
mismatch in what is in the tarball and the name, <code>txzchk(1)</code> will flag the
discrepancy as an error and exit with non-zero.</p>
<p>These checks <strong>MUST PASS</strong>. If they do not you stand a significant chance of
having your submission rejected for violating
<a href="next/rules.html#rule-4---files">Rule 4 - Files</a>
<a href="next/rules.html#rule4-required-files">Rule 4 - Required files</a>
or
<a href="next/rules.html#rule17">Rule 17 - Packaging</a>.</p>
<a href="next/rules.html#rule17">Rule 17 - Use mkiocccentry</a>.</p>
<div id="max-files">
<h4 id="maximum-number-of-files-per-submission">Maximum number of files per submission</h4>
</div>
@@ -1385,9 +1384,9 @@ The <code>mkiocccentry(1)</code> tool uses the v7 format. For instance you might
<pre><code> tar --format=v7 -cJf foo.txz directory</code></pre>
<hr style="width:50%;text-align:left;margin-left:0">
<p><strong>IMPORTANT</strong>: where
<a href="next/rules.html#rule-4---files">Rule 4 - Files</a>,
<a href="next/rules.html#rule4-required-files">Rule 4 - Required files</a>,
and
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>
and the tools from the latest
release of the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>
conflict, the <a href="judges.html">IOCCC judges</a> will use their best judgment which
@@ -1422,9 +1421,9 @@ page</a>,
for help here and also read our
FAQ on “<a href="#mkiocccentry_bugs">mkiocccentry repo bugs</a>”.</p>
<p>At the risk of stating the obvious: submissions that violate
<a href="next/rules.html#rule-4---files">Rule 4 - Files</a>,
<a href="next/rules.html#rule4-required-files">Rule 4 - Required files</a>,
or
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>
<strong>WILL BE REJECTED</strong>, so <strong>BE SURE</strong> to use the latest release of the
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>, to form and test
your submission’s xz compressed tarball. Do <strong>NOT</strong> assume you have the most
@@ -1669,7 +1668,7 @@ somehow, <code>txzchk(1)</code> will flag it as an error. When the judges run <c
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>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</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>
@@ -1903,7 +1902,7 @@ of the same theme.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="rule_2_broken">
<div id="rule_breaking_entry">
<h3 id="q-2.4-how-did-an-entry-win-the-ioccc-that-breaks-rule-2---size">Q 2.4: How did an entry win the IOCCC that breaks Rule 2 - Size?</h3>
<h3 id="q-2.4-how-did-an-entry-win-the-ioccc-that-breaks-rule-2---size-restrictions">Q 2.4: How did an entry win the IOCCC that breaks Rule 2 - Size restrictions?</h3>
</div>
</div>
<p>As entries have been fixed it is entirely possible that some of the entries no
@@ -2120,9 +2119,9 @@ two JSON files, <code>.auth.json</code> and <code>.info.json</code> as well as t
<code>.info.json</code> manifest. (Okay there is an option to skip files but this is for
the judges <strong>ONLY</strong>; use of this option to validate your submission puts you at
a great risk of violating
<a href="next/rules.html#rule-4---files">Rule 4 - Files</a>,
<a href="next/rules.html#rule4-required-files">Rule 4 - Required files</a>,
or
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!).</p>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!).</p>
<p>As an example, if your submission directory is
<code>00000000-0000-4000-0000-000000000000-3/</code> then you should run the following
command:</p>
@@ -2142,9 +2141,9 @@ FAQ on “<a href="#auth_json">.auth.json</a>”
and the
FAQ on “<a href="#info_json">.info.json</a>”
as well as
<a href="next/rules.html#rule-4---files">Rule 4 - Files</a>,
<a href="next/rules.html#rule4-required-files">Rule 4 - Required files</a>,
and
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>
for more information.</p>
<p><strong>NOTE</strong>: the <code>chksubmit(1)</code> tool invokes <code>chkentry(1)</code> but as a contestant you
do not need to worry about those details. One should use <code>chksubmit(1)</code> instead
@@ -2235,12 +2234,12 @@ to be valid. If this is not the case your submission <strong>WILL BE</strong> re
<li>The IOCCC contestant ID used as a username in the form of <strong>in the form of
a UUID</strong> and submission number; see the <a href="next/rules.html">Rules</a> for more details
on this, and in particular
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.</li>
</ul>
<p><strong>NOTE:</strong> if the contest ID is <strong>NOT</strong> in this format then <code>fnamchk</code> will
report it as an <strong>error</strong> and your submission <strong>WILL BE</strong> rejected for
violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p></li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.</p></li>
<li><p><code>tarball</code> (double quoted string)</p>
<ul>
<li>The xz compressed tarball filename.</li>
@@ -2248,10 +2247,10 @@ violating
<p><strong>IMPORTANT:</strong> this <strong>MUST</strong> match the actual tarball’s <strong>filename</strong> in order for
this to be valid. If there is a mismatch you stand a great risk of having
your submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!
Moreover, it is possible that <code>txzchk</code> will report a problem through
<code>fnamchk(1)</code> which also puts you at great risk of violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>. The
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>. The
<code>txzchk(1)</code> tool will use the output of <code>fnamchk</code> to
obtain the correct directory <em>name</em> in the tarball; if <code>fnamchk</code> fails to
validate your filename, or if you have the wrong directory name in the
@@ -2266,7 +2265,7 @@ tarball, this will be flaggd.</p></li>
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>). If
this is not the case you stand a great risk of having your submission
rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p></li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.</p></li>
<li><p><code>author_count</code> (number)</p>
<ul>
<li>How many authors this submission has.</li>
@@ -2339,7 +2338,7 @@ the range of 1 <strong>THROUGH</strong> <code>MAX_AFFILIATION_LEN</code> (see
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>). If
this is not the case you stand a great risk of having your submission
rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.</p>
<p><strong>NOTE:</strong> an <strong>affiliation</strong> does <strong>NOT</strong> have any affect on whether you will win or not.</p></li>
<li><p><code>past_winning_author</code> (boolean)</p>
<ul>
@@ -2424,9 +2423,9 @@ will use it on the submission directory as part of the judging process.</p>
is reported invalid by <code>chksubmit(1)</code>, or if your submission directory is
reported invalid by <code>chksubmit(1)</code>, your submission will almost certainly be
rejected for violating the <a href="next/rules.html">Rules</a> and in particular
<a href="next/rules.html#rule-4---files">Rule 4 - Files</a>,
<a href="next/rules.html#rule4-required-files">Rule 4 - Required files</a>,
and
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.</p>
<p>An obvious example where <code>chksubmit(1)</code> would fail to validate <code>.auth.json</code> is if
there is a mismatch of type in the JSON file with what is expected, for
instance, if in <code>.auth.json</code> the <code>no_comment</code> that we chose to not comment on is
@@ -2435,9 +2434,9 @@ out of range (see above for list). Two more examples would be if a field is
missing or if an unknown filed is in the file. In these cases (and any others
that must be established as valid by <code>chksubmit(1)</code>) your submission would be
rejected for violating
<a href="next/rules.html#rule-4---files">Rule 4 - Files</a>,
<a href="next/rules.html#rule4-required-files">Rule 4 - Required files</a>,
and
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>
and in particular
because <code>chksubmit(1)</code> would not validate the <code>.auth.json</code> file (and maybe other
things too).</p>
@@ -2557,7 +2556,7 @@ this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
<li>The IOCCC contestant ID used as a username in the form of <strong>in the form of
a UUID</strong> and submission number; see the <a href="next/rules.html">rules</a> for more details
on this, and in particular
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.</li>
</ul></li>
<li><p><code>submit_slot</code> (number)</p>
<ul>
@@ -2569,7 +2568,7 @@ on this, and in particular
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>). If
this is not the case you stand a great risk of having your submission
rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p></li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.</p></li>
<li><p><code>title</code> (double quoted string)</p>
<ul>
<li>A short name (length &gt;= 1 <strong>THROUGH</strong> <code>MAX_TITLE_LEN</code>, defined in
@@ -2579,7 +2578,7 @@ matches the regexp <code>[a-z0-9][a-z0-9_+-]*</code>.</li>
</ul>
<p><strong>IMPORTANT:</strong> if this is <strong>NOT</strong> the case you stand a great risk of having your submission
rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p></li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p></li>
<li><p><code>abstract</code> (double quoted string)</p>
<ul>
<li>A one line summary of your submission, with a length of 1 <strong>THROUGH</strong>
@@ -2590,7 +2589,7 @@ in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a
<p>The <code>abstract</code> may not contain a <code>;</code> (semicolon), nor <code>&amp;</code> (ampersand), nor <code>,</code> (comma).</p>
<p><strong>IMPORTANT:</strong> if your abstract is 0 in length or &gt; the maximum abstract length you
stand a great risk of having your submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p></li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p></li>
<li><p><code>tarball</code> (double quoted string)</p>
<ul>
<li>The xz compressed tarball filename.</li>
@@ -2598,27 +2597,27 @@ stand a great risk of having your submission rejected for violating
<p><strong>IMPORTANT:</strong> this <strong>MUST</strong> match the actual tarball’s <strong>filename</strong> in order for
this to be valid. If there is a mismatch you stand a great risk of having
your submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!
Moreover, it is possible that <code>txzchk</code> will report a problem through
<code>fnamchk(1)</code> which also puts you at great risk of violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.
The <code>txzchk(1)</code> tool will use the output of <code>fnamchk</code> to
obtain the correct directory <em>name</em> in the tarball; if <code>fnamchk</code> fails to
validate your filename, or if you have the wrong directory name in the
tarball, this will be flaggd.</p></li>
<li><p><code>rule_2a_size</code> (number)</p>
<ul>
<li>The size calculated of <a href="next/rules.html#rule-2a-gross-size">Rule 2a Gross Size</a>.</li>
<li>The size calculated of <a href="next/rules.html#rule2a-gross-size">Rule 2a - Gross Size</a>.</li>
</ul>
<p><strong>IMPORTANT:</strong> if this violates <a href="next/rules.html#rule2a">Rule 2a</a> you stand a great
chance of having your submission rejected for violating the
<a href="next/rules.html">Rules</a>!</p></li>
<li><p><code>rule_2b_size</code> (number)</p>
<ul>
<li>The size calculated of <a href="next/rules.html#rule-2b-net-size">Rule 2b Next Size</a>.</li>
<li>The size calculated of <a href="next/rules.html#rule2b-net-size">Rule 2b - Net Size</a>.</li>
</ul>
<p><strong>IMPORTANT:</strong> if this violates
<a href="next/rules.html#rule-2b-net-size">Rule 2b Next Size</a>
<a href="next/rules.html#rule2b-net-size">Rule 2b Net Size</a>
you stand a great
chance of having your submission rejected for violating the
<a href="next/rules.html">Rules</a>!</p></li>
@@ -2629,55 +2628,39 @@ chance of having your submission rejected for violating the
<li><p><code>rule_2a_override</code> (boolean)</p>
<ul>
<li><code>true</code> if user overrides warning of
<a href="next/rules.html#rule-2a-gross-size">Rule 2a Gross Size</a>
<a href="next/rules.html#rule2a-gross-size">Rule 2a - Gross Size</a>
violation, else <code>false</code>.</li>
</ul>
<p><strong>IMPORTANT:</strong> if the
<a href="next/rules.html#rule-2a-gross-size">Rule 2a Gross Size</a>
<a href="next/rules.html#rule2a-gross-size">Rule 2a - Gross Size</a>
calculated size is <strong>NOT</strong>
violated but this is <code>true</code> then you stand a good chance of having your
submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p></li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.</p></li>
<li><p><code>rule_2a_mismatch</code> (boolean)</p>
<ul>
<li><code>true</code> if
<a href="next/rules.html#rule-2a-gross-size">Rule 2a Gross Size</a>
<a href="next/rules.html#rule2a-gross-size">Rule 2a - Gross Size</a>
calculated size is not the
same as the file size.</li>
</ul></li>
<li><p><code>rule_2b_override</code> (boolean)</p>
<ul>
<li><code>true</code> if user overrides warning of
<a href="next/rules.html#rule-2b-net-size">Rule 2b Next Size</a>
<a href="next/rules.html#rule2b-net-size">Rule 2b - Net Size</a>
violation, else <code>false</code>.</li>
</ul>
<p><strong>IMPORTANT:</strong> if the
<a href="next/rules.html#rule-2b-net-size">Rule 2b Next Size</a>
<a href="next/rules.html#rule2b-net-size">Rule 2b - Net Size</a>
calculated size is <strong>NOT</strong>
violated but this is <code>true</code> then you stand a good chance of having your
submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p></li>
<li><p><code>highbit_warning</code> (boolean)</p>
<ul>
<li><code>true</code> if <code>iocccsize</code> detects a high bit (unescaped octets with the high
bit set - octet value &gt;= 128); see
<a href="next/rules.html#rule-12---utf-8">Rule 12 - UTF-8</a>,
else <code>false</code>.</li>
</ul></li>
<li><p><code>nul_warning</code> (boolean)</p>
<ul>
<li><code>true</code> if <code>iocccsize</code> detects a NUL character in the <code>prog.c</code>, else
<code>false</code>.</li>
</ul></li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.</p></li>
<li><p><code>trigraph_warning</code> (boolean)</p>
<ul>
<li><code>true</code> if <code>iocccsize</code> detects an unknown or invalid trigraph in
<code>prog.c</code>, else <code>false</code>.</li>
</ul></li>
<li><p><code>wordbuf_warning</code> (boolean)</p>
<ul>
<li>This is ignored and will be removed for IOCCC29 and beyond.</li>
</ul></li>
<li><p><code>ungetc_warning</code> (boolean)</p>
<ul>
<li><code>true</code> if <code>prog.c</code> triggered an <code>ungetc(3)</code> error, else <code>false</code>.</li>
@@ -2689,7 +2672,7 @@ else <code>false</code>.</li>
</ul>
<p><strong>IMPORTANT:</strong> if the <code>Makefile</code> file has no problems and this is <code>true</code> then
you stand a good chance of having your submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p>
<p>See the
FAQ on “<a href="#makefile">Makefile</a>”
for more information.</p></li>
@@ -2699,7 +2682,7 @@ for more information.</p></li>
</ul>
<p><strong>IMPORTANT:</strong>: if the <code>Makefile</code> file does <strong>NOT</strong> have an <code>all</code> rule then
you stand a good chance of having your submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p>
<p>See the
FAQ on “<a href="#makefile">Makefile</a>”
for more information.</p></li>
@@ -2710,7 +2693,7 @@ for more information.</p></li>
<p><strong>IMPORTANT:</strong> if the <code>Makefile</code> file does <strong>NOT</strong> have an <code>all</code> rule and this
boolean is <code>true</code> then you stand a good chance of having your
submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p>
<p>See the
FAQ on “<a href="#makefile">Makefile</a>”
for more information.</p></li>
@@ -2721,7 +2704,7 @@ for more information.</p></li>
<p><strong>IMPORTANT:</strong> if the <code>Makefile</code> file does <strong>NOT</strong> have a <code>clean</code> rule and this
boolean is <code>true</code> then you stand a good chance of having your submission
rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p>
<p>See the
FAQ on “<a href="#makefile">Makefile</a>”
for more information.</p></li>
@@ -2732,7 +2715,7 @@ for more information.</p></li>
<p><strong>IMPORTANT:</strong> if the <code>Makefile</code> file does <strong>NOT</strong> have an <code>clobber</code> rule and this
boolean is <code>true</code> then you stand a good chance of having your submission
rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p>
<p>See the
FAQ on “<a href="#makefile">Makefile</a>”
for more information.</p></li>
@@ -2743,7 +2726,7 @@ for more information.</p></li>
<p><strong>IMPORTANT:</strong> if the <code>Makefile</code> file does <strong>NOT</strong> have a <code>try</code> rule and this
boolean is <code>true</code> then you stand a good chance of having your submission
rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p>
<p>See the
FAQ on “<a href="#makefile">Makefile</a>”
for more information.</p></li>
@@ -2769,7 +2752,7 @@ for more information.</li>
</ul>
<p><strong>IMPORTANT:</strong> if this is <strong>NOT</strong> the case you stand a
great chance of having your submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p></li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p></li>
<li><p><code>auth_JSON</code> (double quoted string)</p>
<ul>
<li>This <code>MUST</code> be <code>".auth.json"</code>, defined as <code>AUTH_JSON_FILENAME</code> in
@@ -2782,7 +2765,7 @@ for more information.</li>
</ul>
<p><strong>IMPORTANT:</strong> if this is <strong>NOT</strong> the case you stand a great chance of having your
submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p></li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p></li>
<li><p><code>c_src</code> (double quoted string)</p>
<ul>
<li>This <code>MUST</code> be <code>"prog.c"</code>, defined as <code>PROG_C_FILENAME</code> in
@@ -2792,7 +2775,7 @@ is your submission source code.</li>
</ul>
<p><strong>IMPORTANT:</strong> if this is <strong>NOT</strong> the case you stand a great chance of having your
submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p></li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p></li>
<li><p><code>Makefile</code> (double quoted string)</p>
<ul>
<li>This <code>MUST</code> be <code>"Makefile"</code>, defined as <code>MAKEFILE_FILENAME</code> in
@@ -2805,7 +2788,7 @@ for more information.</li>
</ul>
<p><strong>IMPORTANT:</strong> if this is <strong>NOT</strong> the case you stand a great chance of having your
submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p></li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p></li>
<li><p><code>remarks</code> (double quoted string)</p>
<ul>
<li>This <code>MUST</code> be <code>"remarks.md"</code>, defined as <code>REMARKS_FILENAME</code> in
@@ -2818,7 +2801,7 @@ for more information.</li>
</ul>
<p><strong>IMPORTANT:</strong> if this is <strong>NOT</strong> the case you stand a great chance of having your
submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p></li>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p></li>
</ul>
<p>The <code>manifest</code> <strong>array</strong> also <strong>OPTIONALLY</strong> has one or more of the field:</p>
<ul>
@@ -2831,7 +2814,7 @@ and <code>chksubmit</code> will verify this for you; it is <strong>ALSO</strong>
filenames are not unique, not POSIX plus + safe chars only, if they are the
wrong permission and various other things. In these cases you stand a great
risk of having your submission rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!
On the other hand, <strong>ONLY</strong> <code>mkiocccentry</code> will
verify that the files exist and can be read; <code>txzchk(1)</code> will <strong>NOT</strong> do
this for you as it only <strong>LISTS</strong> the tarball: it does <strong>NOT</strong> extract it.
@@ -2894,7 +2877,7 @@ out of range (see above for list). Two more examples would be if a field is
missing or if an unknown filed is in the file. In these cases (and any others
that must be established as valid by <code>chksubmit</code>) your submission would be
rejected for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>,
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>,
and in particular
because <code>chksubmit</code> would not validate the <code>.info.json</code> file.</p>
<p>If you wish to <strong>verify</strong> that your <code>.info.json</code> file is valid <strong>JSON</strong> then see the
@@ -5858,22 +5841,6 @@ follow posts something so you will have to check the IOCCC feed manually.</p>
mastodon feed</a> page and/or mastodon
app from time to time to view IOCCC mastodon updates.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="mastodon_notifications">
<h3 id="q-10.6.1-how-can-i-get-push-notifications-when-the-judges-post-something-on-mastodon">Q 10.6.1: How can I get push notifications when the judges post something on mastodon?</h3>
</div>
<p>To do this you need to go to the <a href="https://fosstodon.org/@ioccc">IOCCC mastodon
account</a> with a computer (it is unclear how to do
this with a mobile device, if it is even possible) and then you should see a
bell icon. Make sure it’s activated. If you mouse over it when it’s not enabled
it should look something like this, assuming of course we follow you! :-) (if
not the message about following each other won’t show up):</p>
<p><img src="png/mastodon-notifications.png"
alt="screenshot of Mastodon push notifications"
width=912 height=556></p>
<p>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.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="tabstops">
<h3 id="q-10.7-how-do-i-set-certain-tabstops-for-viewing-source-code-in-vim">Q 10.7: How do I set certain tabstops for viewing source code in vi(m)?</h3>
</div>
faq.md
+72 -107
View File
@@ -1,6 +1,6 @@
# IOCCC FAQ Table of Contents
This is FAQ version **29.01 2025-11-28**.
This is FAQ version **29.02 2025-11-29**.
## 0. [Entering the IOCCC: the bare minimum you need to know](#enter_questions)
@@ -26,7 +26,7 @@ This is FAQ version **29.01 2025-11-28**.
- **Q 1.4**: <a class="normal" href="#mkiocccentry_test">How can I check if my submission passes tests without having to answer questions?</a>
- **Q 1.5**: <a class="normal" href="#extra-files">What are extra files and how may I include additional files beyond the max allowed?</a>
- **Q 1.6**: <a class="normal" href="#ai">May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?</a>
- **Q 1.7**: <a class="normal" href="#rule17">What are the details behind Rule 17 - Packaging?</a>
- **Q 1.7**: <a class="normal" href="#rule17">What are the details behind Rule 17 - use mkiocccentry?</a>
- **Q 1.8**: <a class="normal" href="#uuid">How can I avoid re-entering my UUID to mkiocccentry?</a>
- **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>
@@ -39,7 +39,7 @@ This is FAQ version **29.01 2025-11-28**.
- **Q 2.1**: <a class="normal" href="#feedback">How can I comment or make a suggestion on IOCCC rules, guidelines and tools?</a>
- **Q 2.2**: <a class="normal" href="#warnings">Are there any compiler warnings that I should not worry about in my submissions?</a>
- **Q 2.3**: <a class="normal" href="#frequent-themes">What types of entries have been frequently submitted to the IOCCC?</a>
- **Q 2.4**: <a class="normal" href="#rule_2_broken">How did an entry win the IOCCC that breaks Rule 2 - Size?</a>
- **Q 2.4**: <a class="normal" href="#rule_2_broken">How did an entry win the IOCCC that breaks Rule 2 - Size Limit?</a>
- **Q 2.5**: <a class="normal" href="#submissions">How many submissions do the judges receive for a given IOCCC?</a>
- **Q 2.6**: <a class="normal" href="#judging_time">How much time does it take to judge the contest?</a>
- **Q 2.7**: <a class="normal" href="#judging_rounds">How many judging rounds do you have?</a>
@@ -133,7 +133,6 @@ This is FAQ version **29.01 2025-11-28**.
- **Q 10.4**: <a class="normal" href="#terms"> What is the current meaning of the IOCCC terms Author, Entry, and Submission?</a>
- **Q 10.5**: <a class="normal" href="#licence">Am I allowed to use IOCCC content?</a>
- **Q 10.6**: <a class="normal" href="#try_mastodon">What is Mastodon and why does the IOCCC use it?</a>
- **Q 10.6.1**: <a class="normal" href="#mastodon_notifications">How can I get push notifications when the judges post something on mastodon?</a>
- **Q 10.7**: <a class="normal" href="#tabstops">How do I set certain tabstops for viewing source code in vi&lpar;m&rpar;?</a>
- **Q 10.8**: <a class="normal" href="#menus">How do the menus on the website work and what can I do if they don't work?</a>
- **Q 10.9**: <a class="normal" href="#author-information">How do I find more information about a winning author of an entry?</a>
@@ -216,7 +215,7 @@ This toolkit is from the [mkiocccentry
repo](https://github.com/ioccc-src/mkiocccentry) and it is **required** that you
use it to package your submission. Not doing so puts you at a great risk of
violating the [Rules](next/rules.html) and in particular
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
Jump to: [top](#)
@@ -387,7 +386,7 @@ directory** will be created, with the name based on your IOCCC registration
username, which is **in the form of a UUID**, and submission number along with
the timestamp; see the [rules](next/rules.html) for more details on this, and in
particular
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-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
@@ -582,7 +581,7 @@ rounds; we look at the author name only if an entry wins. See the
- leaving the remark section empty (which would also indicate that you did not
use `mkiocccentry(1)`, as it requires it to not be of size 0, though if you only
include whitespace you would still be violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)).
Jump to: [top](#)
@@ -641,12 +640,13 @@ for more details.
See the
FAQ on "[Rule 17](#rule17)"
and
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)
itself.
Do remember that if your submission requires different filenames, then you
**MUST** make a **COPY** of them in your `Makefile`. See also
[Rule 5 - Integrity](next/rules.html#rule-5---integrity).
[Rule 5 - Do NOT modify submitted files or filenames or parent
directories](next/rules.html#rule5-modifying-files).
Jump to: [top](#)
@@ -858,12 +858,12 @@ itself is an extra file, meaning it counts **AS** an extra file.
This file does **NOT** need to pass the `txzchk(1)` tests; only your submission
tarball needs to pass these tests. However see below if you do do this.
Please pay careful attention to [Rule 17 - Packaging](next/rules.html#rule-17---packaging) and in
Please pay careful attention to [Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry) and in
particular the part about the maximum number of files per
submission, which not only discusses the maximum
number of files but also specific rules you must follow
if you do include a tarball. Not following these points puts you at great risk
of violating [Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
of violating [Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
Also, remember what the [guidelines](next/guidelines.html) say:
@@ -902,7 +902,7 @@ Jump to: [top](#)
<div id="rule17">
### Q 1.7: What are details behind Rule 17 - Packaging?
### Q 1.7: What are details behind Rule 17 - Use mkiocccentry?
</div>
@@ -925,7 +925,7 @@ contains **IMPORTANT** tools and libraries such as:
- `chksubmit(1)` (which uses `jparse(3)` and is a wrapper to `chkentry(1)`)
The above mentioned tools will help you verify that your submission
conforms to [Rule 17 - Packaging](next/rules.html#rule-17---packaging). Each of these tool has a `-h`
conforms to [Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry). Each of these tool has a `-h`
option that provides command line help. For additional details of each tool, see
its man page, and in some cases, the [IOCCC guidelines](next/guidelines.html).
@@ -988,7 +988,7 @@ for help.
The `remarks.md` **MUST** be a **non**-empty file in markdown format
(`mkiocccentry(1)` only checks the file size but if you do not have any text in
it you still risk violating this rule). See also
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)
and our
FAQ on "[remarks.md](#remarks_md)",
our
@@ -1096,7 +1096,7 @@ permissions and `mkiocccentry(1)` does this for you. In particular: directories
`-r-xr-xr-x` (i.e. `0555`); and all other files **MUST** be `-r--r--r--` (i.e.
`0444`). If any file or directory does not have the correct permissions, your
submission **WILL** be rejected for violating
[Rule 17 - Packaging](next/rules.html#rule17)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17)!
After `mkiocccentry(1)` creates the directories and copies the files with these
modes, it also verifies them after the fact and if they are not correct it is an
@@ -1104,10 +1104,11 @@ modes, it also verifies them after the fact and if they are not correct it is an
If you do need different permissions, then see the
FAQ on "[file permissions](#file_perms)". Also keep in mind
[Rule 4 - Files](next/rules.html#rule-4---files),
[Rule 5 - Integrity](next/rules.html#rule-5---integrity),
[Rule 4 - Required files](next/rules.html#rule4-required-files),
[Rule 5 - Do NOT modify submitted files or filenames or parent
directories](next/rules.html#rule5-modifying-files),
and
[Rule 16 - Anonymous](next/rules.html#rule-16---anonymous).
[Rule 16 - Anonymous judging](next/rules.html#rule16-anonymous-judging).
The `txzchk(1)` tool will also verify file/directory permissions (and many other
things) for you, and so will `chksubmit(1)` (along with other checks on files and
@@ -1122,9 +1123,9 @@ The tarball filename **MUST** pass `fnamchk(1)`; the tool `txzchk(1)`
will run `fnamchk(1)` as part of its algorithm. If you use `mkiocccentry(1)`
there should be no problem but if you were to package things manually it is
possible there could be a problem and this poses a big risk of violating
[Rule 4 - Files](next/rules.html#rule-4---files)
[Rule 4 - Required files](next/rules.html#rule4-required-files)
or
[Rule 17 - Packaging](next/rules.html#rule17).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17).
The `fnamchk(1)`, which `txzchk(1)` executes, will verify that the
@@ -1134,9 +1135,9 @@ discrepancy as an error and exit with non-zero.
These checks **MUST PASS**. If they do not you stand a significant chance of
having your submission rejected for violating
[Rule 4 - Files](next/rules.html#rule-4---files)
[Rule 4 - Required files](next/rules.html#rule4-required-files)
or
[Rule 17 - Packaging](next/rules.html#rule17).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17).
<div id="max-files">
#### Maximum number of files per submission
@@ -1177,9 +1178,9 @@ The `mkiocccentry(1)` tool uses the v7 format. For instance you might try:
<hr style="width:50%;text-align:left;margin-left:0">
**IMPORTANT**: where
[Rule 4 - Files](next/rules.html#rule-4---files),
[Rule 4 - Required files](next/rules.html#rule4-required-files),
and
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)
and the tools from the latest
release of the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
conflict, the [IOCCC judges](judges.html) will use their best judgment which
@@ -1220,9 +1221,9 @@ for help here and also read our
FAQ on "[mkiocccentry repo bugs](#mkiocccentry_bugs)".
At the risk of stating the obvious: submissions that violate
[Rule 4 - Files](next/rules.html#rule-4---files),
[Rule 4 - Required files](next/rules.html#rule4-required-files),
or
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)
**WILL BE REJECTED**, so **BE SURE** to use the latest release of the
[mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry), to form and test
your submission's xz compressed tarball. Do **NOT** assume you have the most
@@ -1594,7 +1595,7 @@ 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)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
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
@@ -1911,7 +1912,7 @@ Jump to: [top](#)
<div id="rule_2_broken">
<div id="rule_breaking_entry">
### Q 2.4: How did an entry win the IOCCC that breaks Rule 2 - Size?
### Q 2.4: How did an entry win the IOCCC that breaks Rule 2 - Size restrictions?
</div>
</div>
@@ -2210,9 +2211,9 @@ two JSON files, `.auth.json` and `.info.json` as well as the `prog.c`,
`.info.json` manifest. (Okay there is an option to skip files but this is for
the judges **ONLY**; use of this option to validate your submission puts you at
a great risk of violating
[Rule 4 - Files](next/rules.html#rule-4---files),
[Rule 4 - Required files](next/rules.html#rule4-required-files),
or
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!).
As an example, if your submission directory is
`00000000-0000-4000-0000-000000000000-3/` then you should run the following
@@ -2239,9 +2240,9 @@ FAQ on "[.auth.json](#auth_json)"
and the
FAQ on "[.info.json](#info_json)"
as well as
[Rule 4 - Files](next/rules.html#rule-4---files),
[Rule 4 - Required files](next/rules.html#rule4-required-files),
and
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)
for more information.
**NOTE**: the `chksubmit(1)` tool invokes `chkentry(1)` but as a contestant you
@@ -2336,12 +2337,12 @@ In order of the file's contents we describe each required field, below:
* The IOCCC contestant ID used as a username in the form of **in the form of
a UUID** and submission number; see the [Rules](next/rules.html) for more details
on this, and in particular
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
**NOTE:** if the contest ID is **NOT** in this format then `fnamchk` will
report it as an **error** and your submission **WILL BE** rejected for
violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
- `tarball` (double quoted string)
* The xz compressed tarball filename.
@@ -2349,10 +2350,10 @@ In order of the file's contents we describe each required field, below:
**IMPORTANT:** this **MUST** match the actual tarball's **filename** in order for
this to be valid. If there is a mismatch you stand a great risk of having
your submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
Moreover, it is possible that `txzchk` will report a problem through
`fnamchk(1)` which also puts you at great risk of violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging). The
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry). The
`txzchk(1)` tool will use the output of `fnamchk` to
obtain the correct directory _name_ in the tarball; if `fnamchk` fails to
validate your filename, or if you have the wrong directory name in the
@@ -2367,7 +2368,7 @@ In order of the file's contents we describe each required field, below:
in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry/)). If
this is not the case you stand a great risk of having your submission
rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
- `author_count` (number)
* How many authors this submission has.
@@ -2432,7 +2433,7 @@ author(s) of the submission:
in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry/)). If
this is not the case you stand a great risk of having your submission
rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
**NOTE:** an **affiliation** does **NOT** have any affect on whether you will win or not.
@@ -2517,9 +2518,9 @@ At the risk of stating the obvious, if your `.auth.json` file is invalid JSON or
is reported invalid by `chksubmit(1)`, or if your submission directory is
reported invalid by `chksubmit(1)`, your submission will almost certainly be
rejected for violating the [Rules](next/rules.html) and in particular
[Rule 4 - Files](next/rules.html#rule-4---files),
[Rule 4 - Required files](next/rules.html#rule4-required-files),
and
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
An obvious example where `chksubmit(1)` would fail to validate `.auth.json` is if
there is a mismatch of type in the JSON file with what is expected, for
@@ -2529,9 +2530,9 @@ out of range (see above for list). Two more examples would be if a field is
missing or if an unknown filed is in the file. In these cases (and any others
that must be established as valid by `chksubmit(1)`) your submission would be
rejected for violating
[Rule 4 - Files](next/rules.html#rule-4---files),
[Rule 4 - Required files](next/rules.html#rule4-required-files),
and
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)
and in particular
because `chksubmit(1)` would not validate the `.auth.json` file (and maybe other
things too).
@@ -2655,7 +2656,7 @@ In order of the file's contents we describe each required field, below:
* The IOCCC contestant ID used as a username in the form of **in the form of
a UUID** and submission number; see the [rules](next/rules.html) for more details
on this, and in particular
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
- `submit_slot` (number)
* The submission number.
@@ -2666,7 +2667,7 @@ In order of the file's contents we describe each required field, below:
in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry/)). If
this is not the case you stand a great risk of having your submission
rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
- `title` (double quoted string)
* A short name (length >= 1 **THROUGH** `MAX_TITLE_LEN`, defined in
@@ -2676,7 +2677,7 @@ In order of the file's contents we describe each required field, below:
**IMPORTANT:** if this is **NOT** the case you stand a great risk of having your submission
rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
- `abstract` (double quoted string)
* A one line summary of your submission, with a length of 1 **THROUGH**
@@ -2688,7 +2689,7 @@ In order of the file's contents we describe each required field, below:
**IMPORTANT:** if your abstract is 0 in length or > the maximum abstract length you
stand a great risk of having your submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
- `tarball` (double quoted string)
* The xz compressed tarball filename.
@@ -2696,27 +2697,27 @@ In order of the file's contents we describe each required field, below:
**IMPORTANT:** this **MUST** match the actual tarball's **filename** in order for
this to be valid. If there is a mismatch you stand a great risk of having
your submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
Moreover, it is possible that `txzchk` will report a problem through
`fnamchk(1)` which also puts you at great risk of violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
The `txzchk(1)` tool will use the output of `fnamchk` to
obtain the correct directory _name_ in the tarball; if `fnamchk` fails to
validate your filename, or if you have the wrong directory name in the
tarball, this will be flaggd.
- `rule_2a_size` (number)
* The size calculated of [Rule 2a Gross Size](next/rules.html#rule-2a-gross-size).
* The size calculated of [Rule 2a - Gross Size](next/rules.html#rule2a-gross-size).
**IMPORTANT:** if this violates [Rule 2a](next/rules.html#rule2a) you stand a great
chance of having your submission rejected for violating the
[Rules](next/rules.html)!
- `rule_2b_size` (number)
* The size calculated of [Rule 2b Next Size](next/rules.html#rule-2b-net-size).
* The size calculated of [Rule 2b - Net Size](next/rules.html#rule2b-net-size).
**IMPORTANT:** if this violates
[Rule 2b Next Size](next/rules.html#rule-2b-net-size)
[Rule 2b Net Size](next/rules.html#rule2b-net-size)
you stand a great
chance of having your submission rejected for violating the
[Rules](next/rules.html)!
@@ -2726,51 +2727,38 @@ In order of the file's contents we describe each required field, below:
- `rule_2a_override` (boolean)
* `true` if user overrides warning of
[Rule 2a Gross Size](next/rules.html#rule-2a-gross-size)
[Rule 2a - Gross Size](next/rules.html#rule2a-gross-size)
violation, else `false`.
**IMPORTANT:** if the
[Rule 2a Gross Size](next/rules.html#rule-2a-gross-size)
[Rule 2a - Gross Size](next/rules.html#rule2a-gross-size)
calculated size is **NOT**
violated but this is `true` then you stand a good chance of having your
submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
- `rule_2a_mismatch` (boolean)
* `true` if
[Rule 2a Gross Size](next/rules.html#rule-2a-gross-size)
[Rule 2a - Gross Size](next/rules.html#rule2a-gross-size)
calculated size is not the
same as the file size.
- `rule_2b_override` (boolean)
* `true` if user overrides warning of
[Rule 2b Next Size](next/rules.html#rule-2b-net-size)
[Rule 2b - Net Size](next/rules.html#rule2b-net-size)
violation, else `false`.
**IMPORTANT:** if the
[Rule 2b Next Size](next/rules.html#rule-2b-net-size)
[Rule 2b - Net Size](next/rules.html#rule2b-net-size)
calculated size is **NOT**
violated but this is `true` then you stand a good chance of having your
submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
- `highbit_warning` (boolean)
* `true` if `iocccsize` detects a high bit (unescaped octets with the high
bit set - octet value >= 128); see
[Rule 12 - UTF-8](next/rules.html#rule-12---utf-8),
else `false`.
- `nul_warning` (boolean)
* `true` if `iocccsize` detects a NUL character in the `prog.c`, else
`false`.
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
- `trigraph_warning` (boolean)
* `true` if `iocccsize` detects an unknown or invalid trigraph in
`prog.c`, else `false`.
- `wordbuf_warning` (boolean)
* This is ignored and will be removed for IOCCC29 and beyond.
- `ungetc_warning` (boolean)
* `true` if `prog.c` triggered an `ungetc(3)` error, else `false`.
@@ -2780,7 +2768,7 @@ In order of the file's contents we describe each required field, below:
**IMPORTANT:** if the `Makefile` file has no problems and this is `true` then
you stand a good chance of having your submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
See the
FAQ on "[Makefile](#makefile)"
@@ -2791,7 +2779,7 @@ In order of the file's contents we describe each required field, below:
**IMPORTANT:**: if the `Makefile` file does **NOT** have an `all` rule then
you stand a good chance of having your submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
See the
FAQ on "[Makefile](#makefile)"
@@ -2803,7 +2791,7 @@ In order of the file's contents we describe each required field, below:
**IMPORTANT:** if the `Makefile` file does **NOT** have an `all` rule and this
boolean is `true` then you stand a good chance of having your
submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
See the
FAQ on "[Makefile](#makefile)"
@@ -2815,7 +2803,7 @@ In order of the file's contents we describe each required field, below:
**IMPORTANT:** if the `Makefile` file does **NOT** have a `clean` rule and this
boolean is `true` then you stand a good chance of having your submission
rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
See the
FAQ on "[Makefile](#makefile)"
@@ -2827,7 +2815,7 @@ In order of the file's contents we describe each required field, below:
**IMPORTANT:** if the `Makefile` file does **NOT** have an `clobber` rule and this
boolean is `true` then you stand a good chance of having your submission
rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
See the
FAQ on "[Makefile](#makefile)"
@@ -2839,7 +2827,7 @@ In order of the file's contents we describe each required field, below:
**IMPORTANT:** if the `Makefile` file does **NOT** have a `try` rule and this
boolean is `true` then you stand a good chance of having your submission
rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
See the
FAQ on "[Makefile](#makefile)"
@@ -2865,7 +2853,7 @@ The `mkiocccentry(1)` tool will write it in this order:
**IMPORTANT:** if this is **NOT** the case you stand a
great chance of having your submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
- `auth_JSON` (double quoted string)
* This `MUST` be `".auth.json"`, defined as `AUTH_JSON_FILENAME` in
@@ -2878,7 +2866,7 @@ The `mkiocccentry(1)` tool will write it in this order:
**IMPORTANT:** if this is **NOT** the case you stand a great chance of having your
submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
- `c_src` (double quoted string)
* This `MUST` be `"prog.c"`, defined as `PROG_C_FILENAME` in
@@ -2888,7 +2876,7 @@ The `mkiocccentry(1)` tool will write it in this order:
**IMPORTANT:** if this is **NOT** the case you stand a great chance of having your
submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
- `Makefile` (double quoted string)
* This `MUST` be `"Makefile"`, defined as `MAKEFILE_FILENAME` in
@@ -2901,7 +2889,7 @@ The `mkiocccentry(1)` tool will write it in this order:
**IMPORTANT:** if this is **NOT** the case you stand a great chance of having your
submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
- `remarks` (double quoted string)
* This `MUST` be `"remarks.md"`, defined as `REMARKS_FILENAME` in
@@ -2914,7 +2902,7 @@ The `mkiocccentry(1)` tool will write it in this order:
**IMPORTANT:** if this is **NOT** the case you stand a great chance of having your
submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
The `manifest` **array** also **OPTIONALLY** has one or more of the field:
@@ -2927,7 +2915,7 @@ The `manifest` **array** also **OPTIONALLY** has one or more of the field:
filenames are not unique, not POSIX plus + safe chars only, if they are the
wrong permission and various other things. In these cases you stand a great
risk of having your submission rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
On the other hand, **ONLY** `mkiocccentry` will
verify that the files exist and can be read; `txzchk(1)` will **NOT** do
this for you as it only **LISTS** the tarball: it does **NOT** extract it.
@@ -2991,7 +2979,7 @@ out of range (see above for list). Two more examples would be if a field is
missing or if an unknown filed is in the file. In these cases (and any others
that must be established as valid by `chksubmit`) your submission would be
rejected for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging),
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry),
and in particular
because `chksubmit` would not validate the `.info.json` file.
@@ -7437,29 +7425,6 @@ app from time to time to view IOCCC mastodon updates.
Jump to: [top](#)
<div id="mastodon_notifications">
### Q 10.6.1: How can I get push notifications when the judges post something on mastodon?
</div>
To do this you need to go to the [IOCCC mastodon
account](https://fosstodon.org/@ioccc) with a computer (it is unclear how to do
this with a mobile device, if it is even possible) and then you should see a
bell icon. Make sure it's activated. If you mouse over it when it's not enabled
it should look something like this, assuming of course we follow you! :-) (if
not the message about following each other won't show up):
<img src="png/mastodon-notifications.png"
alt="screenshot of Mastodon push notifications"
width=912 height=556>
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](#)
<div id="tabstops">
### Q 10.7: How do I set certain tabstops for viewing source code in vi(m)?
</div>
news.html
+2 -2
View File
@@ -747,11 +747,11 @@ as well as a critical fix for installing on BSD based systems.</p>
and compile the <a href="faq.html#mkiocccentry">mkiocccentry tool set</a>. You may also wish to install this code.
See also the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/FAQ.md">mkiocccentry FAQ</a> for more information.</p>
<h2 id="section-17">2024-12-30</h2>
<p>The IOCCC <a href="next/rules.html#rule-12---utf-8">Rule 12 - UTF-8</a> no longer discourages the
<p>The IOCCC <a href="next/rules.html#rule12-utf8">Rule 12 - UTF-8</a> no longer discourages the
use of UTF-8 in C source. Since the days of <code>-std=gnu17</code> compilers,
UTF-8 characters do not impose a compiler problem. The related guideline
states that “Rule 13 no longer discourages the use of UTF-8 +characters in C code”.</p>
<p>The IOCCC <a href="next/rules.html#rule-8---submission">Rule 8 - Submission</a> wording has been fixed. It no longer
<p>The IOCCC <a href="next/rules.html#rule8-submitting-requirements">Rule 8 - Submitting requirements</a> wording has been fixed. It no longer
states that email will be sent. Instead it talks about potential slot comment
modifications as means to tell the submitter that their submission was received.</p>
<p>All of the import IOCCC dates within the <a href="next/rules.html">IOCCC rules</a>
news.md
+2 -2
View File
@@ -406,12 +406,12 @@ See also the [mkiocccentry FAQ](https://github.com/ioccc-src/mkiocccentry/blob/m
## 2024-12-30
The IOCCC [Rule 12 - UTF-8](next/rules.html#rule-12---utf-8) no longer discourages the
The IOCCC [Rule 12 - UTF-8](next/rules.html#rule12-utf8) no longer discourages the
use of UTF-8 in C source. Since the days of `-std=gnu17` compilers,
UTF-8 characters do not impose a compiler problem. The related guideline
states that "Rule 13 no longer discourages the use of UTF-8 +characters in C code".
The IOCCC [Rule 8 - Submission](next/rules.html#rule-8---submission) wording has been fixed. It no longer
The IOCCC [Rule 8 - Submitting requirements](next/rules.html#rule8-submitting-requirements) wording has been fixed. It no longer
states that email will be sent. Instead it talks about potential slot comment
modifications as means to tell the submitter that their submission was received.
next/guidelines.html
+22 -934
View File
@@ -452,940 +452,28 @@
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
<!-- BEFORE: 1st line of markdown file: next/guidelines.md -->
<h1 id="th-international-obfuscated-c-code-contest-official-guidelines">29th International Obfuscated C Code Contest Official Guidelines</h1>
<p class="leftbar">
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 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>
<h1 id="guidelines-version">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="rules.html">IOCCC rules</a>.</p>
<div id="guideline2">
</div>
<div id="guideline-2---size">
</div>
<h1 id="guidelines-for-rule-2---size">Guidelines for <a href="rules.html#rule-2---size">Rule 2 - Size</a></h1>
<p class="leftbar">
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>
<strong>AND</strong> the <a href="rules.html#rule-2b-net-size">Rule 2b Net Size</a>.</p>
<p>To check your code against <a href="rules.html#rule-2---size">Rule 2 - Size</a>, use the <code>iocccentry(1)</code> tool.
For example:</p>
<pre><code> iocccsize prog.c</code></pre>
<p>The IOCCC size tool algorithm can be summarized as follows:</p>
<blockquote>
<p>The size tool counts most C reserved words (keyword, secondary, and selected
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>
<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.</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>.
Make sure <code>iocccsize(1)</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> 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="guideline3">
</div>
<div id="guideline-3---register">
</div>
<h1 id="guidelines-for-rule-3---register">Guidelines for <a href="rules.html#rule-3---register">Rule 3 - Register</a></h1>
<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>
<div id="guideline-7---original-work">
</div>
<h1 id="guidelines-for-rule-7---original-work">Guidelines for <a href="rules.html#rule-7---original-work">Rule 7 - Original Work</a></h1>
<p>While it is <strong>NOT</strong> required, you are allowed to use tools or services such as:</p>
<ul>
<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>The IOCCC has a rich history of remarkable winning entries created by
authors who skillfully employed various techniques to develop their code.
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>In short: You created it, you own it, its an original work, or you have explicit permission to the work.</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>
<div id="guideline11">
</div>
<div id="guideline-11---abuse">
</div>
<h1 id="guidelines-for-rule-11---abuse">Guidelines for <a href="rules.html#rule-11---abuse">Rule 11 - Abuse</a></h1>
<p>We do realize that there are holes in the <a href="rules.html">IOCCC rules</a>, and invite
submitters to attempt to apply creative rule interpretation. A rule abuse though, even
if not rewarded, may result in a subsequent rule change for future contests.</p>
<p>We sometimes 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 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 submitted.</p>
<p>Legal abuse of the <a href="rules.html">IOCCC rules</a> is <strong>NOT</strong> an invitation to violate the
<a href="rules.html">IOCCC rules</a> (especailly <a href="./rules.html#rule-17---packaging">Rule 17 - Packaging</a> ). A submission that violates the <a href="rules.html">rules</a> in the
opinion of the <a href="../judges.html">IOCCC judges</a>, <strong>WILL</strong> be
disqualified. <strong><em>RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!</em></strong> If you
have a submission that might otherwise be interesting, you might want to
submit two versions; one that does not abuse the <a href="rules.html">IOCCC rules</a> and one that
does.</p>
<p>If you intend to abuse the <a href="rules.html">IOCCC rules</a>,
indicate so in your <code>remarks.md</code> file. You <strong>MUST</strong> try to justify, plead, beg,
why you consider your rule abuse to be allowed under the
<a href="rules.html">IOCCC rules</a>. Humor or creativity help plead a case.
As there is no guarantee that you will succeed, you might consider
submitting an alternate version that conforms to the
<a href="rules.html">IOCCC rules</a>.</p>
<p>If you do bypass the <code>mkiocccentry(1)</code> warnings about
<a href="rules.html#rule-2a-gross-size">Rule 2a Gross Size</a>
or about
<a href="rules.html#rule-2b-net-size">Rule 2b Net Size</a>
or any other
rule and submit a submission anyway, you <strong>MUST</strong> try to justify why the IOCCC
<a href="../judges.html">IOCCC judges</a> should not reject your submission due to a rule
violation, and you would be wise to do this towards the top of your <code>remarks.md</code>
file.</p>
<p>We are often asked why the contest <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC
guidelines</a> seem strange or contain mistakes, flaws, or
grammatical errors. One reason is that we sometimes make genuine mistakes, but
in many cases such problems, flaws or areas of confusion are deliberate.</p>
<p>Changes to <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</a> in
response to rule abuses, are done in a minimal fashion. Often we will
deliberately leave behind holes (or introduce new ones) so that future rule
abuse can continue. A clever author should be able to read them and “drive a
truck through the holes” in the <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC
guidelines</a>.</p>
<p>At the risk of stating the obvious, this contest is a parody of the software
development process. The <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</a>
are only part of the overall contest. Even so, one might think the
contest <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</a> process as a parody
of the sometimes tragic mismatch between what a customer (or marketing) wants
and what engineering delivers. Real programmers must face obfuscated and
sometimes conflicting, balloning specifications, and requirements from marketing, sales,
product management and even from customers themselves on an all too regular basis.
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="guideline15">
</div>
<div id="guideline-15---building">
</div>
<h1 id="guidelines-for-rule-15---building">Guidelines for <a href="rules.html#rule-15---building">Rule 15 - Building</a></h1>
<p>You may use <code>git,</code> 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>GNU 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="guideline17">
</div>
<div id="guideline-17---packaging">
</div>
<h1 id="guidelines-for-rule-17---packaging">Guidelines for <a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a></h1>
<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">
These 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>) do <em>not</em> 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="mkiocccentry">
</div>
<div id="mkiocccentry_toolkit">
</div>
<h1 id="guidelines-for-the-mkiocccentry-toolkit">Guidelines for the mkiocccentry toolkit</h1>
<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>! So you <strong>REALLY SHOULD</strong> use the 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>iocccsize(1)</li>
<li>txzchk(1)</li>
<li>fnamchk(1)</li>
<li>chksubmit(1)</li>
<li>chkentry(1)</li>
</ul>
<p>Do <strong>NOT</strong> use <code>txzchk(1)</code> or <code>fnamchk(1)</code> command line options that are labeled
“<strong>for TESTING purposes</strong>” in their respective man pages.</p>
<p>Similarly do <strong>NOT</strong> use <code>chkentry(1)</code> command line options marked “<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,
so later enter <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.
While <code>mkiocccentry -Y -i answers ..</code> will force yes answers, use 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 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> as noted else where.</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 generated</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 or directory that begins with a period (<code>.</code>).</p>
<p>The <code>mkiocccentry(1)</code> tool will ignore 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>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>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">
</div>
<h1 id="general-overall-guidelines">General Overall Guidelines</h1>
<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>
<div id="dislikes">
</div>
<h1 id="our-likes-and-dislikes">OUR LIKES AND DISLIKES:</h1>
<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>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 both BSD
and 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="fun">
</div>
<h1 id="fundamental-guidelines">Fun😄damental Guidelines</h1>
<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>
<div id="information">
</div>
<h1 id="for-more-information">FOR MORE INFORMATION:</h1>
<p>For questions or comments about the contest, see <a href="../contact.html">Contacting the IOCCC</a>.</p>
<p><strong>Be SURE</strong> to review the <a href="index.html">IOCCC Rules and Guidelines</a> as they
may (and <strong>often do</strong>) change from year to year.</p>
<p><strong>PLEASE</strong> be sure you have the current <a href="rules.html">IOCCC rules</a> and
<a href="guidelines.html">IOCCC guidelines</a> prior to submitting to the contest.</p>
<p>See the <a href="../news.html">Official IOCCC website news</a> for additional information.</p>
<p>For the updates and breaking IOCCC news, you are encouraged to follow
the <a href="https://fosstodon.org/@ioccc">IOCCC on Mastodon</a>. See our
FAQ on “<a href="../faq.html#try_mastodon">Mastodon</a>”
for more information. Please do note that unless
you are mentioned by us you will <strong>NOT</strong> get a notification from the app <em>so you
should refresh the page <strong>even if you do follow us</strong></em>.</p>
<p>Check out the <a href="https://www.ioccc.org/index.html">Official IOCCC winner website</a> in general.</p>
<p>Consider joining the IOCCC discord community via this link:
<a href="https://discord.gg/Wa42Qujwnw">https://discord.gg/Wa42Qujwnw</a></p>
<p>See the
FAQs on “<a href="../faq.html#mkiocccentry">obtaining, compiling, installing and using the 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> for the IOCCC.</p>
<hr style="width:10%;text-align:left;margin-left:0">
<p>Jump to: <a href="#">top</a>
<!-- AFTER: last line of markdown file: next/guidelines.md --></p>
<!-- START: this line starts content from: inc/guidelines.closed.hdr -->
<h1 id="the-ioccc-is-closed">The IOCCC is closed</h1>
<p>The IOCCC is <strong>NOT</strong> accepting new submissions at this time. See the
<a href="../years.html">IOCCC winning entries page</a> for the entries that have won the
IOCCC in the past.</p>
<p>These guidelines are a <strong>TENTATIVE proposal</strong> for the next IOCCC
and are <strong>likely be to be updated</strong> before the next IOCCC.</p>
<p>See our
FAQ on “<a href="../faq.html#feedback">rules, guidelines, tools feedback</a>”
as well as our
FAQ on “<a href="../faq.html#question">about asking questions</a>”
about these guidelines. You might also find the FAQ in general useful, especially the
FAQ on “<a href="../quick-start.html#enter">how to enter the IOCCC</a>”.</p>
<p>Watch both <a href="../status.html">the IOCCC status page</a> and the
<a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> mastodon feed</a> for information about
future IOCCC openings.</p>
<p><strong>HINT to mastodon users</strong>: You may wish to refresh the <a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span>
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 -->
<!-- AFTER: last line of markdown file: next/guidelines.md -->
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
<!-- START: this line starts content from: inc/after-content.default.html -->
next/guidelines.md
+21 -1207
View File
File diff suppressed because it is too large. Load diff
next/rules.html
+214 -141
View File
@@ -474,60 +474,80 @@ app from time to time to view IOCCC mastodon updates.</p>
<!-- END: the next line ends content from: inc/rules.closed.hdr -->
<!-- This is the last line modified by the tool: bin/gen-status.sh -->
<h1 id="th-international-obfuscated-c-code-contest-official-rules">29th International Obfuscated C Code Contest Official Rules</h1>
<p>Copyright © 2025 Leonid A. Broukhis and Landon Curt Noll.</p>
<p>Copyright (c) 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 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.08 2025-11-28</strong>.</p>
<p>Be sure to read the <a href="guidelines.html">IOCCC guidelines</a>.</p>
<p>These IOCCC Rules are version <strong>29.09 2025-11-29</strong>.</p>
<p>Reminder: 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 <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>,
<p>This IOCCC runs from <code>2025-12-03 20:25:12.045045 UTC</code> to <code>2026-03-13 17:19:23.293137 UTC</code>.</p>
<p>This contest will enter the <strong>pending state</strong> on <code>2025-12-03 20:25:12.045045 UTC</code>,
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>,
<p>This contest will enter the <strong>open state</strong> on <code>2025-12-15 18:21:24.273033 UTC</code>,
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>,
<p>This contest will enter the <strong>judging state</strong> on <code>2026-03-13 17:19:23.293137 UTC</code>,
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>
<p>See the <a href="../status.html">current status of the IOCCC</a>.</p>
<div id="rule1">
<h2 id="rule-1---program">Rule 1 - Program</h2>
<h2 id="rule-1---c-program">Rule 1 - C program</h2>
</div>
<p>Your submission <strong>MUST</strong> be a C program.</p>
<p>Your submission <strong>MUST</strong> be a C program that does NOT <code>#include</code> data files.</p>
<div id="rule2">
<h2 id="rule-2---size">Rule 2 - Size</h2>
<div id="rule2-size-restrictions">
<div id="rule2-size">
<div id="rule-2---size">
<h2 id="rule-2---size-restrictions">Rule 2 - Size restrictions</h2>
</div>
</div>
</div>
</div>
<p><code>Rule 2</code> requires that your submission satisfy <strong>BOTH</strong>
<a href="rules.html#rule-2a-gross-size">Rule 2a Gross Size</a>
<a href="rules.html#rule2a">Rule 2a (Gross Size)</a>
and
<a href="rules.html#rule-2b-net-size">Rule 2b Next Size</a>.
<a href="rules.html#rule2b">Rule 2b (Net 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>
<pre><code> iocccsize prog.c</code></pre>
<p>See the <a href="guidelines.html#guideline-2---size">Guidelines for Rule 2 - Size restrictions</a>.</p>
<div id="rule2a">
<div id="rule2a-gross-size">
<div id="rule-2a-gross-size">
<h3 id="rule-2a---gross-size">Rule 2a - Gross Size</h3>
</div>
</div>
</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><strong>NOTE</strong>: by default <code>iocccsize</code> will only report the rule 2b size, unless the
code surpasses the limit.</p>
<p>See <a href="../quick-start.html#enter">Entering the IOCCC: the bare minimum you need to know</a>.</p>
<div id="rule2b">
<div id="rule2b-net-size">
<div id="rule-2b-net-size">
<h3 id="rule-2b---net-size">Rule 2b - Net Size</h3>
</div>
</div>
</div>
<p>When the filename of your program source (i.e., <code>prog.c</code>) is given as a
command line argument to the latest version of the official IOCCC size
tool (hereby referred to as <code>iocccsize(1)</code>), the value printed <strong>MUST
NOT</strong> exceed <strong>2503</strong>.</p>
<p><strong>NOTE</strong>: <code>iocccsize</code> does <strong>NOT</strong> calculate the filename length. See <a href="#rule17-mkiocccentry">Rule 17 -
Use mkiocccentry</a>.</p>
<div id="rule3">
<h2 id="rule-3---register">Rule 3 - Register</h2>
<div id="rule3-register">
<h2 id="rule-3---register-for-the-ioccc">Rule 3 - Register for the IOCCC</h2>
</div>
</div>
<p>You <strong>MUST</strong> register, using a valid email address, in order to submit
entries to the IOCCC. You may register while the contest is <strong>pending</strong> or <strong>open</strong>.</p>
to the IOCCC. You may register while the contest is <strong>pending</strong> or <strong>open</strong>.</p>
<p>A few days after registering, you’ll receive your UUID username and
temporary password, which you <strong>MUST</strong> change within 14 days. If you
fail to change it in a timely manner, you’ll need to
@@ -538,38 +558,53 @@ register and submit your entries; <strong>DO NOT WAIT UNTIL THE FINAL DAYS</stro
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>
<p>See <a href="rules.html#rule8">Rule 8 - Submitting requirements</a>.</p>
<p>See <a href="guidelines.html#guideline-3---register">Guidelines for Rule 3 - Register for the IOCCC</a>.</p>
<div id="rule4">
<h2 id="rule-4---files">Rule 4 - Files</h2>
<div id="rule4-required-files">
<h2 id="rule-4---required-files">Rule 4 - Required files</h2>
</div>
<p>The submission <strong>MUST</strong> include at least these files: <code>Makefile</code>, <code>prog.c</code>,
<code>remarks.md</code>,<code>.info.json</code>, and <code>.auth.json</code>.</p>
<p>At a minimum the following requirements apply. Additional requirements
</div>
<p>Your submission <strong>MUST</strong> include at least these files: <code>Makefile</code>, <code>prog.c</code>,
<code>remarks.md</code>,<code>.info.json</code>, and <code>.auth.json</code>, the latter two of which are
generated by <code>mkiocccentry(1)</code>. See <a href="#rule17-mkiocccentry">Rule 17 -
Use mkiocccentry</a>.</p>
<p>At a <strong>minimum</strong> the following requirements apply. Additional requirements
may be imposed by <code>mkiocccentry(1)</code> updates that have yet to be listed
here:</p>
below.</p>
<p><strong>NOTE</strong>: <code>mkiocccentry(1)</code> will reject any directory which has prohibited
files.</p>
<p><strong>NOTE</strong>: by ‘top directory’ we mean the directory with <code>prog.c</code>, <code>Makefile</code>,
<code>remarks.md</code> and the <code>mkiocccentry(1)</code> generated files <code>.auth.json</code> and
<code>.info.json</code> and <strong>NOT</strong> the <code>topdir</code> arg to <code>mkiocccentry(1)</code>.</p>
<ul>
<li><p><code>.info.json</code>, and <code>.auth.json</code> <strong>MUST</strong> be generated by <code>mkiocccenty(1)</code>
when packing a submission, and <strong>MUST</strong> pass the <code>chksubmit(1)</code> tests.</p></li>
<li><p><code>.info.json</code> and <code>.auth.json</code> <strong>MUST</strong> be generated by <code>mkiocccenty(1)</code>
when packing a submission. When <code>chksubmit(1)</code> is run on the submission
directory <strong>ALL</strong> tests must pass and if there is <strong>ANY</strong> problem with these
JSON files or if either is missing it will fail. See <a href="#rule17-mkiocccentry">Rule 17 - use
mkiocccentry</a>.</p></li>
<li><p>The <code>Makefile</code>, <code>remarks.md</code>,<code>.info.json</code>, and <code>.auth.json</code> <strong>MUST</strong>
have a file size <strong>greater than 0</strong>.</p></li>
have a file size <strong>greater than 0</strong> and <strong>MUST</strong> have content. Note that
<code>mkiocccentry(1)</code> will check for file <strong>size</strong> but will <strong>NOT</strong> check for
content.</p></li>
<li><p>Your submitted source code <strong>MUST</strong> be called <code>prog.c</code>. When the <code>Makefile</code>
compiles your code, the executable (if applicable) <strong>MUST</strong> be called <code>prog</code>.
The <code>Makefile</code> may compile your source code into other filenames as well.</p></li>
The <code>Makefile</code> may compile your source code into other filenames as well, if you
want.</p></li>
<li><p>As <code>prog</code>, <code>prog.alt</code>, <code>prog.alt.o</code>, <code>prog.o</code> may be created by your
<code>Makefile</code>, your submission <strong>MUST NOT</strong> include those files in
your top directory, as original content.</p></li>
<code>Makefile</code>, your submission <strong>MUST NOT</strong> include those files in your <strong>top</strong>
directory.</p></li>
<li><p>Your submission may <strong>NOT</strong> have any file that starts with <code>COPYING</code>,
<code>COPYRIGHT</code>, or <code>LICENSE</code> as those files are reserved by IOCCC.</p></li>
<li><p>Your submission may <strong>NOT</strong> have in the top directory, <code>prog.orig.c</code>,
<code>README.md</code>, nor <code>index.html</code> as those files reserved by IOCCC.</p></li>
<li><p>Your submission may <strong>NOT</strong> have in the top directory, any file
<li><p>Your submission may <strong>NOT</strong> have in the <strong>top</strong> directory: <code>prog.orig.c</code>,
<code>README.md</code> or <code>index.html</code> as those files are reserved by the IOCCC.</p></li>
<li><p>Your submission may <strong>NOT</strong> have in the <strong>top</strong> directory any file
that matches a file glob pattern form <code>[0-9][0-9][0-9][0-9]_*.tar.bz2</code>
as those files are reserved by IOCCC.</p></li>
<li><p>Your submission may <strong>ONLY</strong> contain files and directories. Other file
types such as symlinks, sockets, etc are <strong>NOT</strong> allowed.</p></li>
<li><p>All directories <strong>MUST</strong> have a file mode of <strong>0755</strong>. All files
<strong>MUST</strong> have the file mode of <strong>0444</strong>, except for files that
types such as symlinks, sockets etc. are <strong>NOT</strong> allowed.</p></li>
<li><p><strong>All</strong> directories <strong>MUST</strong> have permission mode of <strong>0755</strong>. All files
<strong>MUST</strong> have the file mode of <strong>0444</strong>, EXCEPT for files that
end in <code>.sh</code> which must have a mode of <strong>0555</strong>.</p></li>
<li><p>All files that end in <code>.md</code> <strong>MUST</strong> be in markdown format.
We recommend that markdown files observe our
@@ -582,29 +617,35 @@ a case insensitive filesystem.</p></li>
</ul>
<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>
<p>See <a href="rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.</p>
<p>See the
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 the <a href="guidelines.html#mkiocccentry_toolkit">Guidelines on the mkiocccentry toolkit</a>.</p>
<p>See the
FAQ on “<a href="../faq.html#makefile_details">What are the detailed recommendations for a submission Makefile?</a>”.</p>
<div id="rule5">
<h2 id="rule-5---integrity">Rule 5 - Integrity</h2>
<div id="rule5-modifying-files">
<h2 id="rule-5---do-not-modify-submitted-files-or-filenames-or-parent-directories">Rule 5 - Do NOT modify submitted files or filenames or parent directories</h2>
</div>
<p>Your submission <strong>MUST NOT</strong> modify the filenames or content of any of
your original submission, such as <code>prog.c</code>, <code>Makefile</code>, or any supplied
data files. To modify files, your program can make a copy or you can
use the <code>Makefile</code> to setup working copies. Any working copies <strong>MUST</strong> be
cleaned up by the <code>Makefile</code> <code>clobber</code> target, so as to restore the
directory to its original state.</p>
</div>
<p>Your submission <strong>MUST NOT</strong> modify the filenames or content of any of your
original submission, such as <code>prog.c</code>, <code>Makefile</code>, or <strong>ANY</strong> other supplied
files. To modify files, your program can make a copy or you can use the
<code>Makefile</code> to setup working copies. Any working copies <strong>MUST</strong> be cleaned up
by the <code>Makefile</code> <code>clobber</code> target, so as to restore the directory to its
original state.</p>
<p>Your submission <strong>MUST NOT</strong> create or modify directories and files
ABOVE the current directory with the exception of the <code>/tmp</code> and the
<code>/var/tmp</code> directories as long as the directory name or filename does
<strong>NOT</strong> start with “.” (dot).</p>
<p>The <code>Makefile</code> <code>clobber</code> target <strong>MUST</strong> be restore your submission into
ABOVE the current directory (with the exception of the <code>/tmp</code> and the <code>/var/tmp</code>
directories and as long as the directory name or filename does <strong>NOT</strong> start
with a <code>.</code> (dot)).</p>
<p>The <code>Makefile</code> <code>clobber</code> target <strong>MUST</strong> restore your submission to its
original form, including the removal of any created files and directories.</p>
<p>Your code should be able to run under a
<a href="https://pubs.opengroup.org/onlinepubs/9799919799/">SUS environment</a>.</p>
<div id="rule6">
<h2 id="rule-6---free">Rule 6 - Free</h2>
<div id="rule6-free-rule">
<h2 id="rule-6---free-rule">Rule 6 - Free Rule</h2>
</div>
</div>
<p>I am <strong>NOT</strong> a Rule, I am a <code>free(void *human);</code> ‼️</p>
<pre><code> while (!(ioccc(rule(you(are(number(6)))))) {
@@ -612,84 +653,103 @@ original form, including the removal of any created files and directories.</p>
}</code></pre>
<p>See <a href="rules.html#rule-19---prime">Rule 19 - Prime</a>.</p>
<div id="rule7">
<div id="rule7-original-work">
<h2 id="rule-7---original-work">Rule 7 - Original Work</h2>
</div>
<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>
</div>
<p>You, the author(s), <strong>MUST</strong> own the contents of your submission, <strong>OR</strong>, IF you
do <strong>NOT</strong> own the work, then you <strong>MUST</strong> have permission from the original
owner(s) to its use. If you submit <strong>ANY</strong> 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>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="rules.html#rule16-anonymous-judging">Rule 16 - Anonymous Judging</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 id="rule8-submitting-requirements">
<h2 id="rule-8---submitting-requirements">Rule 8 - Submitting requirements</h2>
</div>
<p>The Submit Server will only accept submissions from those who have
registered and only while the contest is open.</p>
<p>The Submit Server places a total submission size limit of <strong>3999971</strong> bytes.</p>
</div>
<p>The submit server will accept submissions <strong>ONLY</strong> from those who have
registered and <strong>ONLY</strong> while the contest is open.</p>
<p>The submit server places a total size limit of <strong>3999971</strong> bytes <strong>PER</strong>
submission.</p>
<p>Each account has ten (<strong>10.000</strong>) submission slots (<strong>0..9)</strong>. Each submission
slot should be annotated by the server as to whether its was received,
processed, malformed, etc. Please take note of any errors, rectify,
and resubmit. In order to avoid potential packaging errors, it is <strong>highly
recommended</strong> to use <code>mkiocccentry(1)</code>.</p>
recommended</strong> to use <code>mkiocccentry(1)</code>, <strong>AND</strong> to check from time to time the
status on the submit server, to see if any tests run by the server failed to
validate your submission.</p>
<p>Do <strong>NOT</strong> register more than one account!</p>
<p>See
<a href="rules.html#rule-3---register">Rule 3 - Register</a>,
<a href="rules.html#rule-15---building">Rule 15 - Building</a>,
<a href="rules.html#rule3-register">Rule 3 - Registering for the IOCCC</a>,
<a href="rules.html#rule15-gnu-makefile">Rule 15 - GNU Makefile</a>,
and
<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p>
<a href="rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.</p>
<div id="rule9">
<h2 id="rule-9---no-hands">Rule 9 - No hands</h2>
<h2 id="rule-9---no-interactive-compiling-allowed">Rule 9 - No interactive compiling allowed</h2>
</div>
<p>Entries requiring human interaction to be initially compiled are <strong>NOT</strong>
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>
build process using <code>bash</code>, <code>gmake</code>, <code>gcc</code> and/or <code>clang</code> and other commonly
available tools under an <a href="https://pubs.opengroup.org/onlinepubs/9799919799/">SUS
environment</a>.</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>
<p><strong>NOTE</strong>: it is better to use the <code>${MAKE}</code> variable as then one may override
the make command.</p>
<p><strong>NOTE</strong>: it is better and more portable to <strong>NOT</strong> modify the <code>${CC}</code> variable
in the Makefile.</p>
<p>See <a href="rules.html#rule15-gnu-makefile">Rule 15 - GNU Makefile</a>.</p>
<div id="rule10">
<h2 id="rule-10---privileges">Rule 10 - Privileges</h2>
<h2 id="rule-10---program-file-permissions">Rule 10 - Program file permissions</h2>
</div>
<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>
document this fact and explain why it is needed in your submission’s
<code>remarks.md</code> file.</p>
<code>remarks.md</code> file, preferably close to the top.</p>
<p>Furthermore, if you need a supplementary program that you include to
have these permissions, you will also have to explain this, because these
have these permissions, you will also have to explain this as well, because these
bits are <strong>NOT</strong> allowed in submissions and those bits will <strong>NOT</strong> be copied by
<code>mkiocccentry(1)</code>.</p>
<p>See <a href="rules.html#rule-4---files">Rule 4 - Files</a>,
<p>See <a href="rules.html#rule4-required-files">Rule 4 - Required files</a>,
and
<a href="rules.html#rule-5---integrity">Rule 5 - Integrity</a>.</p>
<a href="rules.html#rule5-modifying-files">Rule 5 - Do NOT modify files</a>.</p>
<div id="rule11">
<h2 id="rule-11---abuse">Rule 11 - Abuse</h2>
<div id="rule11-legal-rule-abuse">
<h2 id="rule-11---legal-rule-abuse">Rule 11 - Legal rule abuse</h2>
</div>
<p>Legal abuse of the rules is somewhat encouraged, but comes with risks.
A submission that, in the opinion of the Judges, violates the rules <strong>WILL
</div>
<p>Legal abuse of the rules is <strong>somewhat</strong> encouraged, but comes with risks.
A submission that, in the opinion of the Judges, <strong>violates</strong> the rules <strong>WILL
BE DISQUALIFIED</strong>. Submissions that plan to abuse the rules <strong>MUST</strong> justify
why their rule abuse is legal (or interesting) in the <code>remarks.md</code> file.</p>
<p>Submission packaging abuse will <strong>NOT</strong> be tolerated and for this reason
its recommended to use <code>mkiocccentry(1)</code>. During development you can
check your <code>prog.c</code> size limits using <code>iocccsize(1)</code>, e.g., <code>iocccsize -v1 prog.c</code>.
Overriding problems detected by any of the IOCCC tools
<p>Submission packaging abuse will <strong>NOT</strong> be tolerated and for this reason,
amongst many others, it is recommended that you use <code>mkiocccentry(1)</code>. During
development you can check your <code>prog.c</code> size limits using <code>iocccsize(1)</code>, e.g.,
<code>iocccsize -v1 prog.c</code>. Overriding problems detected by any of the IOCCC tools
risks that the submission will be rejected.</p>
<p>If you do submit a rule abusing or violating submission, then consider
also submitting an alternate version in a different submission server
slot that does <strong>NOT</strong> violate the rules in case your rule abuse excuse
is rejected.</p>
<p><strong>IMPORTANT</strong>: If you do submit such an alternate non-rule abusing
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>
version, <strong>PLEASE</strong> 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 - Legal rule
abuse</a>.</p>
<div id="rule12">
<div id="rule12-utf8">
<h2 id="rule-12---utf-8">Rule 12 - UTF-8</h2>
</div>
<p>Use of UTF-8 is supported by <code>C89</code> standard and its updates and so too by the IOCCC.</p>
</div>
<p>Use of UTF-8 is supported by <code>C89</code> standard and its updates and so too by the
IOCCC.</p>
<div id="rule13">
<h2 id="rule-13---newlines">Rule 13 - Newlines</h2>
<h2 id="rule-13---no-carriage-returns-in-prog.c">Rule 13 - No carriage returns in prog.c</h2>
</div>
<p>Any C source that fails to compile because lines contain carriage-returns
(CTRL+M, <code>\r</code>) in particular as part of DOS/Windows style newlines might
@@ -697,34 +757,36 @@ be rejected. Please do <strong>NOT</strong> put trailing CTRL+M in <code>prog.c<
or <code>remarks.md</code> files, but instead end lines with Unix newline (line-feed,
CTRL+J, <code>\n</code>).</p>
<p>You are permitted, in order to try and squeeze your <code>prog.c</code> under a
<a href="rules.html#rule-2a-gross-size">Rule 2a Gross Size</a> and/or
<a href="rules.html#rule-2b-net-size">Rule 2b Next Size</a>
<a href="rules.html#rule2a-gross-size">Rule 2a Gross Size</a> and/or
<a href="rules.html#rule2b-net-size">Rule 2b Net Size</a>
limits, to <strong>NOT</strong> end source with a newline. If you
need to do this, please document that in your <code>remarks.md</code> file and if
your compiler complains about this, document this too and update your
<code>Makefile</code> to account for this.</p>
<div id="rule14">
<h2 id="rule-14---resubmit">Rule 14 - Resubmit</h2>
<h2 id="rule-14---resubmitting-lost-submissions">Rule 14 - Resubmitting lost submissions</h2>
</div>
<p>Submissions that are substantially similar to previous winning IOCCC
entries are discouraged.</p>
<p>You are allowed to resubmit to a later contest, a submission that didn’t
win the IOCCC. If you do so, then you would be well advised to try and
enhance and improve your submission. If you do resubmit something that
didn’t previously win, then you are encouraged to mention this in your
<code>remarks.md</code> file as this sometimes helps.</p>
<p>You are allowed to resubmit to a later contest, a submission that didn’t win the
IOCCC. If you do so, then you would be <strong>WELL ADVISED</strong> to try and enhance and
improve your submission. If you do resubmit something that didn’t previously
win, then you are encouraged to mention this in your <code>remarks.md</code> file as this
<strong>sometimes</strong> helps.</p>
<div id="rule15">
<h2 id="rule-15---building">Rule 15 - Building</h2>
<div id="rule15-gnu-makefile">
<h2 id="rule-15---gnu-makefile">Rule 15 - GNU Makefile</h2>
</div>
<p>The <code>Makefile</code> <strong>MUST</strong> adhere to GNU Makefile syntax. Its recommended
that you copy and rename the <code>Makefile.example</code> as a template. The primary
target of the <code>Makefile</code> <strong>MUST</strong> be <code>prog</code> and the source file is <code>prog.c</code>.
The C compiler and preprocessor <strong>MUST</strong> be invoked using <code>${CC}</code> and <code>${CPP}</code>
macros respectively.</p>
<p>The <code>clobber</code> target should clean and restore the submission directory
tree to its original state, such as removing temporary files or any
modified data files. Don’t assume that <code>git</code> tool chain is installed,
i.e., do <strong>NOT</strong> expect <code>git clean -f</code> to work.</p>
</div>
<p>The <code>Makefile</code> <strong>MUST</strong> adhere to GNU Makefile syntax. It’s highly recommended
that you copy the <a href="Makefile.example">Makefile.example</a> as a template, renaming
it to <code>Makefile</code>. The primary target of the <code>Makefile</code> <strong>MUST</strong> be <code>prog</code> and
the source file is <code>prog.c</code>. The C compiler and preprocessor <strong>MUST</strong> be
invoked using <code>${CC}</code> and <code>${CPP}</code> macros respectively.</p>
<p>The <code>clobber</code> target <strong>MUST</strong> clean and restore the submission directory tree to
its original state, such as removing temporary files or any modified data files.
Don’t assume that <code>git</code> tool chain is installed, i.e. do <strong>NOT</strong> expect <code>git clean -f</code> to work. To be clear: do <strong>NOT</strong> use <code>git</code> to clean out files as this
can cause problems in the winner repo!</p>
<p>The <code>Makefile</code> <strong>MUST</strong> use a syntax that is compatible with
<code>bash(1)</code> and GNU <code>make(1)</code>. You are encouraged to use <code>SHELL= bash</code> in your <code>Makefile</code>; please add a space between the <code>=</code> and
the value such as:</p>
@@ -734,25 +796,33 @@ Specification</a>
environments and systems are available in the search
<code>$PATH</code>. Avoid command options that aren’t part of
<a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">SUS</a>, such as
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>
GNU long name options (such as <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#rule4-required-files">Rule 4 - Required 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 - GNU Makefile</a>.</p>
<div id="rule16">
<h2 id="rule-16---anonymous">Rule 16 - Anonymous</h2>
<div id="rule16-anonymous-judging">
<h2 id="rule-16---anonymous-judging">Rule 16 - Anonymous judging</h2>
</div>
</div>
<p>Your source code, data files, remarks, and program output <strong>MUST NOT</strong>
identify the author(s) of your code (unless you are <strong>Peter Honeyman</strong>
or pretending to be <strong>Peter Honeyman</strong>). In order to be impartial the
<a href="https://www.ioccc.org/judges.html">Judges</a> do <strong>NOT</strong> know who is submitting
entries to the IOCCC until final selection is made. Even if you are
a past winner, you <strong>MUST NOT</strong> reveal your identity deliberately or by
accident anywhere in your submission. <strong><em>Failure to comply may result
in the submission being disqualified.</em></strong></p>
programs to the IOCCC until final selection is made, and <strong>only</strong> submissions
that won.</p>
<p>Even if you are a past winner, you <strong>MUST NOT</strong> reveal your identity
deliberately or by accident anywhere in your submission. <strong><em>Failure to comply
may result in the submission being disqualified</em></strong>.</p>
<div id="rule17">
<h2 id="rule-17---packaging">Rule 17 - Packaging</h2>
<div id="rule17-mkiocccentry">
<h2 id="rule-17---use-mkiocccentry">Rule 17 - Use <code>mkiocccentry</code></h2>
</div>
</div>
<p>TL;DR: use <code>mkiocccentry(1)</code> to package your submission.</p>
<p>The files, directories, and paths <strong>MUST</strong> conform to the limits imposed by
<code>mkiocccentry(1)</code>, including but <strong>NOT</strong> limited, to their names, count, path
length, directory tree depth, and permissions.</p>
@@ -763,33 +833,36 @@ directory depths of <strong>4</strong>. The maximum number of files, excluding
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 (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 tarball <strong>MUST</strong> be a <strong>v7 format</strong> tarball, and any supplementary tarballs
you provide <strong>MUST</strong> also be <strong>v7 format</strong>.</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 submission <strong>MUST</strong> pass all <code>txzchk(1)</code> checks, and the tarball filename
<strong>MUST</strong> pass all <code>fnamchk(1)</code> checks as well.</p>
<p>You may <strong>NOT</strong> submit a tarball created by the <code>-d</code>, <code>-e</code> <strong>OR</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>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>
minimum required 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
are labelled as “<strong>for TESTING purposes</strong>”, <strong>OR</strong> labelled 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>”, again notwithstanding the options
for testing and the IOCCC judges.</p>
<p>The <code>prog.c</code> file <strong>MUST</strong> pass the <a href="rules.html#rule2-size">Rule 2 - Size</a>
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>Any submission that fails to pass the checks performed by the minimum required
version of the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
<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>
<p>See <a href="rules.html#rule4-required-files">Rule 4 - Required files</a>.</p>
<p>See the
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 the <a href="guidelines.html#guideline-17---packaging">Guidelines for Rule 17 - Use mkiocccentry</a>.</p>
<div id="rule18">
<h2 id="rule-18---license">Rule 18 - License</h2>
<h2 id="rule-18---submission-license">Rule 18 - Submission license</h2>
</div>
<p>The entirety of your submission <strong>MUST</strong> be submitted under the following license:</p>
<p><a href="https://creativecommons.org/licenses/by-sa/4.0/">CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International</a></p>
@@ -800,14 +873,14 @@ size checks performed by <code>iocccsize(1)</code>.</p>
<p>This 19th rule, while prime, is reserved for future abuse 😁.
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>
<p>See <a href="rules.html#rule6-free-rule">Rule 6 - Free Rule</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>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>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
next/rules.md
+238 -150
View File
@@ -29,7 +29,7 @@ app from time to time to view IOCCC mastodon updates.
# 29th International Obfuscated C Code Contest Official Rules
Copyright © 2025 Leonid A. Broukhis and Landon Curt Noll.
Copyright (c) 2025 Leonid A. Broukhis and Landon Curt Noll.
All Rights Reserved. Permission for personal, education or non-profit use is
granted provided this copyright and notice are included in its entirety
@@ -39,24 +39,25 @@ writing by [contacting the judges](../contact.html).
## Rules Version
These IOCCC Rules are version **29.08 2025-11-28**.
These IOCCC Rules are version **29.09 2025-11-29**.
Be sure to read the [IOCCC guidelines](guidelines.html).
Reminder: be SURE to read the [IOCCC guidelines](guidelines.html).
<div id="rule0">
## Rule 0 - Dates
</div>
This IOCCC runs from **2025-12-03 20:25:12.045045 UTC** to **2026-03-13 17:19:23.293137 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 **pending state** on **2025-12-03 20:25:12.045045 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 **open state** on **2025-12-15 18:21:24.273033 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).
This contest will enter the **judging state** on **2026-03-13 17:19:23.293137 UTC**,
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.
Until the contest enters the **open** state, any or all
@@ -64,57 +65,81 @@ 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).
See the [current status of the IOCCC](../status.html).
<div id="rule1">
## Rule 1 - Program
## Rule 1 - C program
</div>
Your submission **MUST** be a C program.
Your submission **MUST** be a C program that does NOT `#include` data files.
<div id="rule2">
## Rule 2 - Size
<div id="rule2-size-restrictions">
<div id="rule2-size">
<div id="rule-2---size">
## Rule 2 - Size restrictions
</div>
</div>
</div>
</div>
`Rule 2` requires that your submission satisfy **BOTH**
[Rule 2a Gross Size](rules.html#rule-2a-gross-size)
[Rule 2a &lpar;Gross Size&rpar;](rules.html#rule2a)
and
[Rule 2b Next Size](rules.html#rule-2b-net-size).
[Rule 2b &lpar;Net Size&rpar;](rules.html#rule2b).
During development this can be checked using `iocccsize(1)`:
``` <!---sh-->
iocccsize prog.c
```
See [Guidelines for Rule 2 - Size](guidelines.html#guideline-2---size).
See the [Guidelines for Rule 2 - Size restrictions](guidelines.html#guideline-2---size).
<div id="rule2a">
<div id="rule2a-gross-size">
<div id="rule-2a-gross-size">
### Rule 2a - Gross Size
</div>
</div>
</div>
The overall maximum size of your `prog.c` program source **MUST NOT**
exceed **4993** bytes.
**NOTE**: by default `iocccsize` will only report the rule 2b size, unless the
code surpasses the limit.
See [Entering the IOCCC: the bare minimum you need to know](../quick-start.html#enter).
<div id="rule2b">
<div id="rule2b-net-size">
<div id="rule-2b-net-size">
### Rule 2b - Net Size
</div>
</div>
</div>
When the filename of your program source (i.e., `prog.c`) is given as a
command line argument to the latest version of the official IOCCC size
tool (hereby referred to as `iocccsize(1)`), the value printed **MUST
NOT** exceed **2503**.
**NOTE**: `iocccsize` does **NOT** calculate the filename length. See [Rule 17 -
Use mkiocccentry](#rule17-mkiocccentry).
<div id="rule3">
## Rule 3 - Register
<div id="rule3-register">
## Rule 3 - Register for the IOCCC
</div>
</div>
You **MUST** register, using a valid email address, in order to submit
entries to the IOCCC. You may register while the contest is **pending** or **open**.
to the IOCCC. You may register while the contest is **pending** or **open**.
A few days after registering, you'll receive your UUID username and
temporary password, which you **MUST** change within 14 days. If you
@@ -129,51 +154,69 @@ email or for those who wait until the last minute to try to register!
See [Entering the IOCCC: the bare minimum you need to know](../quick-start.html#enter).
See [Rule 8 - Submission](rules.html#rule-8---submission).
See [Rule 8 - Submitting requirements](rules.html#rule8).
See [Guidelines for Rule 3 - Register](guidelines.html#guideline-3---register).
See [Guidelines for Rule 3 - Register for the IOCCC](guidelines.html#guideline-3---register).
<div id="rule4">
## Rule 4 - Files
<div id="rule4-required-files">
## Rule 4 - Required files
</div>
</div>
The submission **MUST** include at least these files: `Makefile`, `prog.c`,
`remarks.md`,`.info.json`, and `.auth.json`.
Your submission **MUST** include at least these files: `Makefile`, `prog.c`,
`remarks.md`,`.info.json`, and `.auth.json`, the latter two of which are
generated by `mkiocccentry(1)`. See [Rule 17 -
Use mkiocccentry](#rule17-mkiocccentry).
At a minimum the following requirements apply. Additional requirements
At a **minimum** the following requirements apply. Additional requirements
may be imposed by `mkiocccentry(1)` updates that have yet to be listed
here:
below.
* `.info.json`, and `.auth.json` **MUST** be generated by `mkiocccenty(1)`
when packing a submission, and **MUST** pass the `chksubmit(1)` tests.
**NOTE**: `mkiocccentry(1)` will reject any directory which has prohibited
files.
**NOTE**: by 'top directory' we mean the directory with `prog.c`, `Makefile`,
`remarks.md` and the `mkiocccentry(1)` generated files `.auth.json` and
`.info.json` and **NOT** the `topdir` arg to `mkiocccentry(1)`.
* `.info.json` and `.auth.json` **MUST** be generated by `mkiocccenty(1)`
when packing a submission. When `chksubmit(1)` is run on the submission
directory **ALL** tests must pass and if there is **ANY** problem with these
JSON files or if either is missing it will fail. See [Rule 17 - use
mkiocccentry](#rule17-mkiocccentry).
* The `Makefile`, `remarks.md`,`.info.json`, and `.auth.json` **MUST**
have a file size **greater than 0**.
have a file size **greater than 0** and **MUST** have content. Note that
`mkiocccentry(1)` will check for file **size** but will **NOT** check for
content.
* Your submitted source code **MUST** be called `prog.c`. When the `Makefile`
* Your submitted source code **MUST** be called `prog.c`. When the `Makefile`
compiles your code, the executable (if applicable) **MUST** be called `prog`.
The `Makefile` may compile your source code into other filenames as well.
The `Makefile` may compile your source code into other filenames as well, if you
want.
* As `prog`, `prog.alt`, `prog.alt.o`, `prog.o` may be created by your
`Makefile`, your submission **MUST NOT** include those files in
your top directory, as original content.
`Makefile`, your submission **MUST NOT** include those files in your **top**
directory.
* Your submission may **NOT** have any file that starts with `COPYING`,
`COPYRIGHT`, or `LICENSE` as those files are reserved by IOCCC.
* Your submission may **NOT** have in the top directory, `prog.orig.c`,
`README.md`, nor `index.html` as those files reserved by IOCCC.
* Your submission may **NOT** have in the **top** directory: `prog.orig.c`,
`README.md` or `index.html` as those files are reserved by the IOCCC.
* Your submission may **NOT** have in the top directory, any file
* Your submission may **NOT** have in the **top** directory any file
that matches a file glob pattern form `[0-9][0-9][0-9][0-9]_*.tar.bz2`
as those files are reserved by IOCCC.
* Your submission may **ONLY** contain files and directories. Other file
types such as symlinks, sockets, etc are **NOT** allowed.
types such as symlinks, sockets etc. are **NOT** allowed.
* All directories **MUST** have a file mode of **0755**. All files
**MUST** have the file mode of **0444**, except for files that
* **All** directories **MUST** have permission mode of **0755**. All files
**MUST** have the file mode of **0444**, EXCEPT for files that
end in `.sh` which must have a mode of **0555**.
* All files that end in `.md` **MUST** be in markdown format.
@@ -190,32 +233,36 @@ The `remarks.md` and `Makefile` are explained in more detail in the Guidelines.
See [IOCCC markdown guidelines](../markdown.html).
See [Rule 17 - Packaging](rules.html#rule-17---packaging).
See [Rule 17 - Use mkiocccentry](rules.html#rule17-mkiocccentry).
See FAQ on "[What permissions may my files be and what if I need different permissions?](../faq.html#file_perms)".
See the
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 the [Guidelines on the mkiocccentry toolkit](guidelines.html#mkiocccentry_toolkit).
See [Guidelines for the Makefile](guidelines.html#makefile).
See the
FAQ on "[What are the detailed recommendations for a submission Makefile?](../faq.html#makefile_details)".
<div id="rule5">
## Rule 5 - Integrity
<div id="rule5-modifying-files">
## Rule 5 - Do NOT modify submitted files or filenames or parent directories
</div>
</div>
Your submission **MUST NOT** modify the filenames or content of any of
your original submission, such as `prog.c`, `Makefile`, or any supplied
data files. To modify files, your program can make a copy or you can
use the `Makefile` to setup working copies. Any working copies **MUST** be
cleaned up by the `Makefile` `clobber` target, so as to restore the
directory to its original state.
Your submission **MUST NOT** modify the filenames or content of any of your
original submission, such as `prog.c`, `Makefile`, or **ANY** other supplied
files. To modify files, your program can make a copy or you can use the
`Makefile` to setup working copies. Any working copies **MUST** be cleaned up
by the `Makefile` `clobber` target, so as to restore the directory to its
original state.
Your submission **MUST NOT** create or modify directories and files
ABOVE the current directory with the exception of the `/tmp` and the
`/var/tmp` directories as long as the directory name or filename does
**NOT** start with "." (dot).
ABOVE the current directory (with the exception of the `/tmp` and the `/var/tmp`
directories and as long as the directory name or filename does **NOT** start
with a `.` (dot)).
The `Makefile` `clobber` target **MUST** be restore your submission into
The `Makefile` `clobber` target **MUST** restore your submission to its
original form, including the removal of any created files and directories.
Your code should be able to run under a
@@ -223,7 +270,9 @@ Your code should be able to run under a
<div id="rule6">
## Rule 6 - Free
<div id="rule6-free-rule">
## Rule 6 - Free Rule
</div>
</div>
I am **NOT** a Rule, I am a `free(void *human);` ‼️
@@ -237,92 +286,110 @@ See [Rule 19 - Prime](rules.html#rule-19---prime).
<div id="rule7">
<div id="rule7-original-work">
## Rule 7 - Original Work
</div>
</div>
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.
You, the author(s), **MUST** own the contents of your submission, **OR**, IF you
do **NOT** own the work, then 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.
You are permitted to use tools to write your code.
See [Rule 16 - Anonymous](rules.html#rule-16---anonymous).
See [Rule 16 - Anonymous Judging](rules.html#rule16-anonymous-judging).
See [Guidelines for Rule 7 - Original Work](guidelines.html#guideline-7---original-work).
<div id="rule8">
## Rule 8 - Submission
<div id="rule8-submitting-requirements">
## Rule 8 - Submitting requirements
</div>
</div>
The Submit Server will only accept submissions from those who have
registered and only while the contest is open.
The submit server will accept submissions **ONLY** from those who have
registered and **ONLY** while the contest is open.
The Submit Server places a total submission size limit of **3999971** bytes.
The submit server places a total size limit of **3999971** bytes **PER**
submission.
Each account has ten (**10.000**) submission slots (**0..9)**. Each submission
slot should be annotated by the server as to whether its was received,
processed, malformed, etc. Please take note of any errors, rectify,
and resubmit. In order to avoid potential packaging errors, it is **highly
recommended** to use `mkiocccentry(1)`.
and resubmit. In order to avoid potential packaging errors, it is **highly
recommended** to use `mkiocccentry(1)`, **AND** to check from time to time the
status on the submit server, to see if any tests run by the server failed to
validate your submission.
Do **NOT** register more than one account!
See
[Rule 3 - Register](rules.html#rule-3---register),
[Rule 15 - Building](rules.html#rule-15---building),
[Rule 3 - Registering for the IOCCC](rules.html#rule3-register),
[Rule 15 - GNU Makefile](rules.html#rule15-gnu-makefile),
and
[Rule 17 - Packaging](rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](rules.html#rule17-mkiocccentry).
<div id="rule9">
## Rule 9 - No hands
## Rule 9 - No interactive compiling allowed
</div>
Entries requiring human interaction to be initially compiled are **NOT**
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/).
permitted. However, see the guidelines. Each entry **MUST** automate the
build process using `bash`, `gmake`, `gcc` and/or `clang` and other commonly
available tools under an [SUS
environment](https://pubs.opengroup.org/onlinepubs/9799919799/).
**NOTE**: The references to `gmake(1)` can be any GNU Make compatible tool.
See [Rule 15 - Building](rules.html#rule-15---building).
**NOTE**: it is better to use the `${MAKE}` variable as then one may override
the make command.
**NOTE**: it is better and more portable to **NOT** modify the `${CC}` variable
in the Makefile.
See [Rule 15 - GNU Makefile](rules.html#rule15-gnu-makefile).
<div id="rule10">
## Rule 10 - Privileges
## Rule 10 - Program file permissions
</div>
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**
test platforms. If your program needs special permissions you **MUST**
document this fact and explain why it is needed in your submission’s
`remarks.md` file.
`remarks.md` file, preferably close to the top.
Furthermore, if you need a supplementary program that you include to
have these permissions, you will also have to explain this, because these
have these permissions, you will also have to explain this as well, because these
bits are **NOT** allowed in submissions and those bits will **NOT** be copied by
`mkiocccentry(1)`.
See [Rule 4 - Files](rules.html#rule-4---files),
See [Rule 4 - Required files](rules.html#rule4-required-files),
and
[Rule 5 - Integrity](rules.html#rule-5---integrity).
[Rule 5 - Do NOT modify files](rules.html#rule5-modifying-files).
<div id="rule11">
## Rule 11 - Abuse
<div id="rule11-legal-rule-abuse">
## Rule 11 - Legal rule abuse
</div>
</div>
Legal abuse of the rules is somewhat encouraged, but comes with risks.
A submission that, in the opinion of the Judges, violates the rules **WILL
Legal abuse of the rules is **somewhat** encouraged, but comes with risks.
A submission that, in the opinion of the Judges, **violates** the rules **WILL
BE DISQUALIFIED**. Submissions that plan to abuse the rules **MUST** justify
why their rule abuse is legal (or interesting) in the `remarks.md` file.
Submission packaging abuse will **NOT** be tolerated and for this reason
its recommended to use `mkiocccentry(1)`. During development you can
check your `prog.c` size limits using `iocccsize(1)`, e.g., `iocccsize -v1 prog.c`.
Overriding problems detected by any of the IOCCC tools
Submission packaging abuse will **NOT** be tolerated and for this reason,
amongst many others, it is recommended that you use `mkiocccentry(1)`. During
development you can check your `prog.c` size limits using `iocccsize(1)`, e.g.,
`iocccsize -v1 prog.c`. Overriding problems detected by any of the IOCCC tools
risks that the submission will be rejected.
If you do submit a rule abusing or violating submission, then consider
@@ -331,22 +398,26 @@ slot that does **NOT** violate the rules in case your rule abuse excuse
is rejected.
**IMPORTANT**: If you do submit such an alternate non-rule abusing
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.
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).
See [Guidelines for Rule 11 - Legal rule
abuse](guidelines.html#guideline-11---abuse).
<div id="rule12">
<div id="rule12-utf8">
## Rule 12 - UTF-8
</div>
</div>
Use of UTF-8 is supported by `C89` standard and its updates and so too by the IOCCC.
Use of UTF-8 is supported by `C89` standard and its updates and so too by the
IOCCC.
<div id="rule13">
## Rule 13 - Newlines
## Rule 13 - No carriage returns in prog.c
</div>
Any C source that fails to compile because lines contain carriage-returns
@@ -356,91 +427,104 @@ or `remarks.md` files, but instead end lines with Unix newline (line-feed,
CTRL+J, `\n`).
You are permitted, in order to try and squeeze your `prog.c` under a
[Rule 2a Gross Size](rules.html#rule-2a-gross-size) and/or
[Rule 2b Next Size](rules.html#rule-2b-net-size)
limits, to **NOT** end source with a newline. If you
[Rule 2a Gross Size](rules.html#rule2a-gross-size) and/or
[Rule 2b Net Size](rules.html#rule2b-net-size)
limits, to **NOT** end source with a newline. If you
need to do this, please document that in your `remarks.md` file and if
your compiler complains about this, document this too and update your
`Makefile` to account for this.
<div id="rule14">
## Rule 14 - Resubmit
## Rule 14 - Resubmitting lost submissions
</div>
Submissions that are substantially similar to previous winning IOCCC
entries are discouraged.
You are allowed to resubmit to a later contest, a submission that didn't
win the IOCCC. If you do so, then you would be well advised to try and
enhance and improve your submission. If you do resubmit something that
didn't previously win, then you are encouraged to mention this in your
`remarks.md` file as this sometimes helps.
You are allowed to resubmit to a later contest, a submission that didn't win the
IOCCC. If you do so, then you would be **WELL ADVISED** to try and enhance and
improve your submission. If you do resubmit something that didn't previously
win, then you are encouraged to mention this in your `remarks.md` file as this
**sometimes** helps.
<div id="rule15">
## Rule 15 - Building
<div id="rule15-gnu-makefile">
## Rule 15 - GNU Makefile
</div>
</div>
The `Makefile` **MUST** adhere to GNU Makefile syntax. Its recommended
that you copy and rename the `Makefile.example` as a template. The primary
target of the `Makefile` **MUST** be `prog` and the source file is `prog.c`.
The C compiler and preprocessor **MUST** be invoked using `${CC}` and `${CPP}`
macros respectively.
The `Makefile` **MUST** adhere to GNU Makefile syntax. It's highly recommended
that you copy the [Makefile.example](Makefile.example) as a template, renaming
it to `Makefile`. The primary target of the `Makefile` **MUST** be `prog` and
the source file is `prog.c`. The C compiler and preprocessor **MUST** be
invoked using `${CC}` and `${CPP}` macros respectively.
The `clobber` target should clean and restore the submission directory
tree to its original state, such as removing temporary files or any
modified data files. Don't assume that `git` tool chain is installed,
i.e., do **NOT** expect `git clean -f` to work.
The `clobber` target **MUST** clean and restore the submission directory tree to
its original state, such as removing temporary files or any modified data files.
Don't assume that `git` tool chain is installed, i.e. do **NOT** expect `git
clean -f` to work. To be clear: do **NOT** use `git` to clean out files as this
can cause problems in the winner repo!
The `Makefile` **MUST** use a syntax that is compatible with
`bash(1)` and GNU `make(1)`. You are encouraged to use `SHELL=
`bash(1)` and GNU `make(1)`. You are encouraged to use `SHELL=
bash` in your `Makefile`; please add a space between the `=` and
the value such as:
``` <!---sh-->
``` <!---makefile-->
SHELL= bash
```
Assume that commands commonly found in [Single UNIX
Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
environments and systems are available in the search
`$PATH`. Avoid command options that aren't part of
`$PATH`. Avoid command options that aren't part of
[SUS](https://en.wikipedia.org/wiki/Single_UNIX_Specification), such as
GNU long name options `--example` or extensions like `grep -P`.
GNU long name options (such as `--example`) or extensions like `grep -P`.
Do **NOT** assume that `.` (current directory) is in the `$PATH` environment variable.
Do **NOT** assume that `.` (current directory) is in the `$PATH` environment
variable.
See [Rule 4 - Files](rules.html#rule-4---files).
See [Rule 4 - Required files](rules.html#rule4-required-files).
See FAQ on "[What are the detailed recommendations for a submission Makefile?](../faq.html#makefile_details)".
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).
See [Guidelines for Rule 15 - GNU Makefile](guidelines.html#guideline-15---building).
<div id="rule16">
## Rule 16 - Anonymous
<div id="rule16-anonymous-judging">
## Rule 16 - Anonymous judging
</div>
</div>
Your source code, data files, remarks, and program output **MUST NOT**
identify the author(s) of your code (unless you are **Peter Honeyman**
or pretending to be **Peter Honeyman**). In order to be impartial the
or pretending to be **Peter Honeyman**). In order to be impartial the
[Judges](https://www.ioccc.org/judges.html) do **NOT** know who is submitting
entries to the IOCCC until final selection is made. Even if you are
a past winner, you **MUST NOT** reveal your identity deliberately or by
accident anywhere in your submission. ***Failure to comply may result
in the submission being disqualified.***
programs to the IOCCC until final selection is made, and **only** submissions
that won.
Even if you are a past winner, you **MUST NOT** reveal your identity
deliberately or by accident anywhere in your submission. **_Failure to comply
may result in the submission being disqualified_**.
<div id="rule17">
## Rule 17 - Packaging
<div id="rule17-mkiocccentry">
## Rule 17 - Use `mkiocccentry`
</div>
</div>
TL;DR: use `mkiocccentry(1)` to package your submission.
The files, directories, and paths **MUST** conform to the limits imposed by
`mkiocccentry(1)`, including but **NOT** limited, to their names, count, path
length, directory tree depth, and permissions.
The submission tree may have at most **13** directories and maximum
directory depths of **4**. The maximum number of files, excluding
directory depths of **4**. The maximum number of files, excluding
`prog.c`, `remarks.md`, `Makefile`, `prog.alt.c`, `try.sh`, `try.alt.sh`,
`.info.json` and `.auth.json` is **31**. And the maximum file-path
component is **38** and maximum path length is **60**.
@@ -448,47 +532,51 @@ component is **38** and maximum path length is **60**.
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 **MUST** be a **v7 format** tarball.
The tarball **MUST** be a **v7 format** tarball, and any supplementary tarballs
you provide **MUST** also be **v7 format**.
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.
The submission **MUST** pass all `txzchk(1)` checks, and the tarball filename
**MUST** pass all `fnamchk(1)` checks as well.
You may **NOT** submit a tarball created by the `-d`, `-e`, **NOR** by the `-s seed` options of `mkiocccentry(1)`.
You may **NOT** submit a tarball created by the `-d`, `-e` **OR** by the `-s
seed` options of `mkiocccentry(1)`.
The unpacked submission directory **MUST** pass the checks performed by the
current version of `chksubmit(1)`.
minimum required 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 **NOT** use a [mkiocccentry
toolkit](https://github.com/ioccc-src/mkiocccentry) command line options that
are labelled as "**for TESTING purposes**", **OR** labelled 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_".
Submissions may **ONLY** use [mkiocccentry
toolkit](https://github.com/ioccc-src/mkiocccentry) command lines that confirm
to the command's `-h` "_print help message_", again notwithstanding the options
for testing and the IOCCC judges.
The `prog.c` file **MUST** pass the [Rule 2 - Size](rules.html#rule-2---size)
size checks performed by `iocccsize(1)`.
The `prog.c` file **MUST** pass the [Rule 2 - Size](rules.html#rule2-size)
checks performed by `iocccsize(1)`.
The `.auth.json` and `.info.json` files **MUST** be compatible with what `chksubmit(1)` generates.
The `.auth.json` and `.info.json` files **MUST** be compatible with what
`mkiocccentry(1)` generates.
Any submission that fails to pass the checks performed by the most recent version of the
[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
Any submission that fails to pass the checks performed by the minimum required
version of the [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
**WILL be rejected**!
See [Rule 4 - Files](rules.html#rule-4---files).
See [Rule 4 - Required files](rules.html#rule4-required-files).
See FAQ on "[What is the mkiocccentry tool, how do I obtain it and how do I use it?](../faq.html#mkiocccentry)".
See the
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).
See the [Guidelines for Rule 17 - Use mkiocccentry](guidelines.html#guideline-17---packaging).
<div id="rule18">
## Rule 18 - License
## Rule 18 - Submission license
</div>
The entirety of your submission **MUST** be submitted under the following license:
@@ -506,7 +594,7 @@ This 19th rule, while prime, is reserved for future abuse 😁.
Additional rules, both humorous and otherwise, may be added
below this rule in future contests.
See [Rule 6 - Free](rules.html#rule-6---free).
See [Rule 6 - Free Rule](rules.html#rule6-free-rule).
## Further Reading
@@ -519,7 +607,7 @@ for an overview of how to enter the contest.
See also the [FAQ](../faq.html).
And now [for something completely different](guidelines.html#fun)
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.
next/submit.html
+4 -4
View File
@@ -452,7 +452,7 @@
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
<!-- BEFORE: 1st line of markdown file: next/submit.md -->
<p>Use mkiocccentry to rebuild# How to upload your submission to the IOCCC</p>
<h1 id="how-to-upload-your-submission-to-the-ioccc">How to upload your submission to the IOCCC</h1>
<p><strong>IMPORTANT NOTE</strong>: The <a href="https://submit.ioccc.org">IOCCC submit server</a>
is only ready for submissions
<strong>ONLY WHEN THE CONTEST IS <a href="../faq.html#open">open</a></strong>.</p>
@@ -518,7 +518,7 @@ the file selection step.</p>
<li>the status of the submission</li>
<li>the filename, which will be in the correct format, assuming you used
<code>mkiocccentry(1)</code> which is <strong>HIGHLY</strong> recommended so that you do not break
<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</li>
<a href="rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</li>
<li>the file length, which <code>txzchk(1)</code> will also verify (the file itself and the
tarball listing).</li>
<li>the upload date.</li>
@@ -576,7 +576,7 @@ To see any status updates, you should logout and log back in later.</p>
<p>… or <strong>ANY</strong> other error then you <strong>MUST FIX</strong> your submission, repackage your
tarball with <code>mkiocccentry</code> and upload to the same slot again! If you do not fix
this your submission <strong>WILL BE REJECTED</strong> for violating
<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
<a href="rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>!</p>
<p>If the format test went well, then you will see:</p>
<blockquote>
<p><strong>Status: submit file received by the IOCCC judges. Passed both txzchk and chksubmit tests.</strong></p>
@@ -586,7 +586,7 @@ rules or that everything is OK once the tarball is extracted; it simply means
the tests performed by the tools passed. If you find a flaw in a tool and
abuse it and the tests pass then you stand a significant chance of having your
submission rejected for violating
<a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>,
<a href="rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>,
even if the tests passed.</p>
<p>For details on <code>txzchk</code>, see the
FAQ on “<a href="../faq.html#txzchk">txzchk</a>”.</p>
next/submit.md
+4 -4
View File
@@ -1,4 +1,4 @@
Use mkiocccentry to rebuild# How to upload your submission to the IOCCC
# How to upload your submission to the IOCCC
**IMPORTANT NOTE**: The [IOCCC submit server](https://submit.ioccc.org)
is only ready for submissions
@@ -87,7 +87,7 @@ And in the slot it will give you important details like:
- the status of the submission
- the filename, which will be in the correct format, assuming you used
`mkiocccentry(1)` which is **HIGHLY** recommended so that you do not break
[Rule 17 - Packaging](rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](rules.html#rule17-mkiocccentry)!
- the file length, which `txzchk(1)` will also verify (the file itself and the
tarball listing).
- the upload date.
@@ -158,7 +158,7 @@ Or:
... or **ANY** other error then you **MUST FIX** your submission, repackage your
tarball with `mkiocccentry` and upload to the same slot again! If you do not fix
this your submission **WILL BE REJECTED** for violating
[Rule 17 - Packaging](rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](rules.html#rule17-mkiocccentry)!
If the format test went well, then you will see:
@@ -169,7 +169,7 @@ rules or that everything is OK once the tarball is extracted; it simply means
the tests performed by the tools passed. If you find a flaw in a tool and
abuse it and the tests pass then you stand a significant chance of having your
submission rejected for violating
[Rule 17 - Packaging](rules.html#rule-17---packaging),
[Rule 17 - Use mkiocccentry](rules.html#rule17-mkiocccentry),
even if the tests passed.
For details on `txzchk`, see the
quick-start.html
+3 -3
View File
@@ -566,13 +566,13 @@ for more info.</p></li>
<p><strong>NOTE</strong>: Please see our <a href="markdown.html">IOCCC markdown guide</a> for <strong>important information</strong> on using markdown in the IOCCC.</p>
<p>If the <code>mkiocccentry</code> tool indicates that there is a problem with your
submission, especially if it identifies a
<a href="next/rules.html#rule-2---size">Rule 2 - Size</a>,
<a href="next/rules.html#rule2-size">Rule 2 - Size restrictions</a>,
or any other <a href="next/rules.html">rule</a>, related problem, you are <strong>strongly</strong> encouraged to revise and
correct your entry and then re-run the <code>mkiocccentry</code> tool.</p>
<p>If you choose to risk violating <a href="next/rules.html">Rules</a>, be sure and explain your reason
for doing so in your <code>remarks.md</code> file.</p>
<p>See also
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</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
@@ -581,7 +581,7 @@ tools to set the path to the required tools.</p>
<p>Do remember to make sure you have the latest vers
<code>chksubmit(1)</code>, <code>txzchk(1)</code> and <code>fnamchk(1)</code>. And remember to make sure you have
the latest version so you do not violate
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>.
<a href="next/rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>.
See the
FAQ on “<a href="faq.html#obtaining_mkiocccentry">obtaining the latest mkiocccentry tools</a>”,
the
quick-start.md
+3 -3
View File
@@ -162,7 +162,7 @@ Three files are required to exist in `topdir`:
If the `mkiocccentry` tool indicates that there is a problem with your
submission, especially if it identifies a
[Rule 2 - Size](next/rules.html#rule-2---size),
[Rule 2 - Size restrictions](next/rules.html#rule2-size),
or any other [rule](next/rules.html), related problem, you are **strongly** encouraged to revise and
correct your entry and then re-run the `mkiocccentry` tool.
@@ -170,7 +170,7 @@ If you choose to risk violating [Rules](next/rules.html), be sure and explain yo
for doing so in your `remarks.md` file.
See also
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-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
@@ -181,7 +181,7 @@ tools to set the path to the required tools.
Do remember to make sure you have the latest vers
`chksubmit(1)`, `txzchk(1)` and `fnamchk(1)`. And remember to make sure you have
the latest version so you do not violate
[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
See the
FAQ on "[obtaining the latest mkiocccentry tools](faq.html#obtaining_mkiocccentry)",
the