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

Merge pull request #120 from xexyl/guidelines

Browse Source 
Update guidelines - typos and other fixes
This commit is contained in:
Landon Curt Noll authored and GitHub committed 2025-03-03 13:25:14 -08:00
2 parents 0aa07b7744 6aca41983e
commit 0ac0a7f240
2 files changed
+249 -168
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

next/guidelines.html
+122 -84
View File
@@ -461,7 +461,7 @@ writing by <a href="../contact.html">contacting the judges</a>.</p>
</div>
</div>
<p class="leftbar">
These <a href="guidelines.html">IOCCC guidelines</a> are version <strong>28.40 2025-02-27</strong>.
These <a href="guidelines.html">IOCCC guidelines</a> are version <strong>28.41 2025-03-03</strong>.
</p>
<p class="leftbar">
The markdown form of these guidelines <a href="guidelines.md"
@@ -492,6 +492,11 @@ 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 class="leftbar">
Of course if a guideline is talking about a rule and you break that guideline,
you stand a good chance of having your submission rejected for breaking the
rule, not the guideline.
</p>
<p>You <strong>SHOULD read the CURRENT <a href="rules.html">IOCCC rules</a></strong>, <em>prior</em> to submitting
code to the contest. The <a href="rules.html">rules</a> are typically published along with
the <a href="guidelines.html">IOCCC guidelines</a>.</p>
@@ -540,7 +545,7 @@ 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="../faq.html#open">open</a></strong>, an <a href="../judges.html">IOCCC
After registering, when the contest is <strong><a href="../faq.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
@@ -595,19 +600,17 @@ 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">
If you wish to test that your submission passes the <code>mkiocccentry(1)</code> tests
If you wish to <strong>test</strong> 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.
The <code>-d</code> option is an alias for <code>-s 21701</code>. An example use:
</p>
<pre><code> mkiocccentry -d workdir topdir</code></pre>
<p class="leftbar">
where <code>workdir</code> is the directory where the tarball will be formed and the
<code>topdir</code> is the directory which has the required files (<code>prog.c</code>, <code>Makefile</code> and
<code>remarks.md</code>) along with extra data files (and if you wish, directories) you
wish to submit. Be aware 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.
where <code>workdir</code> an <code>topdir</code> are the same as above.
</p>
<p class="leftbar">
You may <strong>NOT</strong> submit a tarball created by the <code>-d</code> or <code>-s seed</code> option!
</p>
<p class="leftbar">
<strong>IMPORTANT NOTE</strong>: if you run the program outside the repo directory
@@ -631,8 +634,9 @@ for more help.
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>
using <code>mkiocccentry(1)</code> the <a href="https://submit.ioccc.org">submit server</a>. Uploading
a tarball not formed by <code>mkiocccentry(1)</code> puts you at a very big risk of
</p>
<p class="leftbar">
Uploading a tarball not formed by <code>mkiocccentry(1)</code> puts you at a very big risk of
violating <a href="rules.html#rule17">Rule 17</a>, especially as <code>mkiocccentry(1)</code> does a
great number of things that are required, and it also runs many checks, and if
any of those checks fail, you are at a very great risk of having your submission
@@ -662,6 +666,13 @@ already exist), <code>-A</code> <strong>WILL OVERWRITE THE FILE</strong> and <co
the file. If you use <code>-A</code>, <strong>BE SURE</strong> you don’t overwrite another file by accident!
</p>
<p class="leftbar">
Be aware that even with the <code>-i answers</code> you will still be required to confirm
most if not all <code>y/n</code> questions - you just don’t have to input the name of the
submission, the abstract, the author details etc. If you really wish to
circumvent this you can use the <code>-Y</code> option but we do not recommend this because
if your update breaks a rule or there is some problem, you might not see it.
</p>
<p class="leftbar">
Once the contest enters the <strong><a href="../faq.html#judging">judging</a></strong> state, you will
<strong>NOT</strong> be allowed to upload your submission files, so do give yourself enough
time.
@@ -715,7 +726,7 @@ before the end of file.</p>
ASCII formfeed, and ASCII carriage return.</p>
<p class="leftbar">
When ‘<code>;</code>’, ‘<code>{</code>’ or ‘<code>}</code>’ are within a C string, they may still not be
counted by the IOCCC size tool. This is a <em>feature</em>, not a bug!
counted by the IOCCC size tool. This is a <strong>feature</strong>, not a bug!
</p>
<p>In cases where the above summary and the algorithm implemented by
the IOCCC size tool source code conflict, the algorithm implemented
@@ -854,9 +865,8 @@ FAQ on “<a href="../faq.html#obtaining_mkiocccentry">obtaining the mkiocccentr
</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
packaged it will run <code>txzchk(1)</code>, which will also run <code>fnamchk(1)</code>, as part of
its algorithm.
other tools, <em>before</em> packaging your xz compressed tarball, including running
<code>chkentry(1)</code> on the submission directory.
</p>
<p class="leftbar">
If <code>mkiocccentry</code> encounters an <strong>error</strong> the program will exit and the xz
@@ -872,6 +882,10 @@ page</a>.
FAQ on “<a href="../faq.html#mkiocccentry_bugs">reporting mkiocccentry bugs</a>”.
</p>
<p class="leftbar">
Once the tarball is packaged it will
run <code>txzchk(1)</code>, which will also run <code>fnamchk(1)</code>, as part of its algorithm.
</p>
<p class="leftbar">
However, even if <code>mkiocccentry</code> or one of the tools it invokes reports an error,
it <strong>does not</strong> necessarily mean it is a bug in the code. It might be an issue with
your submission. Thus if you report an error as a bug it might not be something
@@ -881,8 +895,9 @@ that will be fixed as there might not be anything wrong with the tools.
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.
option will assume ‘<em>yes</em>’ to most questions but this is also a big risk. Using
<code>-Y</code> will say ‘<em>yes</em>’ to even more prompts. Needless to say, we do <strong>NOT</strong>
recommend these options.
</p>
<p class="leftbar">
In many places it will prompt you to verify what you input, allowing you to
@@ -948,6 +963,10 @@ only inspects the contents of the two JSON files; it performs other checks on
the other files, and those checks are run on the two JSON files as well.
</p>
<p class="leftbar">
If you submit your own JSON files they do <strong>NOT</strong> have to be valid JSON, though
you might wish to explain what their purpose is in your remarks. :-)
</p>
<p class="leftbar">
If <code>chkentry</code> does not pass and you used <code>mkiocccentry(1)</code> it is <strong>very likely</strong> a
bug and you should <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the mkiocccentry issues
page</a>.
@@ -976,7 +995,7 @@ If you want to know what <code>.auth.json</code> is, see the
FAQ on “<a href="../faq.html#auth_json">.auth.json</a>”.
If you want to know what the <code>.info.json</code> file is, see the
FAQ on “<a href="../faq.html#info_json">.info.json</a>”.
On the other hand, if you want to know a bit more details about <code>chkentry</code>, see the
On the other hand, if you want to know a bit more details about <code>chkentry(1)</code>, see the
FAQ about “<a href="../faq.html#chkentry">chkentry</a>”.
</p>
<p class="leftbar">
@@ -1003,7 +1022,7 @@ a <em>specific</em> release</strong>. Thus the <code>mkiocccentry</code> will at
<p class="leftbar">
You do <strong>NOT need to install</strong> <code>jparse</code> from the <a href="https://github.com/xexyl/jparse">jparse
repo</a>! The <code>mkiocccentry</code> tools link in the
static library from the <code>mkiocccentry</code>’s <em>clone</em>.
static library from <code>mkiocccentry</code>’s <em>clone</em>.
</p>
<p class="leftbar">
The <code>mkiocccentry</code> toolkit <em>also</em> has a clone of <em>both</em> the <a href="https://github.com/lcn2/dbg">dbg
@@ -1026,7 +1045,7 @@ make sure that you’re using the correct versions, which is also verified by
<p class="leftbar">
Please see the
FAQ on “<a href="../faq.html#chkentry">validating your submission directory</a>
for more details on <code>chkentry</code>.
for more details on <code>chkentry(1)</code>.
</p>
<p class="leftbar">
You might also wish to see the
@@ -1038,18 +1057,19 @@ for much more information on these files.
<p>Jump to: <a href="#">top</a></p>
<h2 id="txzchk"><code>txzchk</code></h2>
<p class="leftbar">
<code>txzchk(1)</code> performs a wide number of sanity checks on the xz
compressed tarball; if any issues are found (‘<code>feathers are stuck in the tarball</code>’ :-) ) <strong>AND if and <em>ONLY IF</em> you used
<code>mkiocccentry(1)</code></strong>, then it is <strong>possibly</strong> a bug in one of the tools and you
might want to <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the mkiocccentry bug report
page</a>. <strong>PLEASE run the
<code>bug_report.sh</code> script to help us out here!</strong> You may do this by running from
the top level directory of the repo <code>make bug_report</code>. See the
FAQ on “<a href="../faq.html#mkiocccentry_bugs">report mkiocccentry bugs</a>”.
<code>txzchk(1)</code> performs a wide number of sanity checks on the xz compressed
tarball; if any issues are found (‘<code>feathers are stuck in the tarball</code>’ :-) )
<strong>AND if and <em>ONLY IF</em> you used <code>mkiocccentry(1)</code></strong>, then it is <strong>possibly</strong> a
bug in one of the tools and you might want to <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the
mkiocccentry bug report
page</a>.
<strong>PLEASE run the <code>bug_report.sh</code> script to help us out here!</strong> You may do this
by running from the top level directory of the repo <code>make bug_report</code>. See the
FAQ on “<a href="../faq.html#mkiocccentry_bugs">reporting mkiocccentry bugs</a>”.
</p>
<p class="leftbar">
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
<em>tarball</em> to verify that the filename 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.
</p>
@@ -1075,7 +1095,7 @@ the two JSON files generated by <code>mkiocccentry(1)</code>, <code>.info.json</
</p>
<p class="leftbar">
Additionally, three of the files, if included, <strong>MUST</strong> be
specific file(name)s and in the top level directory, or they will be counted as
specific file(name)s <strong>AND</strong> in the top level directory, or they will be counted as
an extra file, not an optional file.
</p>
<p class="leftbar">
@@ -1131,13 +1151,15 @@ See also the
FAQ on “<a href="../faq.html#txzchk">txzchk</a>”.
</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="fnamchk"><code>fnamchk</code></h2>
<div id="fnamchk">
<h2 id="fnamchk1"><code>fnamchk(1)</code></h2>
</div>
<p class="leftbar">
As an important part of its algorithm, <a href="#txzchk">txzchk</a> directly executes <code>fnamchk</code>.
If the filename is invalid (or the filename does not match the
As an important part of its algorithm, <a href="#txzchk">txzchk</a> directly executes
<code>fnamchk(1)</code>. If the filename is invalid (or the filename does not match the
directory name of the tarball) then it is an <strong>error</strong> and you risk violating
<a href="rules.html#rule17">Rule 17</a>. Nevertheless, you can run the tool manually, should
you wish to.
<a href="rules.html#rule17">Rule 17</a>. Nevertheless, you can run the tool manually,
should you wish to.
</p>
<p class="leftbar">
For more information on <code>fnamchk</code> and how to manually validate your submission
@@ -1158,7 +1180,7 @@ would prevent this from happening as it would not create such a file anyway. If
you should <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the mkiocccentry issues
page</a>.
See the
FAQ on “<a href="../faq.html#mkiocccentry_bugs">report mkiocccentry bugs</a>”.
FAQ on “<a href="../faq.html#mkiocccentry_bugs">reporting 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
@@ -1230,12 +1252,12 @@ We suggest that you compile your submission with a commonly available
</div>
<p class="leftbar">
Unless you <strong>clearly state</strong> otherwise in your <code>remarks.md</code> file, <strong>AND</strong> put in
your submission’s <code>Makefile</code>, we <strong>will</strong> compile using <code>-std=gnu17 -O3 -g3</code>!
your submission’s <code>Makefile</code>, we <strong>will</strong> compile using <code>-std=gnu17 -O3</code>!
</p>
<p class="leftbar">
It <strong>is OK</strong> if you need to require your submission to <strong>NOT be</strong> compiled
using the default <code>-std=gnu17 -O3 -g3</code> settings. Simply <strong>explain why</strong>
your submission should NOT be compiled using <code>-std=gnu17 -O3 -g3</code> in
using the default <code>-std=gnu17 -O3</code> settings. Simply <strong>explain why</strong>
your submission should NOT be compiled using <code>-std=gnu17 -O3</code> in
your <code>remarks.md</code> file, <strong>AND</strong> adjust your <code>Makefile</code> accordingly.
</p>
<p class="leftbar">
@@ -1411,6 +1433,11 @@ If you need to define something on the compile line, use
the <code>CDEFINE</code> Makefile variable. For example:
</p>
<pre><code> CDEFINE= -Dfoo -Dbar=baz</code></pre>
<p class="leftbar">
<strong>NOTE</strong>: just because we offer a default way to use the <code>-D</code> option, we still
do not like excess use of <code>-D</code> to get past size limits, especially since you
could use <code>#define</code> in your code instead.
</p>
<div id="include">
<h2 id="include-files-in-the-makefile">Include files in the Makefile</h2>
</div>
@@ -1491,11 +1518,11 @@ In other words, for <code>make clobber</code>, do something like:
clobber:
-git clean -f</code></pre>
<p class="leftbar">
And do <strong>NOT</strong> use <code>git</code> for any other tool either.
And do <strong>NOT</strong> use <code>git</code> for any other rule either.
</p>
<p class="leftbar">
<strong>NOTE</strong>: <code>mkiocccentry(1)</code> will directly run <code>make clobber</code> in the submission
directory. An although it is not an error if this fails, if it fails because the
directory. And although it is not an error if this fails, if it fails because the
Makefile does not have a clobber rule, it will be flagged by <code>mkiocccentry(1)</code>
(you may ignore this but it does put you at a risk of violating the rules).
</p>
@@ -1518,7 +1545,8 @@ that your submission should not be obfuscated but the IOCCC has moved away from
the idea of spoilers. In other words, unless your submission does some kind of
encryption (or something with encryption), you should not encrypt your remarks,
say with rot13 or anything else, and it is also appreciated if your remarks have
some education value. And although these are not required, they are a nice bonus.
some education value. And although education value is not required, it is a nice
bonus.
</p>
<p class="leftbar">
We <strong>LIKE</strong> submissions that use an edited version of the
@@ -1558,7 +1586,8 @@ as a program that is more well rounded in confusion.</p>
<pre><code> #define d define
#d foo /* &lt;-- don&#39;t expect this to turn into #define foo */</code></pre>
<p class="leftbar">
In other words, it is a compilation error.
In other words, it is a compilation error, and in order to get older entries
that did this to compile, we had to update them to not do this.
</p>
<p>When declaring local or global variables, you should declare the type:</p>
<pre><code> int this_is_fine;
@@ -1579,7 +1608,7 @@ that you not use any really obscure compiler flags if you can help it.
</p>
<p>One side effect of the above is that you cannot assume the use
of nested functions such as:</p>
<pre><code> main() {
<pre><code> int main() {
| void please_dont_submit_this() {
| printf(&quot;The machine that goes BING!!\n&quot;);
}
@@ -1606,7 +1635,7 @@ not portable and <em>must not</em> be used</strong>:</p>
<li>performing arithmetic on <code>va_list</code> variables</li>
<li>using <code>va_list</code> as a structure or union</li>
</ul>
<p>In particular, do not treat <code>va_list</code> variables as if they were a <code>char **</code>s.</p>
<p>In particular, do not treat <code>va_list</code> variables as if they were a <code>char **</code>.</p>
<p class="leftbar">
We <strong>DISLIKE</strong> the use of <code>varargs.h</code>. Use <code>stdarg.h</code> instead.
</p>
@@ -1640,7 +1669,7 @@ explain to the Walrus why our seas are boiling hot, the question of
whether pigs have wings is likely to remain a debatable point to most.
</p>
<p>One line programs should be short one line programs: say around 80 to 120
octets long. Going well beyond 140 octets is a bit too long to be called
octets long. Going well beyond 120 octets is a bit too long to be called
a one-liner in our vague opinion.</p>
<p>We tend to <strong>DISLIKE</strong> programs that:</p>
<ul>
@@ -1707,10 +1736,10 @@ as part of the world’s time standard. If your code prints time
with seconds, we prefer that your code be capable of printing the
time of day during a leap-second where the value in seconds
after the minute mark is 60.</p>
<p>The “<strong>how to build</strong>” process (via the <code>Makefile</code> or otherwise) should not be
used to try and get around the size limit. It is one thing to make use of a
several <code>-D</code>s on the compile line to help out, but it is quite another to use
many bytes of <code>-D</code>s in order to try and squeeze the source under the size limit.</p>
<p>The <code>Makefile</code> should not be used to try and get around the size limit. It is
one thing to make use of a several <code>-D</code>s on the compile line to help out, but it
is quite another to use many bytes of <code>-D</code>s in order to try and squeeze the
source under the size limit.</p>
<p>Your source code, post-pre-processing, should not exceed the size of
<a href="https://en.wikipedia.org/wiki/Microsoft_Windows">Microsoft Windows</a>. :-)</p>
<p class="leftbar">
@@ -1757,7 +1786,7 @@ For example, one could put in their <code>Makefile</code>:</p>
<pre><code> prog: prog.c
${CC} prog.c -DNON_HUMAN_COMPILE -o prog
@echo &quot;See remarks section about alternate ways to compile&quot;</code></pre>
<p>and then include special notes in their <code>remarks.md</code> file for
<p>and then include special notes in your <code>remarks.md</code> file for
alternate / human intervention based building.</p>
<p>We want to get away from source that is simply a compact blob of
octets. Really try to be more creative than blob coding. <strong>HINT!</strong></p>
@@ -1827,7 +1856,8 @@ software that are not in wide spread use.</p>
As of Red Hat RHEL9.0, the X.org server is deprecated. See the
FAQ on “<a href="../faq.html#Xorg_deprecated">Xorg deprecation”</a>”
for more details. This does not mean that a submission using this will
necessarily be rejected, but it would be better if it can support Wayland.
necessarily be rejected, but it would be better if it can support Wayland in
some way or another.
</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>
@@ -1836,8 +1866,9 @@ However, do you know how to play <a href="https://en.wikipedia.org/wiki/List_of_
You do?!? (Except on Tuesday?)
</p>
<p class="leftbar">
OK, there are actually 3 <em>guidelines</em> that contain the word
<a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>.
OK, there are actually 2 <em>guidelines</em> that contain the word
<a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>,
unless you count this one, in which case there are 3. :-)
</p>
<p>We <strong>DISLIKE</strong> entries that use proprietary toolkits such as the <code>M*tif</code>,
<code>Xv*ew</code>, or <code>OpenL*ok</code> toolkits, since not everyone has them. Use an
@@ -1949,7 +1980,7 @@ some Intel-like x86 architecture**.
<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 code that uses the content of
Submitting source code that uses the contents of
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">iocccsize.c</a>,
<em>unless</em> you are <a href="../authors.html#Anthony_C_Howe">Anthony C Howe</a>, might run the
risk of violating <a href="rules.html#rule7">Rule 7</a>.
@@ -1991,7 +2022,7 @@ And unless you are <a href="http://www.isthe.com/chongo/index.html">Landon Curt
the code in
<a href="https://github.com/ioccc-src/mkiocccentry/tree/master/dbg">dbg</a> and
<a href="https://github.com/ioccc-src/mkiocccentry/tree/master/dyn_array">dyn_array</a> are
not original works. Submitting source code that uses the content of those
not original works. Submitting source code that uses the contents of those
libraries, <em>unless</em> you <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>.
@@ -2017,7 +2048,8 @@ obfuscated, but unless you have some really clever way to compact and
obfuscate a JSON parser more than <a href="https://github.com/westes/flex">flex</a> and
<a href="https://www.gnu.org/software/bison/">bison</a> you will likely not win, either
because of the <a href="rules.html#rule2">source code size limit</a> or because it is not
as obfuscated as the lexer/parser of
as obfuscated as the <a href="https://github.com/westes/flex">flex</a> and <a href="https://www.gnu.org/software/bison/">bison</a>
generated code of
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse">jparse</a>.
</p>
<p>While programs that only run in a specific word size are OK, if you have
@@ -2098,14 +2130,14 @@ Do not fear if you’re not 100% sure of the significance of
it? :-)
</p>
<p class="leftbar">
We <strong>DISLIKE</strong> the use of use ASCII tab characters in markdown files, such as in the required <code>remarks.md</code> file.
We <strong>DISLIKE</strong> the use of ASCII tab characters in markdown files, such as in the required <code>remarks.md</code> file.
</p>
<p class="leftbar">
We don’t mind the use ASCII tab characters in your C code. Feel free
to use ASCII tab characters if that suits your obfuscation needs. If is
perfectly <strong>OK</strong> to use tab characters elsewhere in your submission, just not in
markdown files as this tends complicate and annoy us when it comes time to
rendering your markdown content.
markdown files as this tends annoy us when it comes time to
rendering your markdown content as it complicates the process.
</p>
<p class="leftbar">
If you do use ASCII tab characters in your non-markdown files, be
@@ -2160,26 +2192,28 @@ submitting an alternate version that conforms to the
</p>
<p class="leftbar">
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
2a</a> and/or about <a href="rules.html#rule2b">Rule 2b</a> or any other
rule 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, 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 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 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>.
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 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 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 class="leftbar">
At the risk of stating the obvious, this contest is a parody of the software
@@ -2269,18 +2303,18 @@ 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 and 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
Briefly looking at any supplied data files
</p></li>
<li>passing the source thru the C pre-processor
skipping over any <code>#include</code>d files</li>
<li>performing a number of C beautify/cleanup edits on the source</li>
<li>passing the beautified source thru the C pre-processor
skipping over any <code>#include</code>d files</li>
<li>compiling/building the source</li>
<li>running the program</li>
<li>Passing the source thru the C pre-processor
Skipping over any <code>#include</code>d files</li>
<li>Performing a number of C beautify/cleanup edits on the source</li>
<li>Passing the beautified source thru the C pre-processor
Skipping over any <code>#include</code>d files</li>
<li>Compiling/building the source</li>
<li>Running the program</li>
<li>Doing other things that only <a href="../judges.html">IOCCC judges</a> know about :-)</li>
</ul>
<p>In later rounds, other actions are performed including performing
@@ -2288,6 +2322,10 @@ miscellaneous tests on the source and binary.</p>
<p class="leftbar">
This is the very <strong>guideline</strong> that goes, <strong>BING!</strong>
</p>
<p class="leftbar">
Okay, technically that was the <em>second</em> <strong>guideline</strong> that goes <strong>BING</strong>, and this
is the third. :-)
</p>
<p>Until we reduce the stack of submissions down to about 25 submissions,
submissions are judged on an individual basis. A submission is set aside because it
does not, in our opinion, meet the standard established by the round.
next/guidelines.md
+127 -84
View File
@@ -49,7 +49,7 @@ Jump to: [top](#)
</div>
<p class="leftbar">
These [IOCCC guidelines](guidelines.html) are version **28.40 2025-02-27**.
These [IOCCC guidelines](guidelines.html) are version **28.41 2025-03-03**.
</p>
<p class="leftbar">
@@ -90,6 +90,12 @@ 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).
<p class="leftbar">
Of course if a guideline is talking about a rule and you break that guideline,
you stand a good chance of having your submission rejected for breaking the
rule, not the guideline.
</p>
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).
@@ -139,7 +145,7 @@ before the contest status becomes **[open](../faq.html#open)**.
<p class="leftbar">
You **MUST** [register](register.html) in order to participate in the IOCCC.
You may [register](register.html) while the contest is either
**[pending](../faq.html#pending)** or **[open](../faq.html#open)**.
**[pending](../faq.html#pending)** or **[open](../faq.html#open)**.
</p>
<p class="leftbar">
@@ -150,9 +156,9 @@ has changed from previous years!
</p>
<p class="leftbar">
When the contest is **[open](../faq.html#open)**, an [IOCCC
After registering, when the contest is **[open](../faq.html#open)**, an [IOCCC
judge](../judges.html) will email you your [submit
server](https://submit.ioccc.org) **Username** and **Initial password**. This
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.
@@ -215,7 +221,7 @@ To assist in the formation of the xz compressed tarball for submission, use the
</p>
<p class="leftbar">
If you wish to test that your submission passes the `mkiocccentry(1)` tests
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`
option to `mkiocccentry` for the tool to pseudo-randomly create answers for you.
The `-d` option is an alias for `-s 21701`. An example use:
@@ -226,12 +232,11 @@ The `-d` option is an alias for `-s 21701`. An example use:
```
<p class="leftbar">
where `workdir` is the directory where the tarball will be formed and the
`topdir` is the directory which has the required files (`prog.c`, `Makefile` and
`remarks.md`) along with extra data files (and if you wish, directories) you
wish to submit. Be aware 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.
where `workdir` an `topdir` are the same as above.
</p>
<p class="leftbar">
You may **NOT** submit a tarball created by the `-d` or `-s seed` option!
</p>
<p class="leftbar">
@@ -257,8 +262,10 @@ for more help.
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)
using `mkiocccentry(1)` the [submit server](https://submit.ioccc.org). Uploading
a tarball not formed by `mkiocccentry(1)` puts you at a very big risk of
</p>
<p class="leftbar">
Uploading a tarball not formed by `mkiocccentry(1)` puts you at a very big risk of
violating [Rule 17](rules.html#rule17), especially as `mkiocccentry(1)` does a
great number of things that are required, and it also runs many checks, and if
any of those checks fail, you are at a very great risk of having your submission
@@ -293,6 +300,14 @@ already exist), `-A` **WILL OVERWRITE THE FILE** and `-i` will read the answers
the file. If you use `-A`, **BE SURE** you don't overwrite another file by accident!
</p>
<p class="leftbar">
Be aware that even with the `-i answers` you will still be required to confirm
most if not all `y/n` questions - you just don't have to input the name of the
submission, the abstract, the author details etc. If you really wish to
circumvent this you can use the `-Y` option but we do not recommend this because
if your update breaks a rule or there is some problem, you might not see it.
</p>
<p class="leftbar">
Once the contest enters the **[judging](../faq.html#judging)** state, you will
**NOT** be allowed to upload your submission files, so do give yourself enough
@@ -359,7 +374,7 @@ 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!
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
@@ -530,9 +545,8 @@ FAQ on "[obtaining the mkiocccentry toolkit](../faq.html#obtaining_mkiocccentry)
<p class="leftbar">
`mkiocccentry` runs a number of checks, by the tool itself and by executing
other tools, _before_ packaging your xz compressed tarball. Once the tarball is
packaged it will run `txzchk(1)`, which will also run `fnamchk(1)`, as part of
its algorithm.
other tools, _before_ packaging your xz compressed tarball, including running
`chkentry(1)` on the submission directory.
</p>
<p class="leftbar">
@@ -549,6 +563,11 @@ page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug
FAQ on "[reporting mkiocccentry bugs](../faq.html#mkiocccentry_bugs)".
</p>
<p class="leftbar">
Once the tarball is packaged it will
run `txzchk(1)`, which will also run `fnamchk(1)`, as part of its algorithm.
</p>
<p class="leftbar">
However, even if `mkiocccentry` or one of the tools it invokes reports an error,
it **does not** necessarily mean it is a bug in the code. It might be an issue with
@@ -560,8 +579,9 @@ that will be fixed as there might not be anything wrong with the tools.
On the other hand, some conditions flagged by `mkiocccentry(1)` are **warnings**
and it allows you to override these, if you wish. If you're brave enough you can
use the `-W` option to ignore all warnings but this is a big risk; the `-y`
option will assume '_yes_' to most questions but this is also a big risk.
Needless to say, we do **NOT** recommend these options.
option will assume '_yes_' to most questions but this is also a big risk. Using
`-Y` will say '_yes_' to even more prompts. Needless to say, we do **NOT**
recommend these options.
</p>
<p class="leftbar">
@@ -650,6 +670,11 @@ only inspects the contents of the two JSON files; it performs other checks on
the other files, and those checks are run on the two JSON files as well.
</p>
<p class="leftbar">
If you submit your own JSON files they do **NOT** have to be valid JSON, though
you might wish to explain what their purpose is in your remarks. :-)
</p>
<p class="leftbar">
If `chkentry` does not pass and you used `mkiocccentry(1)` it is **very likely** a
bug and you should [report it as a bug at the mkiocccentry issues
@@ -686,7 +711,7 @@ If you want to know what `.auth.json` is, see the
FAQ on "[.auth.json](../faq.html#auth_json)".
If you want to know what the `.info.json` file is, see the
FAQ on "[.info.json](../faq.html#info_json)".
On the other hand, if you want to know a bit more details about `chkentry`, see the
On the other hand, if you want to know a bit more details about `chkentry(1)`, see the
FAQ about "[chkentry](../faq.html#chkentry)".
</p>
@@ -716,7 +741,7 @@ a _specific_ release**. Thus the `mkiocccentry` will at times be behind the
<p class="leftbar">
You do **NOT need to install** `jparse` from the [jparse
repo](https://github.com/xexyl/jparse)! The `mkiocccentry` tools link in the
static library from the `mkiocccentry`'s _clone_.
static library from `mkiocccentry`'s _clone_.
</p>
<p class="leftbar">
@@ -742,7 +767,7 @@ make sure that you're using the correct versions, which is also verified by
<p class="leftbar">
Please see the
FAQ on "[validating your submission directory](../faq.html#chkentry)
for more details on `chkentry`.
for more details on `chkentry(1)`.
</p>
<p class="leftbar">
@@ -760,20 +785,20 @@ Jump to: [top](#)
</div>
<p class="leftbar">
`txzchk(1)` performs a wide number of sanity checks on the xz
compressed tarball; if any issues are found ('`feathers are stuck in the
tarball`' :-) ) **AND if and _ONLY IF_ you used
`mkiocccentry(1)`**, then it is **possibly** a bug in one of the tools and you
might want to [report it as a bug at the mkiocccentry bug report
page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E). **PLEASE run the
`bug_report.sh` script to help us out here!** You may do this by running from
the top level directory of the repo `make bug_report`. See the
FAQ on "[report mkiocccentry bugs](../faq.html#mkiocccentry_bugs)".
`txzchk(1)` performs a wide number of sanity checks on the xz compressed
tarball; if any issues are found ('`feathers are stuck in the tarball`' :-) )
**AND if and _ONLY IF_ you used `mkiocccentry(1)`**, then it is **possibly** a
bug in one of the tools and you might want to [report it as a bug at the
mkiocccentry bug report
page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E).
**PLEASE run the `bug_report.sh` script to help us out here!** You may do this
by running from the top level directory of the repo `make bug_report`. See the
FAQ on "[reporting mkiocccentry bugs](../faq.html#mkiocccentry_bugs)".
</p>
<p class="leftbar">
As part of its algorithm, `txzchk(1)` will run `fnamchk(1)` on the
_filename_ to verify that the name is valid. See the
_tarball_ to verify that the filename is valid. See the
FAQ on "[fnamchk](../faq.html#fnamchk)"
and [fnamchk below](#fnamchk) for more details on this tool.
</p>
@@ -804,7 +829,7 @@ the two JSON files generated by `mkiocccentry(1)`, `.info.json` and
<p class="leftbar">
Additionally, three of the files, if included, **MUST** be
specific file(name)s and in the top level directory, or they will be counted as
specific file(name)s **AND** in the top level directory, or they will be counted as
an extra file, not an optional file.
</p>
@@ -876,15 +901,15 @@ FAQ on "[txzchk](../faq.html#txzchk)".
Jump to: [top](#)
<div id="fnamchk">
## `fnamchk`
## `fnamchk(1)`
</div>
<p class="leftbar">
As an important part of its algorithm, [txzchk](#txzchk) directly executes `fnamchk`.
If the filename is invalid (or the filename does not match the
As an important part of its algorithm, [txzchk](#txzchk) directly executes
`fnamchk(1)`. If the filename is invalid (or the filename does not match the
directory name of the tarball) then it is an **error** and you risk violating
[Rule 17](rules.html#rule17). Nevertheless, you can run the tool manually, should
you wish to.
[Rule 17](rules.html#rule17). Nevertheless, you can run the tool manually,
should you wish to.
</p>
<p class="leftbar">
@@ -908,7 +933,7 @@ would prevent this from happening as it would not create such a file anyway. If
you should [report it as a bug at the mkiocccentry issues
page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E).
See the
FAQ on "[report mkiocccentry bugs](../faq.html#mkiocccentry_bugs)".
FAQ on "[reporting mkiocccentry bugs](../faq.html#mkiocccentry_bugs)".
</p>
<p class="leftbar">
@@ -989,13 +1014,13 @@ We suggest that you compile your submission with a commonly available
<p class="leftbar">
Unless you **clearly state** otherwise in your `remarks.md` file, **AND** put in
your submission's `Makefile`, we **will** compile using `-std=gnu17 -O3 -g3`!
your submission's `Makefile`, we **will** compile using `-std=gnu17 -O3`!
</p>
<p class="leftbar">
It **is OK** if you need to require your submission to **NOT be** compiled
using the default `-std=gnu17 -O3 -g3` settings. Simply **explain why**
your submission should NOT be compiled using `-std=gnu17 -O3 -g3` in
using the default `-std=gnu17 -O3` settings. Simply **explain why**
your submission should NOT be compiled using `-std=gnu17 -O3` in
your `remarks.md` file, **AND** adjust your `Makefile` accordingly.
</p>
@@ -1235,6 +1260,12 @@ the `CDEFINE` Makefile variable. For example:
CDEFINE= -Dfoo -Dbar=baz
```
<p class="leftbar">
**NOTE**: just because we offer a default way to use the `-D` option, we still
do not like excess use of `-D` to get past size limits, especially since you
could use `#define` in your code instead.
</p>
<div id="include">
## Include files in the Makefile
</div>
@@ -1346,13 +1377,13 @@ and **NOT** something like this:
```
<p class="leftbar">
And do **NOT** use `git` for any other tool either.
And do **NOT** use `git` for any other rule either.
</p>
<p class="leftbar">
**NOTE**: `mkiocccentry(1)` will directly run `make clobber` in the submission
directory. An although it is not an error if this fails, if it fails because the
directory. And although it is not an error if this fails, if it fails because the
Makefile does not have a clobber rule, it will be flagged by `mkiocccentry(1)`
(you may ignore this but it does put you at a risk of violating the rules).
</p>
@@ -1379,7 +1410,8 @@ that your submission should not be obfuscated but the IOCCC has moved away from
the idea of spoilers. In other words, unless your submission does some kind of
encryption (or something with encryption), you should not encrypt your remarks,
say with rot13 or anything else, and it is also appreciated if your remarks have
some education value. And although these are not required, they are a nice bonus.
some education value. And although education value is not required, it is a nice
bonus.
</p>
@@ -1420,7 +1452,8 @@ as a program that is more well rounded in confusion.
```
<p class="leftbar">
In other words, it is a compilation error.
In other words, it is a compilation error, and in order to get older entries
that did this to compile, we had to update them to not do this.
</p>
When declaring local or global variables, you should declare the type:
@@ -1451,7 +1484,7 @@ One side effect of the above is that you cannot assume the use
of nested functions such as:
``` <!---c-->
main() {
int main() {
| void please_dont_submit_this() {
| printf("The machine that goes BING!!\n");
}
@@ -1483,7 +1516,7 @@ not portable and _must not_ be used**:
* performing arithmetic on `va_list` variables
* using `va_list` as a structure or union
In particular, do not treat `va_list` variables as if they were a `char **`s.
In particular, do not treat `va_list` variables as if they were a `char **`.
<p class="leftbar">
We **DISLIKE** the use of `varargs.h`. Use `stdarg.h` instead.
@@ -1526,7 +1559,7 @@ whether pigs have wings is likely to remain a debatable point to most.
</p>
One line programs should be short one line programs: say around 80 to 120
octets long. Going well beyond 140 octets is a bit too long to be called
octets long. Going well beyond 120 octets is a bit too long to be called
a one-liner in our vague opinion.
We tend to **DISLIKE** programs that:
@@ -1584,10 +1617,10 @@ with seconds, we prefer that your code be capable of printing the
time of day during a leap-second where the value in seconds
after the minute mark is 60.
The "**how to build**" process (via the `Makefile` or otherwise) should not be
used to try and get around the size limit. It is one thing to make use of a
several `-D`s on the compile line to help out, but it is quite another to use
many bytes of `-D`s in order to try and squeeze the source under the size limit.
The `Makefile` should not be used to try and get around the size limit. It is
one thing to make use of a several `-D`s on the compile line to help out, but it
is quite another to use many bytes of `-D`s in order to try and squeeze the
source under the size limit.
Your source code, post-pre-processing, should not exceed the size of
[Microsoft Windows](https://en.wikipedia.org/wiki/Microsoft_Windows). :-)
@@ -1649,7 +1682,7 @@ For example, one could put in their `Makefile`:
@echo "See remarks section about alternate ways to compile"
```
and then include special notes in their `remarks.md` file for
and then include special notes in your `remarks.md` file for
alternate / human intervention based building.
We want to get away from source that is simply a compact blob of
@@ -1743,7 +1776,8 @@ software that are not in wide spread use.
As of Red Hat RHEL9.0, the X.org server is deprecated. See the
FAQ on "[Xorg deprecation"](../faq.html#Xorg_deprecated)"
for more details. This does not mean that a submission using this will
necessarily be rejected, but it would be better if it can support Wayland.
necessarily be rejected, but it would be better if it can support Wayland in
some way or another.
</p>
This is the only _guideline_ that contains the word
@@ -1755,8 +1789,9 @@ You do?!? (Except on Tuesday?)
</p>
<p class="leftbar">
OK, there are actually 3 _guidelines_ that contain the word
[fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin).
OK, there are actually 2 _guidelines_ that contain the word
[fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin),
unless you count this one, in which case there are 3. :-)
</p>
We **DISLIKE** entries that use proprietary toolkits such as the `M*tif`,
@@ -1888,7 +1923,7 @@ We believe that Mark Twain's quote:
<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 code that uses the content of
Submitting source code that uses the contents of
[iocccsize.c](https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c),
_unless_ you are [Anthony C Howe](../authors.html#Anthony_C_Howe), might run the
risk of violating [Rule 7](rules.html#rule7).
@@ -1930,7 +1965,7 @@ And unless you are [Landon Curt Noll](http://www.isthe.com/chongo/index.html),
the code in
[dbg](https://github.com/ioccc-src/mkiocccentry/tree/master/dbg) and
[dyn_array](https://github.com/ioccc-src/mkiocccentry/tree/master/dyn_array) are
not original works. Submitting source code that uses the content of those
not original works. Submitting source code that uses the contents of those
libraries, _unless_ you [Landon Curt
Noll](http://www.isthe.com/chongo/index.html), might run the risk of violating
[Rule 7](rules.html#rule7).</p>
@@ -1957,7 +1992,8 @@ obfuscated, but unless you have some really clever way to compact and
obfuscate a JSON parser more than [flex](https://github.com/westes/flex) and
[bison](https://www.gnu.org/software/bison/) you will likely not win, either
because of the [source code size limit](rules.html#rule2) or because it is not
as obfuscated as the lexer/parser of
as obfuscated as the [flex](https://github.com/westes/flex) and [bison](https://www.gnu.org/software/bison/)
generated code of
[jparse](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse).
</p>
@@ -2048,15 +2084,15 @@ it? :-)
</p>
<p class="leftbar">
We **DISLIKE** the use of use ASCII tab characters in markdown files, such as in the required `remarks.md` file.
We **DISLIKE** the use of ASCII tab characters in markdown files, such as in the required `remarks.md` file.
</p>
<p class="leftbar">
We don't mind the use ASCII tab characters in your C code. Feel free
to use ASCII tab characters if that suits your obfuscation needs. If is
perfectly **OK** to use tab characters elsewhere in your submission, just not in
markdown files as this tends complicate and annoy us when it comes time to
rendering your markdown content.
markdown files as this tends annoy us when it comes time to
rendering your markdown content as it complicates the process.
</p>
<p class="leftbar">
@@ -2122,28 +2158,30 @@ submitting an alternate version that conforms to the
<p class="leftbar">
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
2a](rules.html#rule2a) and/or about [Rule 2b](rules.html#rule2b) or any other
rule 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, and you would be wise to do this towards the top of your `remarks.md`
file.
</p>
<p class="leftbar">
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 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
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 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).
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 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 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">
@@ -2254,15 +2292,15 @@ Jump to: [top](#)
A reading consists of a number of actions:
* <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
* passing the beautified source thru the C pre-processor
skipping over any `#include`d files
* compiling/building the source
* running the program
* <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
* Passing the beautified source thru the C pre-processor
Skipping over any `#include`d files
* Compiling/building the source
* Running the program
* Doing other things that only [IOCCC judges](../judges.html) know about :-)
In later rounds, other actions are performed including performing
@@ -2272,6 +2310,11 @@ miscellaneous tests on the source and binary.
This is the very **guideline** that goes, **BING!**
</p>
<p class="leftbar">
Okay, technically that was the _second_ **guideline** that goes **BING**, and this
is the third. :-)
</p>
Until we reduce the stack of submissions down to about 25 submissions,
submissions are judged on an individual basis. A submission is set aside because it
does not, in our opinion, meet the standard established by the round.