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

Merge pull request #67 from xexyl/guidelines-updates

Browse Source 
Many fixes and other updates to guidelines
This commit is contained in:
Landon Curt Noll authored and GitHub committed 2025-01-23 12:39:21 -08:00
2 parents b2bc88182f 7ef8df9e49
commit 38512e1c2d
2 files changed
+608 -463
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

next/guidelines.html
+306 -233
View File
@@ -492,9 +492,9 @@ about them. The <a href="guidelines.html">IOCCC guidelines</a> should be viewed
<a href="guidelines.html">guidelines</a> <em>but remain within the <a href="rules.html">rules</a></em></strong> <em>are
allowed</em>. Even so, you are safer if you remain within the <a href="guidelines.html">IOCCC
guidelines</a>.</p>
<p><strong>You should read the current <a href="rules.html">IOCCC rules</a>, prior to submitting
entries</strong>. The <a href="rules.html">rules</a> are typically published along with the <a href="guidelines.html">IOCCC
guidelines</a>..</p>
<p>You <strong>SHOULD read the CURRENT <a href="rules.html">IOCCC rules</a></strong>, <em>prior</em> to submitting
code to the contest. The <a href="rules.html">rules</a> are typically published along with
the <a href="guidelines.html">IOCCC guidelines</a>.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="new">
<h1 id="whats-new-this-ioccc">WHAT’S NEW THIS IOCCC</h1>
@@ -514,7 +514,7 @@ This contest will enter the <strong><a href="../status.html#judging">judging</a>
</p>
<p class="leftbar">
<strong>IMPORTANT NOTE</strong>: Until the content enters the <strong><a href="../status.html#open">open</a></strong> state, any or all
of the above <strong>dates and times may change</strong>!
of the above <strong>dates and times may change <em>AT ANY TIME</em></strong>!
</p>
<p class="leftbar">
The reason for the times of day are so that key IOCCC events are <strong>calculated</strong>
@@ -524,100 +524,70 @@ to be a <strong>fun</strong>ctional UTC time. :-)
Until the contest status becomes <strong><a href="../status.html#open">open</a></strong>,
the <a href="rules.html">IOCCC rules</a>,
<a href="guidelines.html">IOCCC guidelines</a> and the tools in the
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>, should be
considered provisional <strong>BETA</strong> versions and <strong>may be adjusted <em>AT ANY TIME</em></strong>
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>, <strong>SHOULD be
considered</strong> provisional <strong>BETA</strong> versions and <strong>may be adjusted <em>AT ANY TIME</em></strong>
before the contest status becomes <strong><a href="../status.html#open">open</a></strong>.
</p>
<p class="leftbar">
You <strong>MUST</strong> <a href="register.html">register</a> in order to submit your entry to the IOCCC.
You <strong>MUST</strong> <a href="register.html">register</a> in order to participate in the IOCCC.
You may <a href="register.html">register</a> while the contest is either
<strong><a href="../status.html#pending">pending</a></strong> or <strong><a href="../status.html#open">open</a></strong>.
</p>
<p class="leftbar">
See the
FAQ on “<a href="../quick-start.html#enter">how to register and submit to the IOCCC</a>”
for instructions on registering and participating in the IOCCC, as the process has changed from previous years!
for instructions on registering and participating in the IOCCC, as the process
has changed from previous years!
</p>
<p class="leftbar">
When the contest is <strong><a href="../status.html#open">open</a></strong>, an
<a href="../judges.html">IOCCC judge</a> will email you your <a href="https://submit.ioccc.org">submit server</a>
<strong>Username</strong> and <strong>Initial password</strong>. This takes some time (maybe even a few days) for an
<a href="../judges.html">IOCCC judge</a> to process your registration and email you your
initial login and password.
When the contest is <strong><a href="../status.html#open">open</a></strong>, an <a href="../judges.html">IOCCC
judge</a> will email you your <a href="https://submit.ioccc.org">submit
server</a> <strong>Username</strong> and <strong>Initial password</strong>. This
takes some time (maybe even a few days) for an <a href="../judges.html">IOCCC judge</a> to
process your registration and email you your initial login and password, so be
sure to give yourself enough time.
</p>
<p class="leftbar">
Those who <a href="register.html">register</a> while the contest status is <strong><a href="../status.html#pending">pending</a></strong>
will receive email with their <a href="https://submit.ioccc.org">submit server</a> <strong>Username</strong> and <strong>Initial password</strong>
from an <a href="../judges.html">IOCCC judge</a> shortly after the contest status becomes <strong><a href="../status.html#open">open</a></strong>.
Those who <a href="register.html">register</a> while the contest status is
<strong><a href="../status.html#pending">pending</a></strong> will receive email with their <a href="https://submit.ioccc.org">submit
server</a> <strong>Username</strong> and <strong>Initial password</strong> from an
<a href="../judges.html">IOCCC judge</a> shortly after the contest status becomes
<strong><a href="../status.html#open">open</a></strong>.
</p>
<p class="leftbar">
Once an <a href="../judges.html">IOCCC judge</a> emails you your <strong>Username</strong> and <strong>Initial password</strong>, you
will have 72 hours to <a href="pw-change.html">change your submit server initial password</a>.
If you do not change your <strong>Initial password</strong> in time, you will have to <a href="register.html">re-register</a>.
If you do not change your <strong>Initial password</strong> in time, you will have to
<a href="register.html">re-register</a>. You may <strong>NOT</strong> upload any submission until you
have changed your <strong>Initial password</strong> and logged back in!
</p>
<p class="leftbar">
Because it takes time (maybe even a few days) for an <a href="../judges.html">IOCCC judge</a>
to process your registration and email you your initial login and password,
you should <strong>MAKE SURE</strong> you give yourself enough time before the contest closes.
you should <strong>MAKE SURE</strong> to give yourself enough time before the contest closes.
In other words, <strong>DO NOT WAIT TO REGISTER UNTIL THE FINAL DAYS</strong>!
The <a href="../judges.html">IOCCC judges</a> 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 class="leftbar">
For those who have <a href="register.html">registered</a> and received by email, their
Once you have <a href="register.html">registered</a>, and received by email, your
<a href="https://submit.ioccc.org">submit server</a> <strong>Username</strong> and <strong>Initial password</strong>
from an <a href="../judges.html">IOCCC judge</a>, you may upload your submission to
the <a href="https://submit.ioccc.org">submit server</a> only while the
contest <strong><a href="../status.html#open">open</a></strong>.
from an <a href="../judges.html">IOCCC judge</a>, you may, after <a href="pw-change.html">changing your initial
password</a> upload your submission to
the <a href="https://submit.ioccc.org">submit server</a>, as long as the contest
<strong><a href="../status.html#open">open</a></strong>.
</p>
<p class="leftbar">
The <a href="https://submit.ioccc.org">submit server</a> will become active when the
contest is <strong><a href="../status.html#pending">pending</a></strong>.
Until the contest status becomes <strong><a href="../status.html#pending">pending</a></strong>,
the <a href="https://submit.ioccc.org">submit server</a> might be offline and/or unresponsive.
</p>
<p class="leftbar">
The <a href="https://submit.ioccc.org">submit server</a>, in accordance with <a href="rules.html#rule17">Rule 17</a>,
places a limit of <strong>3999971</strong> octets on the size of your upload.
</p>
<p class="leftbar">
You are <strong>STRONGLY</strong> advised to use the <code>mkiocccentry(1)</code> tool
as found in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>
to form the file to upload to the <a href="https://submit.ioccc.org">submit server</a>.
</p>
<p class="leftbar">
See the
FAQ on “<a href="../faq.html#mkiocccentry">obtaining and compiling the mkiocccentry tools</a>”
for more information about the <code>mkiocccentry(1)</code> tool.
</p>
<p class="leftbar">
While the contest is <strong><a href="../status.html#open">open</a></strong>, you may modify your previously
uploaded submission by rebuilding your submission with the <code>mkiocccentry(1)</code> tool
and then re-uploading it to the same slot number on the <a href="https://submit.ioccc.org">submit server</a>.
</p>
<p class="leftbar">
To help you with this, so that you do not have to repeatedly answer all the
questions, the <code>mkiocccentry(1)</code> tool has the options <code>-a answers</code>, <code>-A answers</code>
and <code>-i answers</code>, where <code>-a</code> will write to an answers file if it does not
already exist, <code>-A</code> will overwrite the file and <code>-i</code> will read the answers from
the file.
</p>
<p class="leftbar">
Once the contest enters the <strong><a href="../status.html#judging">judging</a></strong> state, you will
<strong>NOT</strong> be allowed to upload your submission files.
</p>
<p class="leftbar">
The <a href="https://submit.ioccc.org">submit server</a> will become active when the contest is <strong><a href="../status.html#open">open</a></strong>.
Until the contest status becomes <strong><a href="../status.html#open">open</a></strong>,
the <a href="https://submit.ioccc.org">submit server</a> may be offline and/or unresponsive.
</p>
<p class="leftbar">
The <a href="rules.html#rule2a">Rule 2a</a> size has <strong>increased from 4096 to 4993</strong> bytes.
</p>
<p class="leftbar">
The <a href="rules.html#rule2b">Rule 2b</a> size has <strong>increased from 2053 to 2503</strong>
bytes.
</p>
<p class="leftbar">
The new default way to compile submissions: <code>-std=gnu17 -O3 -g3 -Wall -Wextra -pedantic</code>.
You <strong>are encouraged</strong> to use the example Makefile here. For more details and help,
see below in the <a href="#makefile">Makefile section</a>.
</p>
<p class="leftbar">
Submissions are uploaded as a single xz compressed tarball.
</p>
<p class="leftbar">
@@ -625,10 +595,6 @@ To assist in the formation of the xz compressed tarball for submission, use the
<code>mkiocccentry(1)</code> tool as found in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>.
</p>
<p class="leftbar">
<a href="rules.html#rule17">Rule 17</a> has been <strong>significantly modified</strong>
to account for the new <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a> tools.
</p>
<p class="leftbar">
If you wish to test that your submission passes the <code>mkiocccentry(1)</code> tests
without having to put 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.
@@ -641,92 +607,41 @@ that if the directory exists already, you will have to remove it or move it
before this option will work a second time, just like in normal mode.
</p>
<p class="leftbar">
<a href="rules.html#rule17">Rule 17</a> has been <strong>significantly modified</strong>
to account for the new <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a> tools.
Thus, you are <strong>STRONGLY</strong> advised to use the <code>mkiocccentry(1)</code> tool
as found in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>
to form the file to upload to the <a href="https://submit.ioccc.org">submit server</a>. Not
doing so puts you at a very big risk of violating <a href="rules.html#rule17">Rule 17</a>.
</p>
<p class="leftbar">
See the
FAQ on “<a href="../faq.html#mkiocccentry">obtaining and compiling the mkiocccentry tools</a>”
FAQ on “<a href="../faq.html#mkiocccentry">obtaining and compiling the most recent mkiocccentry tools</a>”
and the
FAQ on “<a href="../quick-start.html#enter">how to enter the IOCCC</a>”
as that FAQ has import details on
as that FAQ has important details on
<a href="register.html">how to register</a>
as well as
<a href="submit.html">how to upload your submission</a> to the IOCCC.
</p>
<p>Jump to: <a href="#">top</a></p>
<div id="hints">
<div id="suggestions">
<h1 id="hints-and-suggestions">HINTS AND SUGGESTIONS:</h1>
</div>
</div>
<p>You are encouraged to examine the <a href="../years.html">winners of previous contests</a>.</p>
<p>Keep in mind that <a href="rules.html">rules</a> change from year to year, so some <a href="../years.html">winning
entries</a> might not be valid submissions this year; what <em>was</em> unique
and novel one year <em>might be ‘old’ the next year</em>.</p>
<p>A submission is usually examined in a number of ways. We typically apply
a number of tests to a submission:</p>
<ul>
<li>look at the original source</li>
<li>convert ANSI trigraphs to ASCII</li>
<li>C pre-process the source ignoring <code>#include</code> lines</li>
<li>C pre-process the source ignoring <code>#define</code> <em>and</em> <code>#include</code> lines</li>
<li>run it through a C beautifier</li>
<li>examine the algorithm</li>
<li>compile it (with flags to enable all warnings)</li>
<li>execute it</li>
</ul>
<p>You should consider how your submission looks in each of the above tests.
You should ask yourself if your submission remains obscure after it has been
‘<em>cleaned up</em>’ by the C pre-processor and a C beautifier.</p>
<p>Your submission need not pass all of the above tests. In certain
cases, a test is not important. Entries that compete for the
‘<strong>strangest/most creative source layout</strong>’ need not do as well as
others in terms of their algorithm. On the other hand, given
two such entries, we are more inclined to pick the submission that
does something interesting when you run it.</p>
<p>We try to avoid limiting creativity in our <a href="rules.html">rules</a>. As such, we
leave the contest open for creative rule interpretation. As in <a href="https://en.wikipedia.org/wiki/Real_life">real
life</a> programming, interpreting a
requirements document or a customer request is important. For this reason, we
often award ‘<strong>Best abuse of the <a href="rules.html">rules</a></strong>’ or ‘<strong>Worst abuse of the
<a href="rules.html">rules</a></strong>’ or some variation to a submission that illustrates this
point in an ironic way.</p>
<p>We do realize that there are holes in the <a href="rules.html">rules</a>, and invite
entries to attempt to exploit them. We will award ‘<strong>Worst abuse of the
<a href="rules.html">rules</a></strong>’ or ‘<strong>Best abuse of the <a href="rules.html">rules</a></strong>’ or some
variation and then plug the hole next year.</p>
<p class="leftbar">
When we do need to plug a hole in the <a href="rules.html">IOCCC rules</a> or <a href="guidelines.html">IOCCC
guidelines</a>, we will attempt to use a very small plug, if not
smaller. Or, maybe not. :-)
While the contest is <strong><a href="../status.html#open">open</a></strong>, you may modify your
previously uploaded submission by rebuilding your submission with the
<code>mkiocccentry(1)</code> tool and then re-uploading it to <strong>the same slot number</strong> on the
<a href="https://submit.ioccc.org">submit server</a>.
</p>
<p class="leftbar">
There may be fewer than 2^7+1 reasons why these <a href="guidelines.html">IOCCC
guidelines</a> seem obfuscated.
To help you with this, so that you do not have to repeatedly answer all the
questions, the <code>mkiocccentry(1)</code> tool has the options <code>-a answers</code>, <code>-A answers</code>
and <code>-i answers</code>, where <code>-a</code> will write to an answers file (if it does not
already exist), <code>-A</code> will overwrite the file and <code>-i</code> will read the answers from
the file. If you use <code>-A</code>, be sure you don’t overwrite another file by accident!
</p>
<p>Check out your program and be sure that it works. We sometimes make
the 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
of the best entries fall down because they didn’t work.</p>
<p class="leftbar">
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. If you do have a bug, you are better off
documenting it. Noting “<em>this submission sometimes prints the 4th power
of a prime by mistake</em>” would save the above submission. And sometimes,
a strange bug/feature can even help the submission! Of course, a correctly
working submission is best. Clever people will note that 16 might be prime
under certain conditions. Wise people, when submitting something clever
will fully explain such cleverness in their submission’s <code>remarks.md</code> file.
Once the contest enters the <strong><a href="../status.html#judging">judging</a></strong> state, you will
<strong>NOT</strong> be allowed to upload your submission files, so do give yourself enough
time.
</p>
<p>People who are considering to just use some complex mathematical
function or state machine to spell out something such as “<em>hello,
world!</em>” <strong>really really, <em>and we do mean REALLY</em>, do need to be more creative</strong>.</p>
<p>Ultra-obfuscated programs are, in some cases, easier to
deobfuscate than subtly-obfuscated programs. Consider using
misleading or subtle tricks layered on top of or under an
appropriate level of obfuscation. A clean looking program with
misleading comments and variable names might be a good start.</p>
<p>When programs use VTxxx/ANSI sequences, they should NOT be limited to a
specific terminal brand. Those programs that work in a standard xterm
are considered more portable.</p>
<p class="leftbar">
<a href="rules.html#rule2">Rule 2</a> (the size rule) refers to the use of the IOCCC size
tool called <code>iocccsize(1)</code>.
@@ -740,18 +655,31 @@ To further clarify <a href="rules.html#rule2">Rule 2</a>, we subdivided it into
<strong>2a</strong> and <strong>2b</strong>.
</p>
<p class="leftbar">
The overall size limit (see <a href="rules.html#rule2a">Rule 2a</a>) on <code>prog.c</code> is now <strong>4993 bytes</strong>.
The overall size limit (see <a href="rules.html#rule2a">Rule 2a</a>) on <code>prog.c</code> has been
<strong>increased from 4096 to 4993</strong> bytes.
</p>
<p class="leftbar">
Your submission must satisfy BOTH the maximum size <a href="rules.html#rule2a">Rule
The <a href="rules.html#rule2a">Rule 2a</a> size was changed from
4096 to 4993: a change that keeps the “2b to 2a” size ratio to a
value similar to the <a href="../faq.html#size_rule2001-2012">2001-2012</a> and
<a href="../faq.html#size_rule2013-2020">2013-2020</a> IOCCC eras.
</p>
<p class="leftbar">
The <a href="rules.html#rule2b">Rule 2b</a> size has <strong>increased from 2053 to 2503</strong>
bytes.
</p>
<p class="leftbar">
Your submission must satisfy <strong>BOTH</strong> the maximum size <a href="rules.html#rule2a">Rule
2a</a> <strong>AND</strong> the IOCCC size tool <a href="rules.html#rule2b">Rule 2b</a>.
</p>
<p class="leftbar">
This IOCCC size tool imposes a 2nd limit on C code size (see <a href="rules.html#rule2a">Rule
The IOCCC size tool imposes a 2nd limit on C code size (see <a href="rules.html#rule2a">Rule
2a</a>). To check your code against <a href="rules.html#rule2">Rule 2</a>:
</p>
<pre><code> iocccsize prog.c</code></pre>
<p>The IOCCC size tool algorithm may be summarized as follows:</p>
<p class="leftbar">
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 octets as 1
@@ -769,6 +697,10 @@ counted by the IOCCC size tool. This is a <em>feature</em>, not a bug!
the IOCCC size tool source code conflict, the algorithm implemented
by the IOCCC size tool source code is preferred by the <a href="../judges.html">judges</a>.</p>
<p class="leftbar">
In other words, make sure <code>iocccsize</code> does not flag any issues with your
<code>prog.c</code>.
</p>
<p class="leftbar">
There are at least 2 other reasons for selecting 2503 as the 2nd limit besides
the fact that 2503 is a prime. These reasons may be searched for and discovered
if you are <a href="https://t5k.org/curios/page.php/2503.html">“Curios!” about 2503</a>.
@@ -779,15 +711,111 @@ BESM-6, and 2503 is a decimal anagram of 2053.
obviates some of the need to <code>#define</code> C reserved words in an effort
to get around the size limits of <a href="rules.html#rule2">Rule 2</a>.</p>
<p>Yes Virginia, <strong>that is a hint</strong>!</p>
<p>Jump to: <a href="#">top</a></p>
<div id="hints">
<div id="suggestions">
<h1 id="hints-and-suggestions">HINTS AND SUGGESTIONS:</h1>
</div>
</div>
<p>You are <strong>encouraged</strong> to examine the <a href="../years.html">winners of previous contests</a>.</p>
<p>Keep in mind that <a href="rules.html">rules</a> change from year to year, so some <a href="../years.html">winning
entries</a> might not be valid submissions this year; what <em>was</em> unique
and novel one year <em>might be ‘old’ the next year</em>.</p>
<p>A submission is usually examined in a number of ways. We typically apply
a number of tests to a submission:</p>
<ul>
<li>look at the original source</li>
<li><p class="leftbar">
convert ANSI trigraphs and digraphs to normal C
</p></li>
<li>C pre-process the source ignoring <code>#include</code> lines</li>
<li>C pre-process the source ignoring <code>#define</code> <em>and</em> <code>#include</code> lines</li>
<li>run it through a C beautifier</li>
<li>examine the algorithm</li>
<li>compile it (with flags to enable all warnings)</li>
<li>execute it</li>
</ul>
<p>You should consider how your submission looks in each of the above tests.
You should ask yourself if your submission remains obscure after it has been
‘<em>cleaned up</em>’ by the C pre-processor and a C beautifier.</p>
<p>Your submission need not pass all of the above tests. In certain
cases, a test is not important. Entries that compete for the
‘<strong>strangest/most creative source layout</strong>’ need not do as well as
others in terms of their algorithm. On the other hand, given
two such entries, we are more inclined to pick the submission that
does something interesting when it’s executed.</p>
<p>We try to avoid limiting creativity in our <a href="rules.html">rules</a>. As such, we
leave the contest open for creative rule interpretation. As in <a href="https://en.wikipedia.org/wiki/Real_life">real
life</a> programming, interpreting a
requirements document or a customer request is important. For this reason, we
often award ‘<strong>Best abuse of the <a href="rules.html">rules</a></strong>’ or ‘<strong>Worst abuse of the
<a href="rules.html">rules</a></strong>’ or some variation to a submission that illustrates this
point in an ironic way.</p>
<p class="leftbar">
The <a href="rules.html#rule2a">Rule 2a</a> size was changed from
4096 to 4993: a change that keeps the “2b to 2a” size ratio to a
value similar to the <a href="../faq.html#size_rule2001-2012">2001-2012</a> and
<a href="../faq.html#size_rule2013-2020">2013-2020</a> IOCCC eras.
Although we are in an age where AI/LLM can create code, we don’t want to stop
anyone from using any tools they like when they’re working on their submissions.
</p>
<p class="leftbar">
The IOCCC has a rich history of remarkable winning entries created by authors
who skillfully employed various code-related techniques such as code generators,
code analysis tools, machine learning tools, natural language models, code
copilot tools, and integrated development environments. Although it is <strong>NOT</strong>
required to use these kinds of tools in order to compile or run a submission,
individuals are free to continue to create their submissions using them. Even
so, we <strong>DISLIKE</strong> submissions that <strong>require</strong> an <strong>IDE</strong> (integrated
development environment).
</p>
<p class="leftbar">
There have been instances where winning entry code was quite different from the
<strong>original</strong> author’s input. At least one winning author cannot even use a
keyboard!
</p>
<p>We do realize that there are holes in the <a href="rules.html">rules</a>, and invite
entries to attempt to exploit them. We will award ‘<strong>Worst abuse of the
<a href="rules.html">rules</a></strong>’ or ‘<strong>Best abuse of the <a href="rules.html">rules</a></strong>’ or some
variation and then plug the hole next year.</p>
<p class="leftbar">
When we do need to plug a hole in the <a href="rules.html">IOCCC rules</a> or <a href="guidelines.html">IOCCC
guidelines</a>, we will attempt to use a very small plug, if not
smaller. Or, maybe not. :-)
</p>
<p class="leftbar">
There may be fewer than 2^7+1 reasons why these <a href="guidelines.html">IOCCC
guidelines</a> seem obfuscated.
</p>
<p class="leftbar">
Check out your program and be sure that it works. 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
of the best submissions fall down because they didn’t work.
</p>
<p class="leftbar">
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. If you do have a bug or mis-feature, you are better off
documenting it. Noting “<em>this submission sometimes prints the 4th power
of a prime by mistake</em>” would save the above submission. And sometimes,
a strange bug/(mis-)feature can even help the submission! Of course, a correctly
working submission is best. Clever people will note that 16 might be prime
under certain conditions. Wise people, when submitting something clever
will fully explain such cleverness in their submission’s <code>remarks.md</code> file.
</p>
<p>People who are considering to just use some complex mathematical
function or state machine to spell out something such as “<em>hello,
world!</em>” <strong>really really, <em>and we do mean REALLY</em>, do need to be more creative</strong>.</p>
<p>Ultra-obfuscated programs are, in some cases, easier to
deobfuscate than subtly-obfuscated programs. Consider using
misleading or subtle tricks layered on top of or under an
appropriate level of obfuscation. A clean looking program with
misleading comments and variable names might be a good start.</p>
<p class="leftbar">
When programs use VTxxx/ANSI sequences, they should <strong>NOT</strong> be limited to a
specific terminal brand. Programs that work in a standard xterm
are considered more portable.
</p>
<p>Jump to: <a href="#">top</a></p>
<div id="extra-files">
<h1 id="including-extra-files">Including extra files</h1>
<h1 id="including-optional-and-extra-files">Including optional and extra files</h1>
</div>
<p class="leftbar">
The maximum total number of files that may be submitted has changed to 39 files.
@@ -795,7 +823,13 @@ However, of those files, 5 are mandatory (<code>prog.c</code>, <code>Makefile</c
the two JSON files generated by <code>mkiocccentry(1)</code>, <code>.info.json</code> and
<code>.auth.json</code>). Additionally, three of the files in the limit <strong>MUST</strong> be
specific file(name)s: the <strong>OPTIONAL</strong> submission files, which are <code>prog.alt.c</code>,
<code>try.sh</code> and <code>try.alt.sh</code>, or else they <strong>WILL</strong> count as an extra file.
<code>try.sh</code> and <code>try.alt.sh</code>, or else they <strong>WILL</strong> count as an extra file. Of
course, if you use the optional filenames without the files being their
intended, that would be an abuse of rules.
For more details on the optional files, see the
FAQ on the “<a href="../faq.html#try_script">try.sh script system</a>”
and the
FAQ on “<a href="../faq.html#alt_code">alt code</a>”.
</p>
<p class="leftbar">
In other words, the actual amount of <strong>EXTRA</strong> files is 31.
@@ -803,19 +837,18 @@ In other words, the actual amount of <strong>EXTRA</strong> files is 31.
<p class="leftbar">
If you do need to include more files, you may do so by including as an extra
file, a tarball. This does <strong>NOT</strong> have to pass <code>txzchk(1)</code> tests; only the
submission tarball must pass the <code>txzchk(1)</code> tests.
submission tarball must pass the <code>txzchk(1)</code> tests. See the <a href="#txzchk">txzchk
section</a> for more details on this important tool.
</p>
<p class="leftbar">
If you <strong>DO</strong> include a tarball, and the build process or the program extracts
said tarball(s), the make <code>clobber</code> rule <strong>MUST</strong> remove them.
</p>
<p class="leftbar">
<p>See <a href="rules.html#rule17">Rule 17</a> and in particular the part about the <a href="rules.html#max-files">maximum
See <a href="rules.html#rule17">Rule 17</a> and in particular the part about the <a href="rules.html#max-files">maximum
number of files</a>. If you do not follow these points, you
are at a great risk of violating <a href="rules.html#rule17">Rule 17</a>!</p>
<p class="leftbar">
<p>For more details, see the
FAQ on the “<a href="../faq.html#try">try.sh script system</a>”,
the
FAQ on “<a href="../faq.html#auth_json">.auth.json</a>”,
the
FAQ on “<a href="../faq.html#info_json">.info.json</a>”,</p>
are at a great risk of violating <a href="rules.html#rule17">Rule 17</a>!
</p>
<h1 id="mkiocccentry"><code>mkiocccentry</code></h1>
<p class="leftbar">
<a href="rules.html#rule17">Rule 17</a> (the <code>mkiocccentry(1)</code> rule) states that
@@ -826,9 +859,10 @@ See the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a
for the <code>mkiocccentry(1)</code> tool and below for more details.
</p>
<p class="leftbar">
<p><strong>IMPORTANT NOTE</strong>: make <strong>CERTAIN</strong> you have the most recent version of the
<strong>IMPORTANT NOTE</strong>: make <strong>CERTAIN</strong> you have the most recent version of the
<code>mkiocccentry</code> toolkit! See the
FAQ on “<a href="../faq.html#obtaining_mkiocccentry">obtaining the mkiocccentry toolkit</a>”.</p>
FAQ on “<a href="../faq.html#obtaining_mkiocccentry">obtaining the mkiocccentry toolkit</a>”.
</p>
<p class="leftbar">
<code>mkiocccentry</code> runs a number of checks, by the tool itself and by executing
other tools, <em>before</em> packaging your xz compressed tarball. Once the tarball is
@@ -839,7 +873,7 @@ its algorithm.
If <code>mkiocccentry</code> encounters an <strong>error</strong> the program will exit and the xz
compressed tarball <strong>will not be formed</strong>. For instance, if <code>chkentry(1)</code> (see
below) fails to validate the <code>.auth.json</code> or <code>.info.json</code>
<a href="https://www.json.org/json-en.html">JSON</a> files that <code>mkiocccentry(1)</code> creates,
<a href="https://www.json.org/json-en.html">JSON</a> files (see below) that <code>mkiocccentry(1)</code> creates,
it is an error and <strong>possibly</strong> a bug that you should <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report as a bug at the
mkiocccentry bug report
page</a>.
@@ -853,11 +887,11 @@ your submission. Thus if you report an error as a bug it might not be something
that will be fixed as there might not be anything wrong with the tools.
</p>
<p class="leftbar">
On the other hand, some conditions are <strong>warnings</strong> and it allows you to
override these, if you wish. If you’re brave enough you can use the <code>-W</code> option
to ignore all warnings but this is a big risk; the <code>-y</code> option will assume
‘<em>yes</em>’ to most questions but this is also a big risk. Needless to say, we do
NOT recommend these options.
On the other hand, some conditions flagged by <code>mkiocccentry(1)</code> are <strong>warnings</strong>
and it allows you to override these, if you wish. If you’re brave enough you can
use the <code>-W</code> option to ignore all warnings but this is a big risk; the <code>-y</code>
option will assume ‘<em>yes</em>’ to most questions but this is also a big risk.
Needless to say, we do <strong>NOT</strong> recommend these options.
</p>
<p class="leftbar">
In many places it will prompt you to verify what you input, allowing you to
@@ -882,10 +916,12 @@ overwrites the file).
<p class="leftbar">
See the
FAQ on “<a href="../faq.html#mkiocccentry">mkiocccentry</a>”
for how to use this tool, in more detail.
for how to use this tool and the
FAQ on “<a href="../faq.html#mkiocccentry_details">finer details of mkiocccentry</a>”
for even more information.
</p>
<div id="tools">
<h1 id="mkiocccentry-tools">mkiocccentry tools</h1>
<h1 id="other-mkiocccentry-tools">Other mkiocccentry tools</h1>
</div>
<p class="leftbar">
The <code>mkiocccentry(1)</code> tool will execute a number of tools, some of which will
@@ -894,10 +930,11 @@ execute one or more additional tools.
<h2 id="iocccsize"><code>iocccsize</code></h2>
<p class="leftbar">
<code>mkiocccentry(1)</code> will use code from <code>iocccsize(1)</code> which
detects a number of issues that you may ignore, if you wish, as described above.
detects a number of issues that you may ignore, if you wish, as noted above.
</p>
<p class="leftbar">
In other words, you no longer need to run <code>iocccsize</code> manually.
In other words, you no longer need to run <code>iocccsize</code> manually. However, the
checks described above are still made but through <code>mkiocccentry</code> itself.
</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="chkentry"><code>chkentry</code></h2>
@@ -1003,7 +1040,7 @@ page</a>. <strong>PLEASE run the
FAQ on “<a href="../faq.html#mkiocccentry_bugs">report mkiocccentry bugs</a>”.
</p>
<p class="leftbar">
As part of its sanity checks, <code>txzchk(1)</code> will run <code>fnamchk(1)</code> on the
As part of its algorithm, <code>txzchk(1)</code> will run <code>fnamchk(1)</code> on the
<em>filename</em> to verify that the name is valid. See the
FAQ on “<a href="../faq.html#fnamchk">fnamchk</a>”
and <a href="#fnamchk">fnamchk below</a> for more details on this tool.
@@ -1038,7 +1075,7 @@ tarball filename, see the
FAQ on “<a href="../faq.html#fnamchk">fnamchk</a>”.
</p>
<p class="leftbar">
Because <code>txzchk(1)</code> tool uses <code>fnamchk(1)</code> tool as part of its algorithm,
Because <code>txzchk(1)</code> tool uses the <code>fnamchk(1)</code> tool as part of its algorithm,
<code>mkiocccentry(1)</code> does not directly invoke <code>fnamchk(1)</code>, although we will
in the judging process.
</p>
@@ -1055,7 +1092,7 @@ FAQ on “<a href="../faq.html#mkiocccentry_bugs">report mkiocccentry bugs</a>
</p>
<p class="leftbar">
As you can see, the use of <code>mkiocccentry(1)</code> is <strong>HIGHLY RECOMMENDED</strong>, and at
the risk of stating the obvious, you run <strong>a VERY BIG risk</strong> of having
the risk of stating the obvious, you run <strong>A VERY BIG RISK</strong> of having
your submission rejected if you package your own tarball, and there are <strong>ANY
problems</strong>. For instance, if <code>chkentry(1)</code> found a problem in your <code>.info.json</code>
file, the <code>mkiocccentry(1)</code> tool would not package it. But if you were to package
@@ -1086,7 +1123,7 @@ that’s OK too!
</div>
</div>
<p class="leftbar">
We <strong>recommend</strong> AND <strong>encourage</strong> you to use the example Makefile <strong>here</strong>,
We <strong>recommend</strong> AND <strong>encourage</strong> you to use the example Makefile,
as the starting point for your submission’s required <code>Makefile</code>:
</p>
<ul>
@@ -1104,7 +1141,7 @@ Feel free to modify the <code>Makefile</code> to suit your obfuscation
needs.
</p>
<p class="leftbar">
Please add a space between the <code>=</code> and the value of variables, in the
<strong>Please</strong> add a space between the <code>=</code> and the value of variables, in the
<code>Makefile</code>, making sure that the <code>=</code> comes immediately after the name. See the
example <code>Makefile</code> for examples.
</p>
@@ -1247,7 +1284,7 @@ obfuscated code and even in some non-obfuscated code, and you should not worry
about this, though it might be worth pointing out.
</p>
<p class="leftbar">
For instance, some compilers like to warn about use of <code>char *</code>s, which seems to
For instance, some compilers like to warn about use of pointers as arrays, which seems to
be dubious, as it obviously can’t (always) be avoided, being a big part of C, so
you should not worry about this either; this is the warning
<code>-Wunsafe-buffer-usage</code> and the way to disable it is <code>-Wno-unsafe-buffer-usage</code>.
@@ -1339,7 +1376,7 @@ only things that should be in the directory after running <code>make clobber</co
is in your submission tarball itself.
</p>
<p class="leftbar">
While people are free to mange their submission under <code>git(1)</code> or even use a
While people are free to manage their submission under <code>git(1)</code> or even use a
GitHub repo, dot-files and dot-directories such as <code>.git</code> are not allowed in a
submission.
</p>
@@ -1351,11 +1388,11 @@ directories to help develop your submission, they won’t be included when you r
the <code>mkiocccentry(1)</code> tool.
</p>
<p class="leftbar">
Even if you did manage to get it into the tarball somehow, <code>txzchk(1)</code> will
flag it as an error. When the judges run <code>txzchk(1)</code> on the uploaded submission
compressed tarball, if anything is wrong, for instance if you “sneak in” any
dot files or dot directories, the submission <strong>WILL BE REJECTED</strong> for violating
<a href="rules.html#rule17">Rule 17</a>!
Even if you did manage to get dot files or dot directories in the tarball
somehow, <code>txzchk(1)</code> will flag it as an error. When the judges run <code>txzchk(1)</code>
on the uploaded submission compressed tarball, if anything is wrong, for
instance if you “sneak in” any dot files or dot directories, the submission
<strong>WILL BE REJECTED</strong> for violating <a href="rules.html#rule17">Rule 17</a>!
</p>
<p class="leftbar">
You may use whatever tools you need to develop your submission, including the
@@ -1376,7 +1413,8 @@ In other words, for <code>make clobber</code>, do something like:
<pre><code> clobber:
${RM} -f foo bar baz</code></pre>
<p>and <strong>NOT</strong> something like this:</p>
<pre><code> clobber:
<pre><code> # do NOT do this!
clobber:
-git clean -f</code></pre>
<p class="leftbar">
And do <strong>NOT</strong> use <code>git</code> for any other tool either.
@@ -1430,8 +1468,7 @@ FAQ on “<a href="../faq.html#try_scripts">submitting try.sh and try.alt.sh scr
</p>
<p class="leftbar">
You might wish to add <code>./try.sh</code> to the <code>try</code> rule in the Makefile you submit.
If you have alternate code, then you could add a <code>try.alt</code> rule or something
like that.
If you have alternate code, then you can use the <code>try.alt</code> rule instead.
</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
@@ -1470,7 +1507,7 @@ of nested functions such as:</p>
}</code></pre>
<p>On 2012 July 20, the <a href="../judges.html">judges</a> rescinded the encouragement of
nested functions. Such constructions, while interesting and sometimes
amusing, will have to wait until they required by a C standard that are
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 class="leftbar">
We <strong>DISLIKE</strong> submissions that require the use of <code>-fnested-functions</code>.
@@ -1601,18 +1638,22 @@ 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">judges</a>, as a group, have a history giving wide degree of latitude
to reasonable entries. And recently they have had as much longitudinal
variation as it is possible to have on <a href="https://science.nasa.gov/earth/">Earth</a>. :-)</p>
<p class="leftbar">
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>.
The <a href="../judges.html">judges</a>, as a group, have a history giving wide degree of latitude
to reasonable submissions. And recently they have had as much longitudinal
variation as it is possible to have on <a href="https://science.nasa.gov/earth/">Earth</a>. :-)
</p>
<p class="leftbar">
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 class="leftbar">
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 if your
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
@@ -1654,13 +1695,15 @@ We think we did. :-)</p>
<blockquote>
<p>All generalizations are false, including this one. – <strong>Mark Twain</strong></p>
</blockquote>
<p>Given two versions of the same program, one that is a compact blob
<p class="leftbar">
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#rule9">Rule 9</a>).</p>
rules</a> for details (in particular, <a href="rules.html#rule9">Rule 9</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>
@@ -1668,7 +1711,7 @@ source. The smallest, a <a href="../1994/smr/index.html">zero byte entry</a>, wo
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 NOT the smallest C source file that when compiled and run, dumps core:</p>
is <strong>NOT</strong> the smallest C source file that when compiled and run, dumps core:</p>
<pre><code> main;</code></pre>
<p class="leftbar">
Unless you specify <code>-fwritable-strings</code> (see <code>COTHER</code> in the example
@@ -1700,6 +1743,12 @@ 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 entries should avoid using X related libraries and
software that are not in wide spread use.</p>
<p class="leftbar">
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.
</p>
<p>This is 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 class="leftbar">
@@ -1810,23 +1859,25 @@ into creating a dense blob. Such are the trade-offs that obfuscators face!</p>
<p class="leftbar">
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.
some Intel-like x86 architecture**.
</p>
<p>We believe that Mark Twain’s quote:</p>
<blockquote>
<p>Get your facts first, then you can distort them as you please.</p>
</blockquote>
<p>… is a good motto for those writing code for the IOCCC.</p>
<p>The IOCCC size tool source is not an original work, unless you are <a href="../authors.html#Anthony_C_Howe">Anthony C
<p class="leftbar">
The IOCCC size tool source is not an original work, unless you are <a href="../authors.html#Anthony_C_Howe">Anthony C
Howe</a>, in which case it is original! :-)
Submitting source that uses the content of
Submitting source code that uses the content of
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">iocccsize.c</a>, unless you are
<a href="../authors.html#Anthony_C_Howe">Anthony C Howe</a>, might run the risk of
violating <a href="rules.html#rule7">Rule 7</a>.</p>
violating <a href="rules.html#rule7">Rule 7</a>.
</p>
<p class="leftbar">
The <code>txzchk(1)</code> tool source is not an original work,
unless you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone Ferguson</a>, in
which case it is original! :-) Submitting source that uses the content of
which case it is original! :-) Submitting source code that uses the contents of
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c">txzchk.c</a>,
unless you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone Ferguson</a>, might
run the risk of violating <a href="rules.html#rule7">Rule 7</a>.
@@ -1843,11 +1894,11 @@ nor
nor any of the other <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse">jparse
tools</a>
(see the <a href="https://github.com/xexyl/jparse/">jparse repo</a>), nor the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/test_ioccc/fnamchk.c">fnamchk tool
source</a>
source</a>,
are original works,
unless you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone Ferguson</a> or
<a href="http://www.isthe.com/chongo/index.html">Landon Curt Noll</a>, in which case they
are original! :-) Submitting source that uses the code of these tools or
are original! :-) Submitting source code that uses the code of any of these tools or
library, unless you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone
Ferguson</a> or <a href="http://www.isthe.com/chongo/index.html">Landon Curt
Noll</a>, might run the risk of violating
@@ -1856,7 +1907,7 @@ Noll</a>, might run the risk of violating
<p class="leftbar">
Unless you are <a href="http://www.isthe.com/chongo/index.html">Landon Curt Noll</a>, the
remaining tools in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>
are <strong>NOT</strong> original works. Submitting source that uses the content of those tools,
are <strong>NOT</strong> original works. Submitting source code that uses the content of those tools,
unless you are <a href="http://www.isthe.com/chongo/index.html">Landon Curt Noll</a>, might
run the risk of violating <a href="rules.html#rule7">Rule 7</a>.
</p>
@@ -1887,7 +1938,7 @@ as obfuscated as the lexer/parser of
<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 class="leftbar">
If <a href="../judges.html">IOCCC judges</a> are feeling ornery we
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 :-)
@@ -1927,7 +1978,9 @@ produce unpredictable results.</p>
<code>2305567963945518424753102147331756070</code>. Attempting to factor values outside
that range will produce unpredictable results.</p>
</blockquote>
<p>Moreover the might try to also factor 3.5 or 0x7, or Fred, so you want to might state:</p>
<p class="leftbar">
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
@@ -1971,7 +2024,7 @@ rendering your markdown content.
</p>
<p class="leftbar">
If you do use ASCII tab characters in your non-markdown files, be
aware that some people may use tab stop that is different than the common 8
aware that some people may use a tab stop that is different than the common 8
character tab stop.
</p>
<p class="leftbar">
@@ -2024,40 +2077,49 @@ submitting an alternate version that conforms to the
If you do bypass the <code>mkiocccentry(1)</code> warnings about <a href="rules.html#rule2a">Rule
2a</a> and/or about <a href="rules.html#rule2b">Rule 2b</a>
and submit a submission anyway, you <strong>MUST</strong> try to justify why the IOCCC
<a href="../judges.html">judges</a> should not reject your submission due to a rule violation.
<a href="../judges.html">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>Abusing the web submission procedure tends to annoy us more
than amuse us. Spend your creative energy on content of your
submission rather than on the submission process itself.</p>
<p>We are often asked why the contest <a href="rules.html">IOCCC rules</a> and
<p class="leftbar">
We are often asked why the contest <a href="rules.html">IOCCC rules</a> and
<a href="guidelines.html">IOCCC guidelines</a> seem too
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. 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 may continue. A clever author
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
the <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</a>.
</p>
<p class="leftbar">
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 a small part of the overall contest. Even so, one may think the
are only a small 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 specifications and requirements from marketing, sales,
product management an even from customers themselves on a all too regular basis.
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>
<a href="guidelines.html">IOCCC guidelines</a> are written in obfuscated form.
</p>
<p>Jump to: <a href="#">top</a></p>
<div id="judging">
<h1 id="judging-process">JUDGING PROCESS:</h1>
</div>
<p>Entries are judged by Leonid A. Broukhis and Landon Curt Noll.</p>
<p>Each submission submitted is given a random id number and subdirectory. The
<p class="leftbar">
Each submission submitted is given a random id number and subdirectory. The
submission files including, but not limited to <code>prog.c</code>, <code>Makefile</code>,
<code>remarks.md</code> as well as any data files that you submit, are all placed under
their own directory and stored and judged from this directory.</p>
<code>remarks.md</code>, <code>.info.json</code>, <code>.auth.json</code> as well as any data files that you
submit, are all placed under their own directory and stored and judged from this
directory.
</p>
<p>Any information about the authors is not read by the <a href="../judges.html">judges</a> until
the judging process is complete, and then only from entries that have
won an award. Because we do not read this information for entries that
@@ -2065,9 +2127,11 @@ do not win, we do not know who did not win.</p>
<p>The above process helps keep us biased for/against any one particular
individual. Therefore you <strong>MUST</strong> refrain from putting any information
that reveals your identity in your submission.</p>
<p>Now some people point out that coding style might reveal the information
about the others. However we consider this to be simply circumstantial
and outside the scope of the above paragraph.</p>
<p class="leftbar">
Now some people point out that coding and/or writing style might reveal the
information about the authors. However we consider this to be simply
circumstantial and outside the scope of the above paragraph.
</p>
<p>Some people, in the past, have attempted to obfuscate their identity by
including comments of famous Internet personalities such as <a href="http://www.citi.umich.edu/u/honey">Peter
Honeyman</a>. The <a href="../judges.html">judges</a> are on to this trick
@@ -2120,9 +2184,11 @@ previous round. Thus, a submission gets at least two readings.</p>
<p>A reading consists of a number of actions:</p>
<ul>
<li><p class="leftbar">
reading <code>prog.c</code>, the C source, reviewing the <code>remarks.md</code> information
reading <code>prog.c</code>, the C source and reviewing the <code>remarks.md</code> information
</p></li>
<li><p class="leftbar">
briefly looking at any supplied data files
</p></li>
<li>briefly looking any any supplied data files</li>
<li>passing the source thru the C pre-processor
skipping over any <code>#include</code>d files</li>
<li>performing a number of C beautify/cleanup edits on the source</li>
@@ -2153,7 +2219,11 @@ we receive. A typical category list might be:</p>
<li><strong>best game that is obfuscated</strong></li>
<li><strong>most creatively obfuscated program</strong></li>
<li><strong>most deceptive C code</strong> (code with deceptive comments and source code)</li>
<li><strong>best X program</strong> (see <a href="#likes">OUR LIKES AND DISLIKES</a>)</li>
<li><p class="leftbar">
<strong>best X program</strong> (see <a href="#likes">OUR LIKES AND DISLIKES</a>
and the
FAQ on “<a href="../faq.html#Xorg_deprecated">Xorg being deprecated</a>”)
</p></li>
<li><strong>best abuse of ISO C or ANSI C standard</strong> (see above about compilers)</li>
<li><strong>best abuse of the C preprocessor</strong></li>
<li><strong>worst/best abuse of the rules</strong> (or some variation)</li>
@@ -2202,7 +2272,7 @@ It has been shown that receiving <strong>anonymous</strong> gifts provides the
</p>
<p class="leftbar">
See the
FAQ on “<a href="../faq.html#support">support the IOCCC</a>”.
FAQ on “<a href="../faq.html#support">supporting the IOCCC</a>”.
</p>
<p>More often than not, we select a small submission (usually one line) and a
strange/creative layout submission. We sometimes also select a
@@ -2224,7 +2294,7 @@ Winning source is called <code>prog.c</code>. A compiled binary is called <code>
</div>
<p class="leftbar">
The <a href="../judges.html">judges</a> will toot initial announcement of who won, the name
of their award, and a very brief description of the winning entry
of their award, and a very brief description (award title) of the winning entry
from the <a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> Mastodon account</a>.
</p>
<p class="leftbar">
@@ -2282,10 +2352,13 @@ It is pointless to ask the <a href="../judges.html">IOCCC judges</a> how many
submissions we receive. See <a href="../faq.html#how_many">How many submissions do the judges receive for a
given IOCCC?</a>.
</p>
<p>Often, winning entries are published in selected magazines from around the
<p class="leftbar">
Often, winning entries are published in selected magazines from around the
world. Winners have appeared in books (‘<code>The New Hacker's Dictionary</code>’,
‘<code>Obfuscated C and Other Mysteries</code>’, ‘<code>Pointers On C</code>’, others) and on t-shirts.
More than one winner has been turned into a tattoo!</p>
‘<code>Obfuscated C and Other Mysteries</code>’, ‘<code>Pointers On C</code>’, others) and on t-shirts
(sometimes by the author(s) themselves). More than one winner has been turned
into a tattoo!
</p>
<p>Last, but not least, <a href="../authors.html">winners</a> receive international fame and flames! :-)</p>
<p>Jump to: <a href="#">top</a></p>
<div id="more-information">
next/guidelines.md
+302 -230
View File
@@ -90,9 +90,9 @@ about them. The [IOCCC guidelines](guidelines.html) should be viewed as
allowed_. Even so, you are safer if you remain within the [IOCCC
guidelines](guidelines.html).
**You should read the current [IOCCC rules](rules.html), prior to submitting
entries**. The [rules](rules.html) are typically published along with the [IOCCC
guidelines](guidelines.html)..
You **SHOULD read the CURRENT [IOCCC rules](rules.html)**, _prior_ to submitting
code to the contest. The [rules](rules.html) are typically published along with
the [IOCCC guidelines](guidelines.html).
Jump to: [top](#)
@@ -119,7 +119,7 @@ This contest will enter the **[judging](../status.html#judging)** state on **202
<p class="leftbar">
**IMPORTANT NOTE**: Until the content enters the **[open](../status.html#open)** state, any or all
of the above **dates and times may change**!
of the above **dates and times may change _AT ANY TIME_**!
</p>
<p class="leftbar">
@@ -131,13 +131,13 @@ to be a **fun**ctional UTC time. :-)
Until the contest status becomes **[open](../status.html#open)**,
the [IOCCC rules](rules.html),
[IOCCC guidelines](guidelines.html) and the tools in the
[mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry), should be
considered provisional **BETA** versions and **may be adjusted _AT ANY TIME_**
[mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry), **SHOULD be
considered** provisional **BETA** versions and **may be adjusted _AT ANY TIME_**
before the contest status becomes **[open](../status.html#open)**.
</p>
<p class="leftbar">
You **MUST** [register](register.html) in order to submit your entry to the IOCCC.
You **MUST** [register](register.html) in order to participate in the IOCCC.
You may [register](register.html) while the contest is either
**[pending](../status.html#pending)** or **[open](../status.html#open)**.
</p>
@@ -145,103 +145,66 @@ You may [register](register.html) while the contest is either
<p class="leftbar">
See the
FAQ on "[how to register and submit to the IOCCC](../quick-start.html#enter)"
for instructions on registering and participating in the IOCCC, as the process has changed from previous years!
for instructions on registering and participating in the IOCCC, as the process
has changed from previous years!
</p>
<p class="leftbar">
When the contest is **[open](../status.html#open)**, an
[IOCCC judge](../judges.html) will email you your [submit server](https://submit.ioccc.org)
**Username** and **Initial password**. This takes some time (maybe even a few days) for an
[IOCCC judge](../judges.html) to process your registration and email you your
initial login and password.
When the contest is **[open](../status.html#open)**, an [IOCCC
judge](../judges.html) will email you your [submit
server](https://submit.ioccc.org) **Username** and **Initial password**. This
takes some time (maybe even a few days) for an [IOCCC judge](../judges.html) to
process your registration and email you your initial login and password, so be
sure to give yourself enough time.
</p>
<p class="leftbar">
Those who [register](register.html) while the contest status is **[pending](../status.html#pending)**
will receive email with their [submit server](https://submit.ioccc.org) **Username** and **Initial password**
from an [IOCCC judge](../judges.html) shortly after the contest status becomes **[open](../status.html#open)**.
Those who [register](register.html) while the contest status is
**[pending](../status.html#pending)** will receive email with their [submit
server](https://submit.ioccc.org) **Username** and **Initial password** from an
[IOCCC judge](../judges.html) shortly after the contest status becomes
**[open](../status.html#open)**.
</p>
<p class="leftbar">
Once an [IOCCC judge](../judges.html) emails you your **Username** and **Initial password**, you
will have 72 hours to [change your submit server initial password](pw-change.html).
If you do not change your **Initial password** in time, you will have to [re-register](register.html).
If you do not change your **Initial password** in time, you will have to
[re-register](register.html). You may **NOT** upload any submission until you
have changed your **Initial password** and logged back in!
</p>
<p class="leftbar">
Because it takes time (maybe even a few days) for an [IOCCC judge](../judges.html)
to process your registration and email you your initial login and password,
you should **MAKE SURE** you give yourself enough time before the contest closes.
you should **MAKE SURE** to give yourself enough time before the contest closes.
In other words, **DO NOT WAIT TO REGISTER UNTIL THE FINAL DAYS**!
The [IOCCC judges](../judges.html) are **NOT** responsible for delayed or lost email,
or for those who wait until the last minute to try to register!
</p>
<p class="leftbar">
For those who have [registered](register.html) and received by email, their
Once you have [registered](register.html), and received by email, your
[submit server](https://submit.ioccc.org) **Username** and **Initial password**
from an [IOCCC judge](../judges.html), you may upload your submission to
the [submit server](https://submit.ioccc.org) only while the
contest **[open](../status.html#open)**.
from an [IOCCC judge](../judges.html), you may, after [changing your initial
password](pw-change.html) upload your submission to
the [submit server](https://submit.ioccc.org), as long as the contest
**[open](../status.html#open)**.
</p>
<p class="leftbar">
The [submit server](https://submit.ioccc.org) will become active when the
contest is **[pending](../status.html#pending)**.
Until the contest status becomes **[pending](../status.html#pending)**,
the [submit server](https://submit.ioccc.org) might be offline and/or unresponsive.
</p>
<p class="leftbar">
The [submit server](https://submit.ioccc.org), in accordance with [Rule 17](rules.html#rule17),
places a limit of **3999971** octets on the size of your upload.
</p>
<p class="leftbar">
You are **STRONGLY** advised to use the `mkiocccentry(1)` tool
as found in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
to form the file to upload to the [submit server](https://submit.ioccc.org).
</p>
<p class="leftbar">
See the
FAQ on "[obtaining and compiling the mkiocccentry tools](../faq.html#mkiocccentry)"
for more information about the `mkiocccentry(1)` tool.
</p>
<p class="leftbar">
While the contest is **[open](../status.html#open)**, you may modify your previously
uploaded submission by rebuilding your submission with the `mkiocccentry(1)` tool
and then re-uploading it to the same slot number on the [submit server](https://submit.ioccc.org).
</p>
<p class="leftbar">
To help you with this, so that you do not have to repeatedly answer all the
questions, the `mkiocccentry(1)` tool has the options `-a answers`, `-A answers`
and `-i answers`, where `-a` will write to an answers file if it does not
already exist, `-A` will overwrite the file and `-i` will read the answers from
the file.
</p>
<p class="leftbar">
Once the contest enters the **[judging](../status.html#judging)** state, you will
**NOT** be allowed to upload your submission files.
</p>
<p class="leftbar">
The [submit server](https://submit.ioccc.org) will become active when the contest is **[open](../status.html#open)**.
Until the contest status becomes **[open](../status.html#open)**,
the [submit server](https://submit.ioccc.org) may be offline and/or unresponsive.
</p>
<p class="leftbar">
The [Rule 2a](rules.html#rule2a) size has **increased from 4096 to 4993** bytes.
</p>
<p class="leftbar">
The [Rule 2b](rules.html#rule2b) size has **increased from 2053 to 2503**
bytes.
</p>
<p class="leftbar">The new default way to compile submissions: `-std=gnu17 -O3 -g3
-Wall -Wextra -pedantic`.
You **are encouraged** to use the example Makefile here. For more details and help,
see below in the [Makefile section](#makefile).
</p>
<p class="leftbar">
Submissions are uploaded as a single xz compressed tarball.
</p>
@@ -251,11 +214,6 @@ To assist in the formation of the xz compressed tarball for submission, use the
`mkiocccentry(1)` tool as found in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
</p>
<p class="leftbar">
[Rule 17](rules.html#rule17) has been **significantly modified**
to account for the new [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) tools.
</p>
<p class="leftbar">
If you wish to test that your submission passes the `mkiocccentry(1)` tests
without having to put in answers each time, you can use the `-d` or `-s seed`
@@ -273,18 +231,136 @@ that if the directory exists already, you will have to remove it or move it
before this option will work a second time, just like in normal mode.
</p>
<p class="leftbar">
[Rule 17](rules.html#rule17) has been **significantly modified**
to account for the new [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) tools.
Thus, you are **STRONGLY** advised to use the `mkiocccentry(1)` tool
as found in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
to form the file to upload to the [submit server](https://submit.ioccc.org). Not
doing so puts you at a very big risk of violating [Rule 17](rules.html#rule17).
</p>
<p class="leftbar">
See the
FAQ on "[obtaining and compiling the mkiocccentry tools](../faq.html#mkiocccentry)"
FAQ on "[obtaining and compiling the most recent mkiocccentry tools](../faq.html#mkiocccentry)"
and the
FAQ on "[how to enter the IOCCC](../quick-start.html#enter)"
as that FAQ has import details on
as that FAQ has important details on
[how to register](register.html)
as well as
[how to upload your submission](submit.html) to the IOCCC.
</p>
<p class="leftbar">
While the contest is **[open](../status.html#open)**, you may modify your
previously uploaded submission by rebuilding your submission with the
`mkiocccentry(1)` tool and then re-uploading it to **the same slot number** on the
[submit server](https://submit.ioccc.org).
</p>
<p class="leftbar">
To help you with this, so that you do not have to repeatedly answer all the
questions, the `mkiocccentry(1)` tool has the options `-a answers`, `-A answers`
and `-i answers`, where `-a` will write to an answers file (if it does not
already exist), `-A` will overwrite the file and `-i` will read the answers from
the file. If you use `-A`, be sure you don't overwrite another file by accident!
</p>
<p class="leftbar">
Once the contest enters the **[judging](../status.html#judging)** state, you will
**NOT** be allowed to upload your submission files, so do give yourself enough
time.
</p>
<p class="leftbar">
[Rule 2](rules.html#rule2) (the size rule) refers to the use of the IOCCC size
tool called `iocccsize(1)`.
</p>
<p class="leftbar">See the [mkiocccentry
repo](https://github.com/ioccc-src/mkiocccentry) for the `iocccsize(1)` tool.
</p>
<p class="leftbar">
To further clarify [Rule 2](rules.html#rule2), we subdivided it into two parts,
**2a** and **2b**.
</p>
<p class="leftbar">
The overall size limit (see [Rule 2a](rules.html#rule2a)) on `prog.c` has been
**increased from 4096 to 4993** bytes.
</p>
<p class="leftbar">
The [Rule 2a](rules.html#rule2a) size was changed from
4096 to 4993: a change that keeps the "2b to 2a" size ratio to a
value similar to the [2001-2012](../faq.html#size_rule2001-2012) and
[2013-2020](../faq.html#size_rule2013-2020) IOCCC eras.
</p>
<p class="leftbar">
The [Rule 2b](rules.html#rule2b) size has **increased from 2053 to 2503**
bytes.
</p>
<p class="leftbar">
Your submission must satisfy **BOTH** the maximum size [Rule
2a](rules.html#rule2a) **AND** the IOCCC size tool [Rule 2b](rules.html#rule2b).
</p>
<p class="leftbar">
The IOCCC size tool imposes a 2nd limit on C code size (see [Rule
2a](rules.html#rule2a)). To check your code against [Rule 2](rules.html#rule2):
</p>
``` <!---sh-->
iocccsize prog.c
```
<p class="leftbar">
The IOCCC size tool algorithm can be summarized as follows:
</p>
> The size tool counts most C reserved words (keyword, secondary, and selected
preprocessor keywords) as 1. The size tool counts all other octets as 1
excluding ASCII whitespace, and excluding any '`;`', '`{`' or '`}`' followed by
ASCII whitespace, and excluding any '`;`', '`{`' or '`}`' octet immediately
before the end of file.
ASCII whitespace includes ASCII tab, ASCII space, ASCII newline,
ASCII formfeed, and ASCII carriage return.
<p class="leftbar">
When '`;`', '`{`' or '`}`' are within a C string, they may still not be
counted by the IOCCC size tool. This is a _feature_, not a bug!
</p>
In cases where the above summary and the algorithm implemented by
the IOCCC size tool source code conflict, the algorithm implemented
by the IOCCC size tool source code is preferred by the [judges](../judges.html).
<p class="leftbar">
In other words, make sure `iocccsize` does not flag any issues with your
`prog.c`.
</p>
<p class="leftbar">
There are at least 2 other reasons for selecting 2503 as the 2nd limit besides
the fact that 2503 is a prime. These reasons may be searched for and discovered
if you are ["Curios!" about 2503](https://t5k.org/curios/page.php/2503.html).
:-) Moreover, 2053 was the number of the kernel disk pack of one of the judge's
BESM-6, and 2503 is a decimal anagram of 2053.
</p>
Take note that this secondary limit imposed by the IOCCC size tool
obviates some of the need to `#define` C reserved words in an effort
to get around the size limits of [Rule 2](rules.html#rule2).
Yes Virginia, **that is a hint**!
Jump to: [top](#)
@@ -295,7 +371,7 @@ Jump to: [top](#)
</div>
</div>
You are encouraged to examine the [winners of previous contests](../years.html).
You are **encouraged** to examine the [winners of previous contests](../years.html).
Keep in mind that [rules](rules.html) change from year to year, so some [winning
entries](../years.html) might not be valid submissions this year; what _was_ unique
@@ -305,7 +381,7 @@ A submission is usually examined in a number of ways. We typically apply
a number of tests to a submission:
* look at the original source
* convert ANSI trigraphs to ASCII
* <p class="leftbar">convert ANSI trigraphs and digraphs to normal C</p>
* C pre-process the source ignoring `#include` lines
* C pre-process the source ignoring `#define` _and_ `#include` lines
* run it through a C beautifier
@@ -322,7 +398,7 @@ cases, a test is not important. Entries that compete for the
'**strangest/most creative source layout**' need not do as well as
others in terms of their algorithm. On the other hand, given
two such entries, we are more inclined to pick the submission that
does something interesting when you run it.
does something interesting when it's executed.
We try to avoid limiting creativity in our [rules](rules.html). As such, we
leave the contest open for creative rule interpretation. As in [real
@@ -332,6 +408,28 @@ often award '**Best abuse of the [rules](rules.html)**' or '**Worst abuse of the
[rules](rules.html)**' or some variation to a submission that illustrates this
point in an ironic way.
<p class="leftbar">
Although we are in an age where AI/LLM can create code, we don't want to stop
anyone from using any tools they like when they're working on their submissions.
</p>
<p class="leftbar">
The IOCCC has a rich history of remarkable winning entries created by authors
who skillfully employed various code-related techniques such as code generators,
code analysis tools, machine learning tools, natural language models, code
copilot tools, and integrated development environments. Although it is **NOT**
required to use these kinds of tools in order to compile or run a submission,
individuals are free to continue to create their submissions using them. Even
so, we **DISLIKE** submissions that **require** an **IDE** (integrated
development environment).
</p>
<p class="leftbar">
There have been instances where winning entry code was quite different from the
**original** author’s input. At least one winning author cannot even use a
keyboard!
</p>
We do realize that there are holes in the [rules](rules.html), and invite
entries to attempt to exploit them. We will award '**Worst abuse of the
[rules](rules.html)**' or '**Best abuse of the [rules](rules.html)**' or some
@@ -348,21 +446,24 @@ There may be fewer than 2^7+1 reasons why these [IOCCC
guidelines](guidelines.html) seem obfuscated.
</p>
<p class="leftbar">
Check out your program and be sure that it works. We sometimes make
the effort to debug a submission that has a slight problem, particularly
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
of the best entries fall down because they didn't work.
of the best submissions fall down because they didn't work.
</p>
<p class="leftbar">
We tend to look down on a [prime
number](https://en.wikipedia.org/wiki/Prime_number) printer that claims that
16 is a prime number. If you do have a bug, you are better off
16 is a prime number. If you do have a bug or mis-feature, you are better off
documenting it. Noting "_this submission sometimes prints the 4th power
of a prime by mistake_" would save the above submission. And sometimes,
a strange bug/feature can even help the submission! Of course, a correctly
a strange bug/(mis-)feature can even help the submission! Of course, a correctly
working submission is best. Clever people will note that 16 might be prime
under certain conditions. Wise people, when submitting something clever
will fully explain such cleverness in their submission's `remarks.md` file.</p>
will fully explain such cleverness in their submission's `remarks.md` file.
</p>
People who are considering to just use some complex mathematical
function or state machine to spell out something such as "_hello,
@@ -374,86 +475,16 @@ misleading or subtle tricks layered on top of or under an
appropriate level of obfuscation. A clean looking program with
misleading comments and variable names might be a good start.
When programs use VTxxx/ANSI sequences, they should NOT be limited to a
specific terminal brand. Those programs that work in a standard xterm
<p class="leftbar">
When programs use VTxxx/ANSI sequences, they should **NOT** be limited to a
specific terminal brand. Programs that work in a standard xterm
are considered more portable.
<p class="leftbar">
[Rule 2](rules.html#rule2) (the size rule) refers to the use of the IOCCC size
tool called `iocccsize(1)`.
</p>
<p class="leftbar">See the [mkiocccentry
repo](https://github.com/ioccc-src/mkiocccentry) for the `iocccsize(1)` tool.
</p>
<p class="leftbar">
To further clarify [Rule 2](rules.html#rule2), we subdivided it into two parts,
**2a** and **2b**.
</p>
<p class="leftbar">
The overall size limit (see [Rule 2a](rules.html#rule2a)) on `prog.c` is now **4993 bytes**.
</p>
<p class="leftbar">
Your submission must satisfy BOTH the maximum size [Rule
2a](rules.html#rule2a) **AND** the IOCCC size tool [Rule 2b](rules.html#rule2b).
</p>
<p class="leftbar">
This IOCCC size tool imposes a 2nd limit on C code size (see [Rule
2a](rules.html#rule2a)). To check your code against [Rule 2](rules.html#rule2):
</p>
``` <!---sh-->
iocccsize prog.c
```
The IOCCC size tool algorithm may be summarized as follows:
> The size tool counts most C reserved words (keyword, secondary, and selected
preprocessor keywords) as 1. The size tool counts all other octets as 1
excluding ASCII whitespace, and excluding any '`;`', '`{`' or '`}`' followed by
ASCII whitespace, and excluding any '`;`', '`{`' or '`}`' octet immediately
before the end of file.
ASCII whitespace includes ASCII tab, ASCII space, ASCII newline,
ASCII formfeed, and ASCII carriage return.
<p class="leftbar">
When '`;`', '`{`' or '`}`' are within a C string, they may still not be
counted by the IOCCC size tool. This is a _feature_, not a bug!</p>
In cases where the above summary and the algorithm implemented by
the IOCCC size tool source code conflict, the algorithm implemented
by the IOCCC size tool source code is preferred by the [judges](../judges.html).
<p class="leftbar">
There are at least 2 other reasons for selecting 2503 as the 2nd limit besides
the fact that 2503 is a prime. These reasons may be searched for and discovered
if you are ["Curios!" about 2503](https://t5k.org/curios/page.php/2503.html).
:-) Moreover, 2053 was the number of the kernel disk pack of one of the judge's
BESM-6, and 2503 is a decimal anagram of 2053.
</p>
Take note that this secondary limit imposed by the IOCCC size tool
obviates some of the need to `#define` C reserved words in an effort
to get around the size limits of [Rule 2](rules.html#rule2).
Yes Virginia, **that is a hint**!
<p class="leftbar">
The [Rule 2a](rules.html#rule2a) size was changed from
4096 to 4993: a change that keeps the "2b to 2a" size ratio to a
value similar to the [2001-2012](../faq.html#size_rule2001-2012) and
[2013-2020](../faq.html#size_rule2013-2020) IOCCC eras.
</p>
Jump to: [top](#)
<div id="extra-files">
# Including extra files
# Including optional and extra files
</div>
<p class="leftbar">
@@ -462,7 +493,13 @@ However, of those files, 5 are mandatory (`prog.c`, `Makefile`, `remarks.md` and
the two JSON files generated by `mkiocccentry(1)`, `.info.json` and
`.auth.json`). Additionally, three of the files in the limit **MUST** be
specific file(name)s: the **OPTIONAL** submission files, which are `prog.alt.c`,
`try.sh` and `try.alt.sh`, or else they **WILL** count as an extra file.
`try.sh` and `try.alt.sh`, or else they **WILL** count as an extra file. Of
course, if you use the optional filenames without the files being their
intended, that would be an abuse of rules.
For more details on the optional files, see the
FAQ on the "[try.sh script system](../faq.html#try_script)"
and the
FAQ on "[alt code](../faq.html#alt_code)".
</p>
<p class="leftbar">
@@ -472,21 +509,20 @@ In other words, the actual amount of **EXTRA** files is 31.
<p class="leftbar">
If you do need to include more files, you may do so by including as an extra
file, a tarball. This does **NOT** have to pass `txzchk(1)` tests; only the
submission tarball must pass the `txzchk(1)` tests.
submission tarball must pass the `txzchk(1)` tests. See the [txzchk
section](#txzchk) for more details on this important tool.
</p>
<p class="leftbar">
If you **DO** include a tarball, and the build process or the program extracts
said tarball(s), the make `clobber` rule **MUST** remove them.
</p>
<p class="leftbar">
See [Rule 17](rules.html#rule17) and in particular the part about the [maximum
number of files](rules.html#max-files). If you do not follow these points, you
are at a great risk of violating [Rule 17](rules.html#rule17)!
<p class="leftbar">
For more details, see the
FAQ on the "[try.sh script system](../faq.html#try)",
the
FAQ on "[.auth.json](../faq.html#auth_json)",
the
FAQ on "[.info.json](../faq.html#info_json)",
</p>
<div id="mkiocccentry">
@@ -507,6 +543,7 @@ for the `mkiocccentry(1)` tool and below for more details.
**IMPORTANT NOTE**: make **CERTAIN** you have the most recent version of the
`mkiocccentry` toolkit! See the
FAQ on "[obtaining the mkiocccentry toolkit](../faq.html#obtaining_mkiocccentry)".
</p>
<p class="leftbar">
`mkiocccentry` runs a number of checks, by the tool itself and by executing
@@ -519,7 +556,7 @@ its algorithm.
If `mkiocccentry` encounters an **error** the program will exit and the xz
compressed tarball **will not be formed**. For instance, if `chkentry(1)` (see
below) fails to validate the `.auth.json` or `.info.json`
[JSON](https://www.json.org/json-en.html) files that `mkiocccentry(1)` creates,
[JSON](https://www.json.org/json-en.html) files (see below) that `mkiocccentry(1)` creates,
it is an error and **possibly** a bug that you should [report as a bug at the
mkiocccentry bug report
page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E).
@@ -535,11 +572,11 @@ that will be fixed as there might not be anything wrong with the tools.
</p>
<p class="leftbar">
On the other hand, some conditions are **warnings** and it allows you to
override these, if you wish. If you're brave enough you can use the `-W` option
to ignore all warnings but this is a big risk; the `-y` option will assume
'_yes_' to most questions but this is also a big risk. Needless to say, we do
NOT recommend these options.
On the other hand, some conditions flagged by `mkiocccentry(1)` are **warnings**
and it allows you to override these, if you wish. If you're brave enough you can
use the `-W` option to ignore all warnings but this is a big risk; the `-y`
option will assume '_yes_' to most questions but this is also a big risk.
Needless to say, we do **NOT** recommend these options.
</p>
<p class="leftbar">
@@ -548,7 +585,6 @@ correct details as you go along.
</p>
Jump to: [top](#)
<div id="mkiocccentry-synopsis">
@@ -575,12 +611,14 @@ overwrites the file).
<p class="leftbar">
See the
FAQ on "[mkiocccentry](../faq.html#mkiocccentry)"
for how to use this tool, in more detail.
for how to use this tool and the
FAQ on "[finer details of mkiocccentry](../faq.html#mkiocccentry_details)"
for even more information.
</p>
<div id="tools">
# mkiocccentry tools
# Other mkiocccentry tools
</div>
<p class="leftbar">
@@ -594,11 +632,12 @@ execute one or more additional tools.
<p class="leftbar">
`mkiocccentry(1)` will use code from `iocccsize(1)` which
detects a number of issues that you may ignore, if you wish, as described above.
detects a number of issues that you may ignore, if you wish, as noted above.
</p>
<p class="leftbar">
In other words, you no longer need to run `iocccsize` manually.
In other words, you no longer need to run `iocccsize` manually. However, the
checks described above are still made but through `mkiocccentry` itself.
</p>
Jump to: [top](#)
@@ -726,7 +765,7 @@ FAQ on "[report mkiocccentry bugs](../faq.html#mkiocccentry_bugs)".
</p>
<p class="leftbar">
As part of its sanity checks, `txzchk(1)` will run `fnamchk(1)` on the
As part of its algorithm, `txzchk(1)` will run `fnamchk(1)` on the
_filename_ to verify that the name is valid. See the
FAQ on "[fnamchk](../faq.html#fnamchk)"
and [fnamchk below](#fnamchk) for more details on this tool.
@@ -771,7 +810,7 @@ FAQ on "[fnamchk](../faq.html#fnamchk)".
</p>
<p class="leftbar">
Because `txzchk(1)` tool uses `fnamchk(1)` tool as part of its algorithm,
Because `txzchk(1)` tool uses the `fnamchk(1)` tool as part of its algorithm,
`mkiocccentry(1)` does not directly invoke `fnamchk(1)`, although we will
in the judging process.
</p>
@@ -790,7 +829,7 @@ FAQ on "[report mkiocccentry bugs](../faq.html#mkiocccentry_bugs)".
<p class="leftbar">
As you can see, the use of `mkiocccentry(1)` is **HIGHLY RECOMMENDED**, and at
the risk of stating the obvious, you run **a VERY BIG risk** of having
the risk of stating the obvious, you run **A VERY BIG RISK** of having
your submission rejected if you package your own tarball, and there are **ANY
problems**. For instance, if `chkentry(1)` found a problem in your `.info.json`
file, the `mkiocccentry(1)` tool would not package it. But if you were to package
@@ -828,7 +867,7 @@ that's OK too!
</div>
<p class="leftbar">
We **recommend** AND **encourage** you to use the example Makefile **here**,
We **recommend** AND **encourage** you to use the example Makefile,
as the starting point for your submission's required `Makefile`:
</p>
@@ -843,7 +882,7 @@ needs.
</p>
<p class="leftbar">
Please add a space between the `=` and the value of variables, in the
**Please** add a space between the `=` and the value of variables, in the
`Makefile`, making sure that the `=` comes immediately after the name. See the
example `Makefile` for examples.
</p>
@@ -1026,7 +1065,7 @@ about this, though it might be worth pointing out.
</p>
<p class="leftbar">
For instance, some compilers like to warn about use of `char *`s, which seems to
For instance, some compilers like to warn about use of pointers as arrays, which seems to
be dubious, as it obviously can't (always) be avoided, being a big part of C, so
you should not worry about this either; this is the warning
`-Wunsafe-buffer-usage` and the way to disable it is `-Wno-unsafe-buffer-usage`.
@@ -1163,7 +1202,7 @@ is in your submission tarball itself.
</p>
<p class="leftbar">
While people are free to mange their submission under `git(1)` or even use a
While people are free to manage their submission under `git(1)` or even use a
GitHub repo, dot-files and dot-directories such as `.git` are not allowed in a
submission.
</p>
@@ -1177,11 +1216,11 @@ the `mkiocccentry(1)` tool.
</p>
<p class="leftbar">
Even if you did manage to get it into the tarball somehow, `txzchk(1)` will
flag it as an error. When the judges run `txzchk(1)` on the uploaded submission
compressed tarball, if anything is wrong, for instance if you "sneak in" any
dot files or dot directories, the submission **WILL BE REJECTED** for violating
[Rule 17](rules.html#rule17)!
Even if you did manage to get dot files or dot directories in the tarball
somehow, `txzchk(1)` will flag it as an error. When the judges run `txzchk(1)`
on the uploaded submission compressed tarball, if anything is wrong, for
instance if you "sneak in" any dot files or dot directories, the submission
**WILL BE REJECTED** for violating [Rule 17](rules.html#rule17)!
</p>
<p class="leftbar">
@@ -1212,6 +1251,7 @@ In other words, for `make clobber`, do something like:
and **NOT** something like this:
``` <!---makefile-->
# do NOT do this!
clobber:
-git clean -f
```
@@ -1268,8 +1308,7 @@ FAQ on "[submitting try.sh and try.alt.sh scripts](../faq.html#try_scripts)".
<p class="leftbar">
You might wish to add `./try.sh` to the `try` rule in the Makefile you submit.
If you have alternate code, then you could add a `try.alt` rule or something
like that.
If you have alternate code, then you can use the `try.alt` rule instead.
</p>
Doing masses of `#define`s to obscure the source has become 'old'. We
@@ -1326,7 +1365,7 @@ of nested functions such as:
On 2012 July 20, the [judges](../judges.html) rescinded the encouragement of
nested functions. Such constructions, while interesting and sometimes
amusing, will have to wait until they required by a C standard that are
amusing, will have to wait until they are required by a C standard that are
actually implemented in **BOTH** `gcc` **AND** `clang`.
<p class="leftbar">
@@ -1463,20 +1502,24 @@ marks the spot**". Yet on the third hand, windows are best when they are
"unseen" (i.e., not dirty). :-)
</p>
<p class="leftbar">
The [judges](../judges.html), as a group, have a history giving wide degree of latitude
to reasonable entries. And recently they have had as much longitudinal
to reasonable submissions. And recently they have had as much longitudinal
variation as it is possible to have on [Earth](https://science.nasa.gov/earth/). :-)
</p>
<p class="leftbar">
You should try to restrict commands used in the build file to
commands found in [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environments
and systems that conform to the [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification).
You should try to restrict commands used in the build file to commands found in
[Single UNIX
Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
environments and systems that conform to the [Single UNIX
Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification).
</p>
<p class="leftbar">
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 if your
absolute one. The intent is to ensure that the building of your
program is reasonably portable.
</p>
@@ -1533,6 +1576,7 @@ We think we did. :-)
> All generalizations are false, including this one. -- **Mark Twain**
<p class="leftbar">
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
@@ -1540,6 +1584,7 @@ version of the same program that is formatted in an interesting
and/or obfuscated way, would definitely win over the first two!
Remember, you can submit more than one submission. See the [IOCCC
rules](rules.html) for details (in particular, [Rule 9](rules.html#rule9)).
</p>
We suggest that you avoid trying for the '**smallest self-replicating**'
source. The smallest, a [zero byte entry](../1994/smr/index.html), won in
@@ -1550,7 +1595,7 @@ better be the smallest such program or they risk being rejected because
they do not work as documented.
Please note that the C source below, besides lacking in obfuscation,
is NOT the smallest C source file that when compiled and run, dumps core:
is **NOT** the smallest C source file that when compiled and run, dumps core:
``` <!---c-->
main;
@@ -1598,6 +1643,13 @@ source program (one that actually works) to display audio/visual data.
X client entries should avoid using X related libraries and
software that are not in wide spread use.
<p class="leftbar">
As of Red Hat RHEL9.0, the X.org server is deprecated. See the
FAQ on "[Xorg deprecation"](../faq.html#Xorg_deprecated)"
for more details. This does not mean that a submission using this will
necessarily be rejected, but it would be better if it can support Wayland.
</p>
This is the only _guideline_ that contains the word
[fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin).
@@ -1728,7 +1780,7 @@ into creating a dense blob. Such are the trade-offs that obfuscators face!
<p class="leftbar">
We prefer code that can run on either a 64-bit or 32-bit
processor. However, it is **UNWISE **to assume it will run on an
some Intel-like x86 architecture.
some Intel-like x86 architecture**.
</p>
We believe that Mark Twain's quote:
@@ -1737,16 +1789,18 @@ We believe that Mark Twain's quote:
... is a good motto for those writing code for the IOCCC.
<p class="leftbar">
The IOCCC size tool source is not an original work, unless you are [Anthony C
Howe](../authors.html#Anthony_C_Howe), in which case it is original! :-)
Submitting source that uses the content of
Submitting source code that uses the content of
[iocccsize.c](https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c), unless you are
[Anthony C Howe](../authors.html#Anthony_C_Howe), might run the risk of
violating [Rule 7](rules.html#rule7).
</p>
<p class="leftbar"> The `txzchk(1)` tool source is not an original work,
unless you are [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson), in
which case it is original! :-) Submitting source that uses the content of
which case it is original! :-) Submitting source code that uses the contents of
[txzchk.c](https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c),
unless you are [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson), might
run the risk of violating [Rule 7](rules.html#rule7).</p>
@@ -1763,11 +1817,11 @@ nor
nor any of the other [jparse
tools](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse)
(see the [jparse repo](https://github.com/xexyl/jparse/)), nor the [fnamchk tool
source](https://github.com/ioccc-src/mkiocccentry/blob/master/test_ioccc/fnamchk.c)
source](https://github.com/ioccc-src/mkiocccentry/blob/master/test_ioccc/fnamchk.c),
are original works,
unless you are [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson) or
[Landon Curt Noll](http://www.isthe.com/chongo/index.html), in which case they
are original! :-) Submitting source that uses the code of these tools or
are original! :-) Submitting source code that uses the code of any of these tools or
library, unless you are [Cody Boone
Ferguson](../authors.html#Cody_Boone_Ferguson) or [Landon Curt
Noll](http://www.isthe.com/chongo/index.html), might run the risk of violating
@@ -1776,7 +1830,7 @@ Noll](http://www.isthe.com/chongo/index.html), might run the risk of violating
<p class="leftbar">
Unless you are [Landon Curt Noll](http://www.isthe.com/chongo/index.html), the
remaining tools in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
are **NOT** original works. Submitting source that uses the content of those tools,
are **NOT** original works. Submitting source code that uses the content of those tools,
unless you are [Landon Curt Noll](http://www.isthe.com/chongo/index.html), might
run the risk of violating [Rule 7](rules.html#rule7).
</p>
@@ -1811,7 +1865,7 @@ While programs that only run in a specific word size are OK, if you have
to pick, choose a 64-bit word size.
<p class="leftbar">
If [IOCCC judges](../judges.html) are feeling ornery we
If the [IOCCC judges](../judges.html) are feeling ornery we
might choose to compile your program for running on an Arduino or
a PDP-11. Heck, should we ever find an emulator of 60-bit CDC Cyber
CPU, we might just try your submission on that emulator as well :-)
@@ -1858,7 +1912,9 @@ However the [judges](../judges.html) might try to also factor 0, so you want to
`2305567963945518424753102147331756070`. Attempting to factor values outside
that range will produce unpredictable results.
Moreover the might try to also factor 3.5 or 0x7, or Fred, so you want to might state:
<p class="leftbar">
Moreover they might try to also factor 3.5 or 0x7, or Fred, so you want to might state:
</p>
> This submission factors integers between 1 and
`2305567963945518424753102147331756070`. Attempting to factor anything else
@@ -1905,7 +1961,7 @@ rendering your markdown content.
<p class="leftbar">
If you do use ASCII tab characters in your non-markdown files, be
aware that some people may use tab stop that is different than the common 8
aware that some people may use a tab stop that is different than the common 8
character tab stop.
</p>
@@ -1968,13 +2024,16 @@ submitting an alternate version that conforms to the
If you do bypass the `mkiocccentry(1)` warnings about [Rule
2a](rules.html#rule2a) and/or about [Rule 2b](rules.html#rule2b)
and submit a submission anyway, you **MUST** try to justify why the IOCCC
[judges](../judges.html) should not reject your submission due to a rule violation.
[judges](../judges.html) should not reject your submission due to a rule
violation, and you would be wise to do this towards the top of your `remarks.md`
file.
</p>
Abusing the web submission procedure tends to annoy us more
than amuse us. Spend your creative energy on content of your
submission rather than on the submission process itself.
<p class="leftbar">
We are often asked why the contest [IOCCC rules](rules.html) and
[IOCCC guidelines](guidelines.html) seem too
strange or contain mistakes, flaws or grammatical errors. One reason
@@ -1982,20 +2041,23 @@ is that we sometimes make genuine mistakes. But in many cases such
problems, flaws or areas of confusion are deliberate. Changes to
[IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html) 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 may continue. A clever author
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 [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html).
</p>
<p class="leftbar">
At the risk of stating the obvious, this contest is a parody of the software
development process. The [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html)
are only a small part of the overall contest. Even so, one may think the
are only a small part of the overall contest. Even so, one might think the
contest [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html) 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 specifications and requirements from marketing, sales,
product management an even from customers themselves on a all too regular basis.
product management and even from customers themselves on an all too regular basis.
This is one of the reasons why the [IOCCC rules](rules.html) and
[IOCCC guidelines](guidelines.html) are written in obfuscated form.
</p>
Jump to: [top](#)
@@ -2005,10 +2067,13 @@ Jump to: [top](#)
Entries are judged by Leonid A. Broukhis and Landon Curt Noll.
<p class="leftbar">
Each submission submitted is given a random id number and subdirectory. The
submission files including, but not limited to `prog.c`, `Makefile`,
`remarks.md` as well as any data files that you submit, are all placed under
their own directory and stored and judged from this directory.
`remarks.md`, `.info.json`, `.auth.json` as well as any data files that you
submit, are all placed under their own directory and stored and judged from this
directory.
</p>
Any information about the authors is not read by the [judges](../judges.html) until
the judging process is complete, and then only from entries that have
@@ -2019,9 +2084,11 @@ The above process helps keep us biased for/against any one particular
individual. Therefore you **MUST** refrain from putting any information
that reveals your identity in your submission.
Now some people point out that coding style might reveal the information
about the others. However we consider this to be simply circumstantial
and outside the scope of the above paragraph.
<p class="leftbar">
Now some people point out that coding and/or writing style might reveal the
information about the authors. However we consider this to be simply
circumstantial and outside the scope of the above paragraph.
</p>
Some people, in the past, have attempted to obfuscate their identity by
including comments of famous Internet personalities such as [Peter
@@ -2087,8 +2154,8 @@ Jump to: [top](#)
A reading consists of a number of actions:
* <p class="leftbar">reading `prog.c`, the C source, reviewing the `remarks.md` information</p>
* briefly looking any any supplied data files
* <p class="leftbar">reading `prog.c`, the C source and reviewing the `remarks.md` information</p>
* <p class="leftbar">briefly looking at any supplied data files</p>
* passing the source thru the C pre-processor
skipping over any `#include`d files
* performing a number of C beautify/cleanup edits on the source
@@ -2122,7 +2189,9 @@ we receive. A typical category list might be:
* **best game that is obfuscated**
* **most creatively obfuscated program**
* **most deceptive C code** (code with deceptive comments and source code)
* **best X program** (see [OUR LIKES AND DISLIKES](#likes))
* <p class="leftbar">**best X program** (see [OUR LIKES AND DISLIKES](#likes)
and the
FAQ on "[Xorg being deprecated](../faq.html#Xorg_deprecated)")</p>
* **best abuse of ISO C or ANSI C standard** (see above about compilers)
* **best abuse of the C preprocessor**
* **worst/best abuse of the rules** (or some variation)
@@ -2178,7 +2247,7 @@ It has been shown that receiving **anonymous** gifts provides the
<p class="leftbar">
See the
FAQ on "[support the IOCCC](../faq.html#support)".
FAQ on "[supporting the IOCCC](../faq.html#support)".
</p>
More often than not, we select a small submission (usually one line) and a
@@ -2207,7 +2276,7 @@ Jump to: [top](#)
<p class="leftbar">
The [judges](../judges.html) will toot initial announcement of who won, the name
of their award, and a very brief description of the winning entry
of their award, and a very brief description (award title) of the winning entry
from the [@IOCCC Mastodon account](https://fosstodon.org/@ioccc).
</p>
@@ -2282,10 +2351,13 @@ submissions we receive. See [How many submissions do the judges receive for a
given IOCCC?](../faq.html#how_many).
</p>
<p class="leftbar">
Often, winning entries are published in selected magazines from around the
world. Winners have appeared in books ('`The New Hacker's Dictionary`',
'`Obfuscated C and Other Mysteries`', '`Pointers On C`', others) and on t-shirts.
More than one winner has been turned into a tattoo!
'`Obfuscated C and Other Mysteries`', '`Pointers On C`', others) and on t-shirts
(sometimes by the author(s) themselves). More than one winner has been turned
into a tattoo!
</p>
Last, but not least, [winners](../authors.html) receive international fame and flames! :-)