checkpoint on updating the rules and guidelines
Added a `#weverything` div tag to the FAQ. Expanded and improved(?) a number of rules and guidelines. In particular, the consequences of the new mkiocccentry repo have been put into the rules and guidelines. This is a checkpoint from which we can review, edit and improve.
This commit is contained in:
Landon Curt Noll committed
1 parent
6eebade91b
commit
f08f87d92f
6 files changed
+647
-397
No files matched your search
@@ -481,9 +481,11 @@ other inconsistencies with the original entry?</a></li>
|
||||
</div>
|
||||
<div id="faq0_0">
|
||||
<div id="submit">
|
||||
<div id="register">
|
||||
<h3 id="faq-0.0-how-may-i-enter-the-ioccc">FAQ 0.0: How may I enter the IOCCC?</h3>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>To submit your code to the IOCCC, you <strong>MUST</strong> follow these steps:</p>
|
||||
<h4 id="verify-that-the-ioccc-is-open-for-submissions">0. Verify that the IOCCC is open for submissions</h4>
|
||||
<p>Check the <a href="status.html">current status of the IOCCC</a> see of the IOCCC is open.</p>
|
||||
@@ -1542,8 +1544,10 @@ include this here, at least for now.</p>
|
||||
<p>Usually the index.html file will explain how to use it under Linux so we do not
|
||||
include this here, at least for now.</p>
|
||||
<div id="faq3_11">
|
||||
<div id="weverything">
|
||||
<h3 id="faq-3.11-why-do-makefiles-use--weverything-with-clang">FAQ 3.11: Why do Makefiles use -Weverything with clang?</h3>
|
||||
</div>
|
||||
</div>
|
||||
<p>While we know that use of <code>-Weverything</code> is generally not recommended
|
||||
by <code>clang</code> C compiler developers, we do use the <code>-Weverything</code>
|
||||
option in a certain case in IOCCC entry <code>Makefile</code>s.</p>
|
||||
|
||||
@@ -103,9 +103,11 @@ other inconsistencies with the original entry?](#faq4_3)
|
||||
|
||||
<div id="faq0_0">
|
||||
<div id="submit">
|
||||
<div id="register">
|
||||
### FAQ 0.0: How may I enter the IOCCC?
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
To submit your code to the IOCCC, you **MUST** follow these steps:
|
||||
|
||||
@@ -1636,8 +1638,10 @@ include this here, at least for now.
|
||||
|
||||
|
||||
<div id="faq3_11">
|
||||
<div id="weverything">
|
||||
### FAQ 3.11: Why do Makefiles use -Weverything with clang?
|
||||
</div>
|
||||
</div>
|
||||
|
||||
While we know that use of `-Weverything` is generally not recommended
|
||||
by `clang` C compiler developers, we do use the `-Weverything`
|
||||
|
||||
+161
-125
@@ -425,29 +425,39 @@ The rules are typically published along with the <a href="guidelines.html">IOCCC
|
||||
<strong><code>|</code></strong> <strong>XXX - date/time is TBD - XXX</strong></p>
|
||||
<p><strong><code>|</code></strong> The reason for the times of day are so that key IOCCC events are <strong>calculated</strong>
|
||||
for be a <strong>fun</strong>ctional UTC time. :-)</p>
|
||||
<p>Until the start of this IOCCC, the <a href="rules.html">IOCCC rules</a>, <a href="guidelines.html">IOCCC guidelines</a> and <code>iocccsize.c</code>
|
||||
(contained in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||||
toolkit</a>)
|
||||
tool should be considered provisional <strong>BETA</strong> versions and <strong>may be
|
||||
adjusted <em>AT ANY TIME</em></strong>.</p>
|
||||
<p>The IOCCC submission URL is <a href="https://submit.ioccc.org/" class="uri">https://submit.ioccc.org/</a>.</p>
|
||||
<p><strong><code>|</code></strong> Until the start of this IOCCC, the <a href="rules.html">IOCCC rules</a>,
|
||||
<a href="guidelines.html">IOCCC guidelines</a> tools in the
|
||||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>, tool should be
|
||||
considered provisional <strong>BETA</strong> versions and <strong>may be adjusted <em>AT
|
||||
ANY TIME</em></strong>.</p>
|
||||
<p><strong><code>|</code></strong> The submit URL should be active on or slightly before <strong>2024-MMM-DD HH:MM:SS UTC</strong>.<br>
|
||||
<strong><code>|</code></strong> <strong>XXX - date/time is TBD - XXX</strong></p>
|
||||
<p>Please wait to submit your entries until after that time.</p>
|
||||
<p>The <a href="rules.html">IOCCC rules</a>, <a href="guidelines.html">IOCCC guidelines</a> and iocccsize.c (invoked by the mkiocccentry)
|
||||
tool will be available on the official IOCCC website on or slightly before start
|
||||
of this IOCCC. Please check the IOCCC <a href="../faq.html#submit">FAQ about how to submit</a>
|
||||
to see how to submit entries, on or after the start of this IOCCC, to be sure
|
||||
you are using the correct versions of these items before using the IOCCC entry
|
||||
submission URL.</p>
|
||||
<p><strong><code>|</code></strong> The <a href="rules.html">IOCCC rules</a>, <a href="guidelines.html">IOCCC
|
||||
guidelines</a> will be available on the official IOCCC
|
||||
website on or slightly before start of this IOCCC. Please check
|
||||
the IOCCC <a href="../faq.html#submit">FAQ about how to submit</a> to see how
|
||||
to submit entries, on or after the start of this IOCCC, to be sure
|
||||
you are using the correct versions of these items before using the
|
||||
IOCCC submission URL.</p>
|
||||
<p><strong><code>|</code></strong> The <a href="rules.html#rule2a">Rule 2a</a> size has <strong>increased from 4096 to 4993</strong> bytes.</p>
|
||||
<p><strong><code>|</code></strong> The <a href="rules.html#rule2b">Rule 2b</a> size has <strong>increased from 2053 to 2503</strong> bytes.</p>
|
||||
<p><strong><code>|</code></strong> Use default way to compile submissions is now <code>-std=gnu17 -O3 -g3 -Wall -Wextra -pedantic</code>.</p>
|
||||
<p><strong><code>|</code></strong> Submissions are in the form of a single bzip2 compressed tarball.</p>
|
||||
<p><strong><code>|</code></strong> To assist in the formation of the bzip2 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><strong><code>|</code></strong> <a href="rules.html#rule17">Rule 17</a> as been significantly modified
|
||||
to account for the new <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a> tools.</p>
|
||||
<p><strong><code>|</code></strong> An <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example">example Makefile</a>
|
||||
is now available from the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>.</p>
|
||||
<p><strong><code>|</code></strong> The IOCCC submission URL, <a href="../status.html">when the IOCCC is open</a>, is <a href="https://submit.ioccc.org/">submit.ioccc.org</a>.</p>
|
||||
<h1 id="hints-and-suggestions">HINTS AND SUGGESTIONS:</h1>
|
||||
<p>You are encouraged to examine the winners of previous contests. See
|
||||
<strong>FOR MORE INFORMATION</strong> for details on how to get previous winners.</p>
|
||||
<p>Keep in mind that rules change from year to year, so some winning entries
|
||||
might not be valid entries this year. What <em>was</em> unique and novel one year
|
||||
<em>might be ‘old’ the next year</em>.</p>
|
||||
<p>An entry is usually examined in a number of ways. We typically apply
|
||||
a number of tests to an entry:</p>
|
||||
<p>An submission is usually examined in a number of ways. We typically apply
|
||||
a number of tests to an submission:</p>
|
||||
<ul>
|
||||
<li>look at the original source</li>
|
||||
<li>convert ANSI trigraphs to ASCII</li>
|
||||
@@ -458,21 +468,21 @@ a number of tests to an entry:</p>
|
||||
<li>compile it (with flags to enable all warnings)</li>
|
||||
<li>execute it</li>
|
||||
</ul>
|
||||
<p>You should consider how your entry looks in each of the above tests.
|
||||
You should ask yourself if your entry remains obscure after it has been
|
||||
<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 entry need not pass all of the above tests. In certain
|
||||
<p>Your submission need not pass all of the above tests. In certain
|
||||
cases, a test is not important. Entries that compete for the
|
||||
‘<em>strangest/most creative source layout</em>’ 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 entry that
|
||||
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 rules. 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 ‘<em>Best abuse of the
|
||||
rules</em>’ or ‘<em>Worst abuse of the rules</em>’ to an entry that illustrates this point
|
||||
rules</em>’ or ‘<em>Worst abuse of the rules</em>’ to an submission that illustrates this point
|
||||
in an ironic way.</p>
|
||||
<p>We do realize that there are holes in the rules, and invite entries
|
||||
to attempt to exploit them. We will award ‘<em>Worst abuse of the rules</em>’ or
|
||||
@@ -480,18 +490,18 @@ to attempt to exploit them. We will award ‘<em>Worst abuse of the rules</em>
|
||||
<p><strong><code>|</code></strong> Even so, we will attempt to use the smallest plug needed, if not smaller. Or, maybe not. :-)</p>
|
||||
<p><strong><code>|</code></strong> There may be less than 2^7+1 reasons why these <a href="guidelines.html">IOCCC guidelines</a> seem obfuscated.</p>
|
||||
<p>Check out your program and be sure that it works. We sometimes make
|
||||
the effort to debug an entry that has a slight problem, particularly
|
||||
the effort to debug an 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><strong><code>|</code></strong> 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 entry sometimes prints the 4th power
|
||||
of a prime by mistake</em>” would save the above entry. And sometimes,
|
||||
a strange bug/feature can even help the entry! Of course, a correctly
|
||||
working entry is best. Clever people will note that 16 might be prime
|
||||
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 entry’s <code>remarks.md</code> file.</p>
|
||||
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>” really really, and we do mean really, do need to be more creative.</p>
|
||||
@@ -504,12 +514,12 @@ misleading comments and variable names might be a good start.</p>
|
||||
specific terminal brand. Those programs that work in a standard xterm
|
||||
are considered more portable.</p>
|
||||
<p><strong><code>|</code></strong> <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>.</p>
|
||||
<p><strong><code>|</code></strong> See the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a> for the <code>iocccsize(1)</code> tool.</p>
|
||||
<p><strong><code>|</code></strong> See the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a> for the <code>iocccsize(1)</code> tool.</p>
|
||||
<p><strong><code>|</code></strong> To further clarify <a href="rules.html#rule2">Rule 2</a>, we subdivided it into two parts, <strong>2a</strong> and <strong>2b</strong>.</p>
|
||||
<p><strong><code>|</code></strong> The overall size limit (see <a href="rules.html#rule2a">Rule 2a</a>) on <code>prog.c</code> is now <strong>4993 bytes</strong>.</p>
|
||||
<p><strong><code>|</code></strong> Your entry must satisfy BOTH the maximum size <a href="rules.html#rule2a">Rule 2a</a> AND your entry
|
||||
<p><strong><code>|</code></strong> Your submission must satisfy BOTH the maximum size <a href="rules.html#rule2a">Rule 2a</a> AND your submission
|
||||
must satisfy the IOCCC size tool <a href="rules.html#rule2b">Rule 2b</a>.</p>
|
||||
<p>This tool imposes a 2nd limit on C code size (see <a href="rules.html#rule2a">Rule 2a</a>. To check your
|
||||
<p><strong><code>|</code></strong> This 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 the 2nd limit of <a href="rules.html#rule2">Rule 2</a>, use the -i command line option.
|
||||
For example:</p>
|
||||
<pre><code> ./iocccsize prog.c</code></pre>
|
||||
@@ -535,22 +545,61 @@ by the IOCCC size tool source code is preferred by the judges.</p>
|
||||
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><strong><code>|</code></strong> 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_rule">2001-2020 IOCCC era</a>.</p>
|
||||
<p>We applaud programs that do not issue warnings when compiled.
|
||||
To avoid warnings, you might be tempted to add various <code>-Wno-foobar</code>
|
||||
flags. Unfortunately such flags are NOT portable. Moreover,
|
||||
such flags are not consistent between different C compilers.
|
||||
Therefore we recommend that you consider one of several approaches:</p>
|
||||
<ol type="a">
|
||||
<li>Write code that does not generate compiler warnings (but see <a href="../faq.html#faq3_11">the FAQ about
|
||||
clang -Weverything</a>)</li>
|
||||
<li>Do not use flags that disable compiler warnings</li>
|
||||
<li>Provide instructions (such as in your Makefile) that
|
||||
use the appropriate disable compiler warnings flags for
|
||||
both clang and gcc</li>
|
||||
<li>Do something creative</li>
|
||||
</ol>
|
||||
<p><strong><code>|</code></strong> 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_rule">2001-2020 IOCCC era</a>.</p>
|
||||
<p><strong><code>|</code></strong> We recommend that you use the
|
||||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example">example Makefile</a>
|
||||
from the <a href="https://github.com/ioccc-src/mkiocccentry">IOCCC mkiocccentry repo</a>.
|
||||
renamed as <code>Makefile</code> of course, as the starting point for your submissions
|
||||
required <code>Makefile</code>. Feel free to modify the Makefile to suit your obfuscated needs.</p>
|
||||
<p><strong><code>|</code></strong> The rest of these guidelines will assume that you are using some variant of the
|
||||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example">example Makefile</a>,
|
||||
renamed as <code>Makefile</code> of course.</p>
|
||||
<p><strong><code>|</code></strong> We suggest that you compile your submission with a commonly available
|
||||
<code>-std=gnu17</code> (ISO C 2017 with GNU extensions) C compiler.</p>
|
||||
<p><strong><code>|</code></strong> Unless you clearly state otherwise in your <code>remarks.md</code> file AND put into your
|
||||
submission’s <code>Makefile</code>, we will compile using <code>-O3 -std=gnu17</code>.</p>
|
||||
<p><strong><code>|</code></strong> It is <strong>OK</strong> to require your submission to not be compiled
|
||||
using the default <code>-O3 -g3 -std=gnu17</code> settings. Simply explain why
|
||||
your submission should not be compiled using <code>-O3 -g3 -std=gnu17</code> in
|
||||
your <code>remarks.md</code> file and adjust your <code>Makefile</code> accordingly.</p>
|
||||
<p><strong><code>|</code></strong> <strong>IMPORTANT NOTE</strong>: The use of <code>-std=gnu17</code> does <strong>NOT</strong> imply the use of the <code>gcc</code>
|
||||
compiler! We often start by compiling using the <strong>clang</strong> C compiler instead.</p>
|
||||
<p><strong><code>|</code></strong> You may change the standard under which your submission is compiled
|
||||
by modifying the <code>CSTD</code> Makefile variable. For example, to use <code>c17</code> instead:</p>
|
||||
<pre><code> CSTD= -std=c17</code></pre>
|
||||
<p><strong><code>|</code></strong> For compilers, such as clang, that have the <code>-Weverything</code> option,
|
||||
while you try wish it, <strong>HOWEVER</strong> see the <a href="../faq.html#weverything">FAQ about clang -Weverything</a>.
|
||||
Thus, we do <strong>NOT</strong> recommend that you put the use of <code>-Weverything</code> into
|
||||
your submission’s <code>Makefile</code>.</p>
|
||||
<p><strong><code>|</code></strong> You may change the level of optimization and compiler debug level
|
||||
which your submission is compiled by modifying the <code>COPT</code> Makefile variable.
|
||||
For example, to compile without optimization:</p>
|
||||
<pre><code> COPT= -O0 -g3</code></pre>
|
||||
<p><strong><code>|</code></strong> There is no real penalty for compiler warnings. Sometimes
|
||||
compiler warnings cannot be helped: especially in the case of
|
||||
obfuscated C. :-) So if you cannot easily get rid of a compiler
|
||||
warning, try not fret too much.</p>
|
||||
<p><strong><code>|</code></strong> To turn off a compiler warning, to your submission’s <code>Makefile</code>,
|
||||
try something such as:</p>
|
||||
<pre><code> CSILENCE= -Wno-some-thing -Wno-another-thing -Wno-unknown-warning-option</code></pre>
|
||||
<p><strong><code>|</code></strong> If you do add “<code>-Wno-some-thing</code>” to your Makefile,
|
||||
consider also adding <code>-Wno-unknown-warning-option</code> just in case the
|
||||
warning you use is not available in the compilers we use test your
|
||||
submission.</p>
|
||||
<p><strong><code>|</code></strong> If you need to define something on the compile line, use
|
||||
the <code>CDEFINE</code> Makefile variable. For example:</p>
|
||||
<pre><code> CDEFINE= -Dfoo -Dbar=baz</code></pre>
|
||||
<p><strong><code>|</code></strong> If need add other “<em>magic</em>” flags to your compile line,
|
||||
use the <code>COTHER</code> Makefile variable. For example:</p>
|
||||
<pre><code> COTHER= -include stdio.h</code></pre>
|
||||
<h1 id="our-likes-and-dislikes">OUR LIKES AND DISLIKES:</h1>
|
||||
<p><strong><code>|</code></strong> We <strong>LIKE</strong> entries that use an edited variant of the
|
||||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example">example Makefile</a>,
|
||||
renamed as <code>Makefile</code> of course. This makes it easier for the <a href="../judges.html">IOCCC Judges</a>
|
||||
to test your submission. And if your submissions wins, integrate it into
|
||||
the <a href="https://www.ioccc.org/index.html">Official IOCCC winner website</a>.</p>
|
||||
<p>Doing masses of <code>#defines</code> to obscure the source has become ‘old’. We
|
||||
tend to ‘see thru’ masses of <code>#defines</code> due to our pre-processor tests
|
||||
that we apply. Simply abusing <code>#defines</code> or <code>-Dfoo=bar</code> won’t go as far
|
||||
@@ -561,32 +610,19 @@ as a program that is more well rounded in confusion.</p>
|
||||
<p>When declaring local or global variables, you should declare the type:</p>
|
||||
<pre><code> int this_is_fine;
|
||||
this_is_not; /* <-- Try to avoid implicit type declarations */</code></pre>
|
||||
<p><strong><code>|</code></strong> We suggest that you compile your entry with a commonly available
|
||||
gnu17 (ISO C 2017 with GNU extensions) C compiler.</p>
|
||||
<p>We really <strong>LIKE</strong> code that has a minimum of warnings, especially under the
|
||||
<p><strong><code>|</code></strong> We <strong>LIKE</strong> code that has a minimum of warnings, especially under the
|
||||
more strict <code>-Wall -Wextra -pedantic</code> mode:</p>
|
||||
<pre><code> -Wall -Wextra -pedantic</code></pre>
|
||||
<p>For compilers, such as clang, that have the <code>-Weverything</code> option, try
|
||||
to make your code compile warning free using:</p>
|
||||
<pre><code> -Wall -Wextra -Weverything -pedantic</code></pre>
|
||||
<p>.. though, again, see <a href="../faq.html#faq3_11">the FAQ about clang -Weverything</a> in
|
||||
the <a href="../faq.html">FAQ</a>.</p>
|
||||
<p>If you must turn off various warnings on the compile line such as:</p>
|
||||
<pre><code> ... -Wno-empty-body -Wno-return-type ...</code></pre>
|
||||
<p><strong><code>|</code></strong> be sure to clearly state so in your <code>remarks.md</code> file <strong>AS WELL AS</strong> in
|
||||
your <code>Makefile</code>.</p>
|
||||
<pre><code> CWARN= -Wall -Wextra -pedantic</code></pre>
|
||||
<p>All other things being equal, a program that must turn off fewer
|
||||
warnings will be considered better, for certain values of better.</p>
|
||||
<p><strong><code>|</code></strong> Unless you clearly state otherwise in your <code>remarks.md</code> file <strong>AS WELL AS</strong> in
|
||||
your “how to build” / Makefile we will compile using:</p>
|
||||
<pre><code> -O3 -std=gnu17</code></pre>
|
||||
<p><strong><code>|</code></strong> There is no real penalty for compiler warnings. Sometimes compiler warnings cannot be helped: especially in the case of obfuscated C. :-) So if you cannot easily get rid of a compiler warning, try not fret too much. Just add the needed “<code>-Wno-somethings</code>” to your Makefile. We suggest you add then to the <code>CSILENCE=</code> line, if you use some variant of the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example">example Makefile</a> from the <a href="https://github.com/ioccc-src/mkiocccentry">IOCCC mkiocccentry repo</a>.</p>
|
||||
<p><strong><code>|</code></strong> If you do add “<code>-Wno-somethings</code>” to your Makefile, consider also adding <code>-Wno-unknown-warning-option</code> just in case the warning you use is not available in the compilers we use test your submission.</p>
|
||||
<p><strong><code>|</code></strong> <strong>DO NOT</strong> assume that we will use <strong>gcc</strong> to compile your program.
|
||||
We will first try to compile your program using <strong>clang</strong>.</p>
|
||||
<p>It is much better to not use any obscure compiler flags if
|
||||
you can help it. We want to discourage the use of obscure compiler
|
||||
flags that would make the program less portable.</p>
|
||||
<p><strong><code>|</code></strong> We tend to <strong>like less</strong> a submission that requires either
|
||||
<strong>gcc</strong> or <strong>clang</strong>. We prefer submissions that can compile
|
||||
under both <strong>gcc</strong> and <strong>clang</strong>.</p>
|
||||
<p><strong><code>|</code></strong> We <strong>RECOMMEND</strong> that the compiler flags you use in your
|
||||
submission’s <code>Makefile</code> are supported by both <strong>gcc</strong> and <strong>clang</strong>.</p>
|
||||
<p><strong><code>|</code></strong> We <strong>DISLIKE</strong> the use of obscure compiler flags, especially
|
||||
if either <strong>gcc</strong> or <strong>clang</strong> does not support it. We <strong>suggest</strong>
|
||||
that you not use any really obscure compiler flags if you can help it.</p>
|
||||
<p>One side effect of the above is that you cannot assume the use
|
||||
of nested functions such as:</p>
|
||||
<pre><code> main() {
|
||||
@@ -595,15 +631,14 @@ of nested functions such as:</p>
|
||||
}
|
||||
| please_dont_submit_this();
|
||||
}</code></pre>
|
||||
<p>This is because such nested functions often requires one to compile with
|
||||
a flag such as <code>-fnested-functions</code> that is not found on some compilers.</p>
|
||||
<p>On 2012 July 20, the judges rescinded the encouragement of
|
||||
<p><strong><code>|</code></strong> On 2012 July 20, the judges 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
|
||||
actually implemented in commonly used C compilers. Sorry!</p>
|
||||
actually implemented in both <strong>gcc</strong> and <strong>clang</strong>.</p>
|
||||
<p><strong><code>|</code></strong> We <strong>DISLIKE</strong> submissions require the use of <code>-fnested-functions</code>.</p>
|
||||
<p>We prefer programs that do not require a fish license: crayons and
|
||||
cat detector vans not withstanding.</p>
|
||||
<p>If your entry uses functions that have a variable number of
|
||||
<p>If your submission uses functions that have a variable number of
|
||||
arguments, be careful. Systems implement <code>va_list</code> as a wide variety
|
||||
of ways. Because of this, a number of operations using <code>va_list</code> are
|
||||
not portable and must not be used:</p>
|
||||
@@ -620,7 +655,7 @@ not portable and must not be used:</p>
|
||||
<p>On 28 January 2007, the Judges rescinded the requirement that the
|
||||
<code>#</code> in a C preprocessor directive must be the 1st non-whitespace octet.</p>
|
||||
<p>The <code>exit(3)</code> function returns <code>void</code>. Some broken systems have <code>exit(3)</code>
|
||||
return <code>int</code>, your entry should assume that <code>exit(3)</code> returns a <code>void</code>.</p>
|
||||
return <code>int</code>, your submission should assume that <code>exit(3)</code> returns a <code>void</code>.</p>
|
||||
<p><strong><code>|</code></strong> This <em>guideline</em> has a change mark at the very start of this line.</p>
|
||||
<p>Small programs are best when they are short, obscure and concise.
|
||||
While such programs are not as complex as other winners, they do
|
||||
@@ -640,7 +675,7 @@ a one-liner in our vague opinion.</p>
|
||||
<ul>
|
||||
<li>are very hardware specific</li>
|
||||
<li>are very OS version specific (index/strchr differences are OK, but socket/streams specific code is likely not to be)<br>
|
||||
<strong><code>|</code></strong> * dump core or have compiler warnings (it is OK only if you warn us in your ‘remark,md’ file)<br>
|
||||
<strong><code>|</code></strong> * dump core or have compiler warnings (it is OK only if you warn us in your ‘remark.md’ file)<br>
|
||||
<strong><code>|</code></strong> * won’t compile or run a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a> environment</li>
|
||||
<li>depend on a utility or application not normally found systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a></li>
|
||||
<li>abuse the build file to get around the size limit<br>
|
||||
@@ -653,10 +688,10 @@ a one-liner in our vague opinion.</p>
|
||||
<li>that mandate the exclusive the use of an specific Integrated</li>
|
||||
<li>Development Environment (IDE)</li>
|
||||
</ul>
|
||||
<p>In order to encourage entry portability, we <strong>DISLIKE</strong> entries that
|
||||
<p>In order to encourage submission portability, we <strong>DISLIKE</strong> entries that
|
||||
fail to build unless one is using an IDE. For example, do not
|
||||
mandate that one must use Microsoft Visual Studio to compile
|
||||
your entry. Nevertheless some of the better IDEs have command-line
|
||||
your submission. Nevertheless some of the better IDEs have command-line
|
||||
interfaces to their compilers, once one learns how to invoke a shell.</p>
|
||||
<p><strong><code>|</code></strong> The program must compile and link cleanly in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a> environment Therefore do not assume the system has a
|
||||
<a href="https://en.wikipedia.org/wiki/Windows.h">windows.h</a> include file:</p>
|
||||
@@ -692,7 +727,7 @@ operating systems (i.e., Linux, GNU Hurd, BSD, Unix, etc.).</p>
|
||||
<p>There are at least zero judges who think that Fideism has little
|
||||
or nothing to do with the IOCCC judging process.</p>
|
||||
<p>Don’t forget that the building of your program should be done
|
||||
<strong><em>WITHOUT human intervention</em></strong>. So don’t do things such as:</p>
|
||||
<strong>WITHOUT human intervention</strong>. So don’t do things such as:</p>
|
||||
<pre><code> prog: prog.c
|
||||
#echo this next line requires data from standard input
|
||||
cat > prog.c
|
||||
@@ -727,9 +762,9 @@ 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 entry. See the <a href="rules.html">IOCCC rules</a> for details.</p>
|
||||
Remember, you can submit more than one submission. See the <a href="rules.html">IOCCC rules</a> for details.</p>
|
||||
<p>We suggest that you avoid trying for the ‘smallest self-replicating’
|
||||
source. The smallest, a zero byte entry, <a href="../1994/smr/index.html">won in 1994</a>.</p>
|
||||
source. The smallest, a zero byte submission, <a href="../1994/smr/index.html">won in 1994</a>.</p>
|
||||
<p>Programs that claim to be the smallest C source that does something, really
|
||||
better be the smallest such program or they risk being rejected because
|
||||
they do not work as documented.</p>
|
||||
@@ -798,7 +833,7 @@ parliament should you have one.</p>
|
||||
<p>Some types of programs can’t excel (anti-tm) in some areas. Your
|
||||
program doesn’t have to excel in all areas, but doing well in several
|
||||
areas really does help.</p>
|
||||
<p><strong><code>|</code></strong> You are better off explaining what your entry does in your
|
||||
<p><strong><code>|</code></strong> You are better off explaining what your submission does in your
|
||||
<code>remarks.md</code> file section rather than leaving it obscure for the judges
|
||||
as we might miss something and/or be too tired to notice.</p>
|
||||
<p><strong><code>|</code></strong> Please avoid this specific individual <em>guideline</em>, if it at all possible.</p>
|
||||
@@ -826,18 +861,18 @@ Instead of unescaped octets, you should use or escapes:</p>
|
||||
if (strlen(foo) == 36) printf("foo is 36 octets plus a final NUL\n");
|
||||
else printf("This code should not print this message\n");</code></pre>
|
||||
<p><strong><code>|</code></strong> It is a very good idea to, in your <code>remarks.md</code> file, tell us why you
|
||||
think your entry is obfuscated. This is particularly true if
|
||||
your entry is has some very subtle obfuscations that we might
|
||||
think your submission is obfuscated. This is particularly true if
|
||||
your submission is has some very subtle obfuscations that we might
|
||||
otherwise overlook. <strong><<– Hint!</strong></p>
|
||||
<p>Anyone can format their code into a dense blob. A really clever
|
||||
author will try format their entry using a “normal” formatting style
|
||||
author will try format their submission using a “normal” formatting style
|
||||
such that at first glance (if you squint and don’t look at the details)
|
||||
the code might pass for non-obfuscated C. Deceptive comments,
|
||||
and misleading formatting, in some cases, may be a plus. On the
|
||||
other hand, a misleading code style requires more source bytes.</p>
|
||||
<p>If you do elect to use misleading formatting and comments, we
|
||||
suggest you remark on this point in your remarks where you talk
|
||||
about why you think your entry is obfuscated. On the other hand,
|
||||
about why you think your submission is obfuscated. On the other hand,
|
||||
if you are pushing up against the size limits, you may be forced
|
||||
into creating a dense blob. Such are the trade-offs that obfuscators face!</p>
|
||||
<p>We prefer code that can run on either a 64-bit or 32-bit processor.
|
||||
@@ -859,48 +894,49 @@ interesting than simply implementing the IOCCC size tool algorithm.</p>
|
||||
to pick, choose a 64-bit word size.</p>
|
||||
<p>If we 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 entry
|
||||
an emulator of 60-bit CDC Cyber CPU, we might just try your submission
|
||||
on that emulator as well :-)</p>
|
||||
<p>If your entry MUST run only in 32-bit mode on an Intel processor, add the
|
||||
<p>If your submission MUST run only in 32-bit mode on an Intel processor, add the
|
||||
following compiler flag:</p>
|
||||
<pre><code> -arch i386</code></pre>
|
||||
<p>to your “how to build” make compile line. For example:</p>
|
||||
<pre><code> prog: prog.c
|
||||
${CC} prog.c -arch i386 -o prog</code></pre>
|
||||
<p>Be even more creative!</p>
|
||||
<p><strong><code>|</code></strong> If there are limitations in your entry, you are highly encouraged
|
||||
<p><strong><code>|</code></strong> If there are limitations in your submission, you are highly encouraged
|
||||
to note such limitations in your <code>remarks.md</code> file. For example if your
|
||||
entry factors values up to a certain size, you might want to state:</p>
|
||||
<pre><code> This entry factors values up 2305567963945518424753102147331756070.
|
||||
submission factors values up to a certain size, you might want to state:</p>
|
||||
<pre><code> This submission factors values up 2305567963945518424753102147331756070.
|
||||
Attempting to factor larger values will produce unpredictable results.</code></pre>
|
||||
<p>The judges might try to factor the value -5, so you want to might state:</p>
|
||||
<pre><code> This entry factors positive values up 2305567963945518424753102147331756070.
|
||||
<pre><code> This submission factors positive values up 2305567963945518424753102147331756070.
|
||||
Attempting to factor large values will produce unpredictable results.</code></pre>
|
||||
<p>However the judges might try to also factor 0, so you want to might state:</p>
|
||||
<pre><code> This entry factors values between 1 and 2305567963945518424753102147331756070.
|
||||
<pre><code> This submission factors values between 1 and 2305567963945518424753102147331756070.
|
||||
Attempting to factor values outside that range will produce unpredictable results.</code></pre>
|
||||
<p>Moreover the try to also factor 3.5 or 0x7, or Fred, so you want to might state:</p>
|
||||
<pre><code> This entry factors integers between 1 and 2305567963945518424753102147331756070.
|
||||
<pre><code> This submission factors integers between 1 and 2305567963945518424753102147331756070.
|
||||
Attempting to factor anything else will produce unpredictable results.</code></pre>
|
||||
<p>You entry might be better off catching the attempt to factor bogus values
|
||||
<p>You submission might be better off catching the attempt to factor bogus values
|
||||
and doing something interesting. So you might want to code accordingly and state:</p>
|
||||
<pre><code> This entry factors integers between 1 and 2305567963945518424753102147331756070.
|
||||
<pre><code> This submission factors integers between 1 and 2305567963945518424753102147331756070.
|
||||
Attempting to factor anything else will cause the program to insult your pet fish Eric.</code></pre>
|
||||
<p>The judges might not have a pet fish named Eric, so might want to state:</p>
|
||||
<pre><code> This entry factors integers between 1 and 2305567963945518424753102147331756070.
|
||||
<pre><code> This submission factors integers between 1 and 2305567963945518424753102147331756070.
|
||||
Attempting to factor anything else will cause the program to insult your pet fish Eric,
|
||||
or in the case that you lack such a pet, will insult the pet that you do not have.</code></pre>
|
||||
<p>When all other things are equal, an entry with fewer limitations will be judged
|
||||
better than an entry with lots of limitations. So you might want to code accordingly
|
||||
<p>When all other things are equal, an submission with fewer limitations will be judged
|
||||
better than an submission with lots of limitations. So you might want to code accordingly
|
||||
and state:</p>
|
||||
<pre><code> This entry attempts to a factor value of any size provided that the program is
|
||||
<pre><code> This submission attempts to a factor value of any size provided that the program is
|
||||
given enough time and memory. If the value is not a proper integer, the program
|
||||
might insult a fish named Eric.</code></pre>
|
||||
<p><strong><code>|</code></strong> Do not fear if you not 100% sure of the significance of <code>2305567963945518424753102147331756070</code> as it is not of prime importance: or is it? :-)</p>
|
||||
<p><strong><code>|</code></strong> We <strong>DISLIKE</strong> the use of use ASCII tab characters in markdown files, such as in the required <code>remarks.md</code> file.</p>
|
||||
<p><strong><code>|</code></strong> 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 annoys us when be comes to rendering your markdown content.</p>
|
||||
<p><strong><code>|</code></strong> 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 character tab stop.</p>
|
||||
<p><strong><code>|</code></strong> We <strong>LIKE</strong> a reading <code>remarks.md</code> files, especially if they contain useful, informative, and even humorous content about your entry. Yes, this is a <strong>hint</strong>. :-)</p>
|
||||
<p><strong><code>|</code></strong> <strong>PLEASE</strong> observe our <a href="../markdown.html">IOCCC markdown guidelines</a> when forming your submission’s <code>remarks.md</code> file. And if your submission contains additional markdown files, please follow those same guidelines. See also <a href="rules.html#rule19">Rule 19</a>.</p>
|
||||
<p><strong><code>|</code></strong> We <strong>LIKE</strong> a reading <code>remarks.md</code> files, especially if they contain useful, informative, and even humorous content about your submission. Yes, this is a <strong>hint</strong>. :-)</p>
|
||||
<p><strong><code>|</code></strong> We <strong>RECOMMEND</strong> you put a reasonable amount effort into the content of the <code>remarks.md</code> file: it is a required for for a reason. :-)</p>
|
||||
<h1 id="abusing-the-rules">ABUSING THE RULES:</h1>
|
||||
<p>Legal abuse of the <a href="rules.html">IOCCC rules</a> is somewhat encouraged. Legal rule abuse
|
||||
@@ -911,27 +947,27 @@ submitted.</p>
|
||||
entries, regardless of if they receive an award, result in changes to
|
||||
the next year’s <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</a>.</p>
|
||||
<p>Legal abuse of the <a href="rules.html">IOCCC rules</a> is NOT an invitation to violate the
|
||||
<a href="rules.html">IOCCC rules</a>. An entry that violates the <a href="rules.html">rules</a> in the
|
||||
<a href="rules.html">IOCCC rules</a>. An submission that violates the <a href="rules.html">rules</a> in the
|
||||
opinion of the judges, <strong>WILL</strong> be
|
||||
disqualified. <strong><em>RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!</em></strong> If you
|
||||
have an entry that might otherwise be interesting, you might want to
|
||||
have an submission that might otherwise be interesting, you might want to
|
||||
submit two versions; one that does not abuse the <a href="rules.html">IOCCC rules</a> and one that
|
||||
does.</p>
|
||||
<p><strong><code>|</code></strong> If you intend to abuse the <a href="rules.html">IOCCC rules</a>,
|
||||
indicate so in your <code>remarks.md</code> file. You <strong>MUST</strong> try to justify
|
||||
why you consider your rule abuse to be allowed under the
|
||||
<a href="rules.html">IOCCC rules</a>. That is, you must plead your case as to why
|
||||
your entry is valid. Humor and/or creativity help plead a case.
|
||||
your submission is valid. Humor and/or creativity help plead a case.
|
||||
As there is no guarantee that you will succeed, you might consider
|
||||
submitting an alternate version that conforms to the
|
||||
<a href="rules.html">IOCCC rules</a>.</p>
|
||||
<p><strong><code>|</code></strong> If 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 an entry anyway, you <strong>MUST</strong> try to justify why the IOCCC
|
||||
judges should not reject your entry due to a rule violation.</p>
|
||||
and submit an submission anyway, you <strong>MUST</strong> try to justify why the IOCCC
|
||||
judges should not reject your submission due to a rule violation.</p>
|
||||
<p>Abusing the web submission procedure tends to annoy us more
|
||||
than amuse us. Spend your creative energy on content of your
|
||||
entry rather than on the submission process itself.</p>
|
||||
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
|
||||
<a href="guidelines.html">IOCCC guidelines</a> seem too
|
||||
strange or contain mistakes, flaws or grammatical errors. One reason
|
||||
@@ -954,8 +990,8 @@ 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>
|
||||
<h1 id="judging-process">JUDGING PROCESS:</h1>
|
||||
<p>Entries are judged by Leonid A. Broukhis and Landon Curt Noll.</p>
|
||||
<p>Each entry submitted is given a random id number and subdirectory. The
|
||||
entry files including, but not limited to prog.c, Makefile (that we
|
||||
<p>Each submission submitted is given a random id number and subdirectory. The
|
||||
submission files including, but not limited to prog.c, Makefile (that we
|
||||
form from around your “how to build” information), as well as any
|
||||
data files that you submit are all placed under their own directory
|
||||
stored and judged from this directory.</p>
|
||||
@@ -965,7 +1001,7 @@ won an award. Because we do not read this information for entries that
|
||||
do not win, we do not know who did not win.</p>
|
||||
<p>The above process helps keep us biased for/against any one particular
|
||||
individual. Therefore you <strong>MUST</strong> refrain from putting any information
|
||||
that reveals your identity in your entry.</p>
|
||||
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>
|
||||
@@ -975,12 +1011,12 @@ Honeyman</a>. The judges are on to this trick
|
||||
and therefore consider any obfuscated source or data file claiming to be from
|
||||
Honeyman to not be form Honeyman. This of course creates an interesting paradox
|
||||
known as the “obfuscated Peter Honeyman paradox”. Should Peter Honeyman
|
||||
actually submit an obfuscated entry, he alone is excluded from the above, as we
|
||||
actually submit an obfuscated submission, he alone is excluded from the above, as we
|
||||
will likely believe it just another attempt at confusion. This <em>guideline</em> is
|
||||
known as the “Peter Honeyman is exempt” <em>guideline</em>.</p>
|
||||
<p>BTW: None of the entries claiming to be from Peter Honeyman have ever
|
||||
won an award. So it is theoretically possible that Peter Honeyman
|
||||
did submit an entry in the past. In the past, Peter had denied
|
||||
did submit an submission in the past. In the past, Peter had denied
|
||||
submitting anything to the IOCCC. Perhaps those entries were
|
||||
submitted by one of his students?</p>
|
||||
<p><strong><code>|</code></strong> Hopefully we are <strong>VERY CLEAR</strong> on this point! The rules now strongly state:
|
||||
@@ -1003,7 +1039,7 @@ account</a>.</p>
|
||||
the collection of entries are divided into two roughly equal piles;
|
||||
the pile that advances on to the next round, and the pile that does
|
||||
not. We also re-examine the entries that were eliminated in the
|
||||
previous round. Thus, an entry gets at least two readings.</p>
|
||||
previous round. Thus, an submission gets at least two readings.</p>
|
||||
<p>A reading consists of a number of actions:</p>
|
||||
<ul>
|
||||
<li>reading the “how to build” information and forming a Makefile</li>
|
||||
@@ -1023,11 +1059,11 @@ skipping over any #include files</li>
|
||||
miscellaneous tests on the source and binary.</p>
|
||||
<p><strong><code>|</code></strong> This is the very <em>guideline</em> that goes, BING!</p>
|
||||
<p>Until we reduce the stack of entries down to about 25 entries, entries
|
||||
are judged on an individual basis. An entry is set aside because it
|
||||
are judged on an individual basis. An submission is set aside because it
|
||||
does not, in our opinion, meet the standard established by the round.
|
||||
When the number of entries thins to about 25 entries, we begin to form
|
||||
award categories. Entries begin to compete with each other for awards.
|
||||
An entry will often compete in several categories.</p>
|
||||
An submission will often compete in several categories.</p>
|
||||
<p>The actual award category list will vary depending on the types of entries
|
||||
we receive. A typical category list might be:</p>
|
||||
<ul>
|
||||
@@ -1054,28 +1090,28 @@ half that number: declaring those remaining to be winners.</p>
|
||||
the final round are definitely better than the ones that do not
|
||||
make it. The selection of the winners out of the final round, is
|
||||
less clear cut.</p>
|
||||
<p>Sometimes a final round entry is good enough to win, but is beat out
|
||||
by a similar, but slightly better entry. For this reason, it is
|
||||
sometimes worthwhile to re-enter an improved version of an entry
|
||||
<p>Sometimes a final round submission is good enough to win, but is beat out
|
||||
by a similar, but slightly better submission. For this reason, it is
|
||||
sometimes worthwhile to re-enter an improved version of an submission
|
||||
that failed to win in a previous year. This assumes, of course,
|
||||
that the entry is worth improving in the first place!</p>
|
||||
that the submission is worth improving in the first place!</p>
|
||||
<p>More than one IOCCC judge has been known to bribe another IOCCC judge
|
||||
into voting for a winning entry by offering a bit high quality chocolate.
|
||||
into voting for a winning submission by offering a bit high quality chocolate.
|
||||
This technique is highly discouraged for use by non-IOCCC judges.</p>
|
||||
<p>More often than not, we select a small entry (usually one line), a
|
||||
strange/creative layout entry. We sometimes also select an
|
||||
entry that abuses the <a href="guidelines.html">IOCCC guidelines</a> in an interesting way,
|
||||
<p>More often than not, we select a small submission (usually one line), a
|
||||
strange/creative layout submission. We sometimes also select an
|
||||
submission that abuses the <a href="guidelines.html">IOCCC guidelines</a> in an interesting way,
|
||||
or that stretches the content rules that while legal, is
|
||||
nevertheless goes against the intent of the rules.</p>
|
||||
<p>In the end, we traditionally pick one entry as ‘best’. Sometimes such
|
||||
an entry simply far exceeds any of the other entries. More often, the
|
||||
<p>In the end, we traditionally pick one submission as ‘best’. Sometimes such
|
||||
an submission simply far exceeds any of the other entries. More often, the
|
||||
‘best’ is picked because it does well in a number of categories.</p>
|
||||
<p>In years past, we renamed the winning entry from prog.c to a
|
||||
<p>In years past, we renamed the winning submission from prog.c to a
|
||||
name related to the submitter(s) names. This is no longer done.
|
||||
Winning source is called prog.c A compiled binary is called prog.</p>
|
||||
<h1 id="announcement-of-winners">ANNOUNCEMENT OF WINNERS:</h1>
|
||||
<p>The judges 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 of the winning submission
|
||||
from the <a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> Mastodon account</a>. You should
|
||||
follow us on Mastodon and refresh the page (even if you do follow us) as unless
|
||||
you are mentioned you will not get a notification.</p>
|
||||
|
||||
+198
-142
@@ -68,25 +68,41 @@ The rules are typically published along with the [IOCCC guidelines](guidelines.h
|
||||
**`|`** The reason for the times of day are so that key IOCCC events are **calculated**
|
||||
for be a **fun**ctional UTC time. :-)
|
||||
|
||||
Until the start of this IOCCC, the [IOCCC rules](rules.html), [IOCCC guidelines](guidelines.html) and `iocccsize.c`
|
||||
(contained in the [mkiocccentry
|
||||
toolkit](https://github.com/ioccc-src/mkiocccentry))
|
||||
tool should be considered provisional **BETA** versions and **may be
|
||||
adjusted _AT ANY TIME_**.
|
||||
|
||||
The IOCCC submission URL is <https://submit.ioccc.org/>.
|
||||
**`|`** Until the start of this IOCCC, the [IOCCC rules](rules.html),
|
||||
[IOCCC guidelines](guidelines.html) tools in the
|
||||
[mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry), tool should be
|
||||
considered provisional **BETA** versions and **may be adjusted _AT
|
||||
ANY TIME_**.
|
||||
|
||||
**`|`** The submit URL should be active on or slightly before **2024-MMM-DD HH:MM:SS UTC**.<br>
|
||||
**`|`** **XXX - date/time is TBD - XXX**
|
||||
|
||||
Please wait to submit your entries until after that time.
|
||||
**`|`** The [IOCCC rules](rules.html), [IOCCC
|
||||
guidelines](guidelines.html) will be available on the official IOCCC
|
||||
website on or slightly before start of this IOCCC. Please check
|
||||
the IOCCC [FAQ about how to submit](../faq.html#submit) to see how
|
||||
to submit entries, on or after the start of this IOCCC, to be sure
|
||||
you are using the correct versions of these items before using the
|
||||
IOCCC submission URL.
|
||||
|
||||
The [IOCCC rules](rules.html), [IOCCC guidelines](guidelines.html) and iocccsize.c (invoked by the mkiocccentry)
|
||||
tool will be available on the official IOCCC website on or slightly before start
|
||||
of this IOCCC. Please check the IOCCC [FAQ about how to submit](../faq.html#submit)
|
||||
to see how to submit entries, on or after the start of this IOCCC, to be sure
|
||||
you are using the correct versions of these items before using the IOCCC entry
|
||||
submission URL.
|
||||
**`|`** The [Rule 2a](rules.html#rule2a) size has **increased from 4096 to 4993** bytes.
|
||||
|
||||
**`|`** The [Rule 2b](rules.html#rule2b) size has **increased from 2053 to 2503** bytes.
|
||||
|
||||
**`|`** Use default way to compile submissions is now `-std=gnu17 -O3 -g3 -Wall -Wextra -pedantic`.
|
||||
|
||||
**`|`** Submissions are in the form of a single bzip2 compressed tarball.
|
||||
|
||||
**`|`** To assist in the formation of the bzip2 compressed tarball for submission, use the
|
||||
`mkiocccentry(1)` tool as found in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
|
||||
|
||||
**`|`** [Rule 17](rules.html#rule17) as been significantly modified
|
||||
to account for the new [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) tools.
|
||||
|
||||
**`|`** An [example Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example)
|
||||
is now available from the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
|
||||
|
||||
**`|`** The IOCCC submission URL, [when the IOCCC is open](../status.html), is [submit.ioccc.org](https://submit.ioccc.org/).
|
||||
|
||||
|
||||
# HINTS AND SUGGESTIONS:
|
||||
@@ -98,8 +114,8 @@ Keep in mind that rules change from year to year, so some winning entries
|
||||
might not be valid entries this year. What _was_ unique and novel one year
|
||||
_might be 'old' the next year_.
|
||||
|
||||
An entry is usually examined in a number of ways. We typically apply
|
||||
a number of tests to an entry:
|
||||
An submission is usually examined in a number of ways. We typically apply
|
||||
a number of tests to an submission:
|
||||
|
||||
* look at the original source
|
||||
* convert ANSI trigraphs to ASCII
|
||||
@@ -110,15 +126,15 @@ a number of tests to an entry:
|
||||
* compile it (with flags to enable all warnings)
|
||||
* execute it
|
||||
|
||||
You should consider how your entry looks in each of the above tests.
|
||||
You should ask yourself if your entry remains obscure after it has been
|
||||
You should consider how your submission looks in each of the above tests.
|
||||
You should ask yourself if your submission remains obscure after it has been
|
||||
'_cleaned up_' by the C pre-processor and a C beautifier.
|
||||
|
||||
Your entry need not pass all of the above tests. In certain
|
||||
Your submission need not pass all of the above tests. In certain
|
||||
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 entry that
|
||||
two such entries, we are more inclined to pick the submission that
|
||||
does something interesting when you run it.
|
||||
|
||||
We try to avoid limiting creativity in our rules. As such, we leave
|
||||
@@ -126,7 +142,7 @@ the contest open for creative rule interpretation. As in [real
|
||||
life](https://en.wikipedia.org/wiki/Real_life)
|
||||
programming, interpreting a requirements document or a customer request
|
||||
is important. For this reason, we often award '_Best abuse of the
|
||||
rules_' or '_Worst abuse of the rules_' to an entry that illustrates this point
|
||||
rules_' or '_Worst abuse of the rules_' to an submission that illustrates this point
|
||||
in an ironic way.
|
||||
|
||||
We do realize that there are holes in the rules, and invite entries
|
||||
@@ -138,19 +154,19 @@ to attempt to exploit them. We will award '_Worst abuse of the rules_' or
|
||||
**`|`** There may be less than 2^7+1 reasons why these [IOCCC guidelines](guidelines.html) seem obfuscated.
|
||||
|
||||
Check out your program and be sure that it works. We sometimes make
|
||||
the effort to debug an entry that has a slight problem, particularly
|
||||
the effort to debug an 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.
|
||||
|
||||
**`|`** 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
|
||||
documenting it. Noting "_this entry sometimes prints the 4th power
|
||||
of a prime by mistake_" would save the above entry. And sometimes,
|
||||
a strange bug/feature can even help the entry! Of course, a correctly
|
||||
working entry is best. Clever people will note that 16 might be prime
|
||||
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
|
||||
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 entry's `remarks.md` file.
|
||||
will fully explain such cleverness in their submission's `remarks.md` file.
|
||||
|
||||
People who are considering to just use some complex mathematical
|
||||
function or state machine to spell out something such as "_hello,
|
||||
@@ -168,16 +184,16 @@ are considered more portable.
|
||||
|
||||
**`|`** [Rule 2](rules.html#rule2) (the size rule) refers to the use of the IOCCC size tool called `iocccsize(1)`.
|
||||
|
||||
**`|`** See the [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) for the `iocccsize(1)` tool.
|
||||
**`|`** See the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) for the `iocccsize(1)` tool.
|
||||
|
||||
**`|`** To further clarify [Rule 2](rules.html#rule2), we subdivided it into two parts, **2a** and **2b**.
|
||||
|
||||
**`|`** The overall size limit (see [Rule 2a](rules.html#rule2a)) on `prog.c` is now **4993 bytes**.
|
||||
|
||||
**`|`** Your entry must satisfy BOTH the maximum size [Rule 2a](rules.html#rule2a) AND your entry
|
||||
**`|`** Your submission must satisfy BOTH the maximum size [Rule 2a](rules.html#rule2a) AND your submission
|
||||
must satisfy the IOCCC size tool [Rule 2b](rules.html#rule2b).
|
||||
|
||||
This tool imposes a 2nd limit on C code size (see [Rule 2a](rules.html#rule2a). To check your
|
||||
**`|`** This IOCCC size tool imposes a 2nd limit on C code size (see [Rule 2a](rules.html#rule2a). To check your
|
||||
code against the 2nd limit of [Rule 2](rules.html#rule2), use the -i command line option.
|
||||
For example:
|
||||
|
||||
@@ -217,25 +233,94 @@ to get around the size limits of [Rule 2](rules.html#rule2).
|
||||
|
||||
Yes Virginia, **that is a hint**!
|
||||
|
||||
**`|`** 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-2020 IOCCC era](../faq.html#size_rule).
|
||||
**`|`** 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-2020 IOCCC era](../faq.html#size_rule).
|
||||
|
||||
We applaud programs that do not issue warnings when compiled.
|
||||
To avoid warnings, you might be tempted to add various `-Wno-foobar`
|
||||
flags. Unfortunately such flags are NOT portable. Moreover,
|
||||
such flags are not consistent between different C compilers.
|
||||
Therefore we recommend that you consider one of several approaches:
|
||||
**`|`** We recommend that you use the
|
||||
[example Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example)
|
||||
from the [IOCCC mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
|
||||
renamed as `Makefile` of course, as the starting point for your submissions
|
||||
required `Makefile`. Feel free to modify the Makefile to suit your obfuscated needs.
|
||||
|
||||
a) Write code that does not generate compiler warnings (but see [the FAQ about
|
||||
clang -Weverything](../faq.html#faq3_11))
|
||||
b) Do not use flags that disable compiler warnings
|
||||
c) Provide instructions (such as in your Makefile) that
|
||||
use the appropriate disable compiler warnings flags for
|
||||
both clang and gcc
|
||||
d) Do something creative
|
||||
**`|`** The rest of these guidelines will assume that you are using some variant of the
|
||||
[example Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example),
|
||||
renamed as `Makefile` of course.
|
||||
|
||||
**`|`** We suggest that you compile your submission with a commonly available
|
||||
`-std=gnu17` (ISO C 2017 with GNU extensions) C compiler.
|
||||
|
||||
**`|`** Unless you clearly state otherwise in your `remarks.md` file AND put into your
|
||||
submission's `Makefile`, we will compile using `-O3 -std=gnu17`.
|
||||
|
||||
**`|`** It is **OK** to require your submission to not be compiled
|
||||
using the default `-O3 -g3 -std=gnu17` settings. Simply explain why
|
||||
your submission should not be compiled using `-O3 -g3 -std=gnu17` in
|
||||
your `remarks.md` file and adjust your `Makefile` accordingly.
|
||||
|
||||
**`|`** **IMPORTANT NOTE**: The use of `-std=gnu17` does **NOT** imply the use of the `gcc`
|
||||
compiler! We often start by compiling using the **clang** C compiler instead.
|
||||
|
||||
**`|`** You may change the standard under which your submission is compiled
|
||||
by modifying the `CSTD` Makefile variable. For example, to use `c17` instead:
|
||||
|
||||
```
|
||||
CSTD= -std=c17
|
||||
```
|
||||
|
||||
**`|`** For compilers, such as clang, that have the `-Weverything` option,
|
||||
while you try wish it, **HOWEVER** see the [FAQ about clang -Weverything](../faq.html#weverything).
|
||||
Thus, we do **NOT** recommend that you put the use of `-Weverything` into
|
||||
your submission's `Makefile`.
|
||||
|
||||
**`|`** You may change the level of optimization and compiler debug level
|
||||
which your submission is compiled by modifying the `COPT` Makefile variable.
|
||||
For example, to compile without optimization:
|
||||
|
||||
```
|
||||
COPT= -O0 -g3
|
||||
```
|
||||
|
||||
**`|`** There is no real penalty for compiler warnings. Sometimes
|
||||
compiler warnings cannot be helped: especially in the case of
|
||||
obfuscated C. :-) So if you cannot easily get rid of a compiler
|
||||
warning, try not fret too much.
|
||||
|
||||
**`|`** To turn off a compiler warning, to your submission's `Makefile`,
|
||||
try something such as:
|
||||
|
||||
```
|
||||
CSILENCE= -Wno-some-thing -Wno-another-thing -Wno-unknown-warning-option
|
||||
```
|
||||
|
||||
**`|`** If you do add "`-Wno-some-thing`" to your Makefile,
|
||||
consider also adding `-Wno-unknown-warning-option` just in case the
|
||||
warning you use is not available in the compilers we use test your
|
||||
submission.
|
||||
|
||||
**`|`** If you need to define something on the compile line, use
|
||||
the `CDEFINE` Makefile variable. For example:
|
||||
|
||||
```
|
||||
CDEFINE= -Dfoo -Dbar=baz
|
||||
```
|
||||
|
||||
**`|`** If need add other "_magic_" flags to your compile line,
|
||||
use the `COTHER` Makefile variable. For example:
|
||||
|
||||
```
|
||||
COTHER= -include stdio.h
|
||||
```
|
||||
|
||||
|
||||
# OUR LIKES AND DISLIKES:
|
||||
|
||||
**`|`** We **LIKE** entries that use an edited variant of the
|
||||
[example Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example),
|
||||
renamed as `Makefile` of course. This makes it easier for the [IOCCC Judges](../judges.html)
|
||||
to test your submission. And if your submissions wins, integrate it into
|
||||
the [Official IOCCC winner website](https://www.ioccc.org/index.html).
|
||||
|
||||
Doing masses of `#defines` to obscure the source has become 'old'. We
|
||||
tend to 'see thru' masses of `#defines` due to our pre-processor tests
|
||||
that we apply. Simply abusing `#defines` or `-Dfoo=bar` won't go as far
|
||||
@@ -255,56 +340,26 @@ When declaring local or global variables, you should declare the type:
|
||||
this_is_not; /* <-- Try to avoid implicit type declarations */
|
||||
```
|
||||
|
||||
**`|`** We suggest that you compile your entry with a commonly available
|
||||
gnu17 (ISO C 2017 with GNU extensions) C compiler.
|
||||
|
||||
We really **LIKE** code that has a minimum of warnings, especially under the
|
||||
**`|`** We **LIKE** code that has a minimum of warnings, especially under the
|
||||
more strict ` -Wall -Wextra -pedantic` mode:
|
||||
|
||||
```
|
||||
-Wall -Wextra -pedantic
|
||||
CWARN= -Wall -Wextra -pedantic
|
||||
```
|
||||
|
||||
For compilers, such as clang, that have the `-Weverything` option, try
|
||||
to make your code compile warning free using:
|
||||
|
||||
```
|
||||
-Wall -Wextra -Weverything -pedantic
|
||||
```
|
||||
|
||||
.. though, again, see [the FAQ about clang -Weverything](../faq.html#faq3_11) in
|
||||
the [FAQ](../faq.html).
|
||||
|
||||
|
||||
If you must turn off various warnings on the compile line such as:
|
||||
|
||||
```
|
||||
... -Wno-empty-body -Wno-return-type ...
|
||||
```
|
||||
|
||||
**`|`** be sure to clearly state so in your `remarks.md` file **AS WELL AS** in
|
||||
your `Makefile`.
|
||||
|
||||
All other things being equal, a program that must turn off fewer
|
||||
warnings will be considered better, for certain values of better.
|
||||
|
||||
**`|`** Unless you clearly state otherwise in your `remarks.md` file **AS WELL AS** in
|
||||
your "how to build" / Makefile we will compile using:
|
||||
**`|`** We tend to **like less** a submission that requires either
|
||||
**gcc** or **clang**. We prefer submissions that can compile
|
||||
under both **gcc** and **clang**.
|
||||
|
||||
```
|
||||
-O3 -std=gnu17
|
||||
```
|
||||
**`|`** We **RECOMMEND** that the compiler flags you use in your
|
||||
submission's `Makefile` are supported by both **gcc** and **clang**.
|
||||
|
||||
**`|`** There is no real penalty for compiler warnings. Sometimes compiler warnings cannot be helped: especially in the case of obfuscated C. :-) So if you cannot easily get rid of a compiler warning, try not fret too much. Just add the needed "`-Wno-somethings`" to your Makefile. We suggest you add then to the `CSILENCE=` line, if you use some variant of the [example Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example) from the [IOCCC mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
|
||||
|
||||
**`|`** If you do add "`-Wno-somethings`" to your Makefile, consider also adding `-Wno-unknown-warning-option` just in case the warning you use is not available in the compilers we use test your submission.
|
||||
|
||||
**`|`** **DO NOT** assume that we will use **gcc** to compile your program.
|
||||
We will first try to compile your program using **clang**.
|
||||
|
||||
It is much better to not use any obscure compiler flags if
|
||||
you can help it. We want to discourage the use of obscure compiler
|
||||
flags that would make the program less portable.
|
||||
**`|`** We **DISLIKE** the use of obscure compiler flags, especially
|
||||
if either **gcc** or **clang** does not support it. We **suggest**
|
||||
that you not use any really obscure compiler flags if you can help it.
|
||||
|
||||
One side effect of the above is that you cannot assume the use
|
||||
of nested functions such as:
|
||||
@@ -318,18 +373,17 @@ of nested functions such as:
|
||||
}
|
||||
```
|
||||
|
||||
This is because such nested functions often requires one to compile with
|
||||
a flag such as `-fnested-functions` that is not found on some compilers.
|
||||
|
||||
On 2012 July 20, the judges rescinded the encouragement of
|
||||
**`|`** On 2012 July 20, the judges 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
|
||||
actually implemented in commonly used C compilers. Sorry!
|
||||
actually implemented in both **gcc** and **clang**.
|
||||
|
||||
**`|`** We **DISLIKE** submissions require the use of `-fnested-functions`.
|
||||
|
||||
We prefer programs that do not require a fish license: crayons and
|
||||
cat detector vans not withstanding.
|
||||
|
||||
If your entry uses functions that have a variable number of
|
||||
If your submission uses functions that have a variable number of
|
||||
arguments, be careful. Systems implement `va_list` as a wide variety
|
||||
of ways. Because of this, a number of operations using `va_list` are
|
||||
not portable and must not be used:
|
||||
@@ -349,7 +403,7 @@ On 28 January 2007, the Judges rescinded the requirement that the
|
||||
`#` in a C preprocessor directive must be the 1st non-whitespace octet.
|
||||
|
||||
The `exit(3)` function returns `void`. Some broken systems have `exit(3)`
|
||||
return `int`, your entry should assume that `exit(3)` returns a `void`.
|
||||
return `int`, your submission should assume that `exit(3)` returns a `void`.
|
||||
|
||||
**`|`** This _guideline_ has a change mark at the very start of this line.
|
||||
|
||||
@@ -374,7 +428,7 @@ We tend to **DISLIKE** programs that:
|
||||
|
||||
* are very hardware specific
|
||||
* are very OS version specific (index/strchr differences are OK, but socket/streams specific code is likely not to be)<br>
|
||||
**`|`** * dump core or have compiler warnings (it is OK only if you warn us in your 'remark,md' file)<br>
|
||||
**`|`** * dump core or have compiler warnings (it is OK only if you warn us in your 'remark.md' file)<br>
|
||||
**`|`** * won't compile or run a [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environment
|
||||
* depend on a utility or application not normally found systems that conform to the [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
|
||||
* abuse the build file to get around the size limit<br>
|
||||
@@ -387,10 +441,10 @@ We tend to **DISLIKE** programs that:
|
||||
* that mandate the exclusive the use of an specific Integrated
|
||||
* Development Environment (IDE)
|
||||
|
||||
In order to encourage entry portability, we **DISLIKE** entries that
|
||||
In order to encourage submission portability, we **DISLIKE** entries that
|
||||
fail to build unless one is using an IDE. For example, do not
|
||||
mandate that one must use Microsoft Visual Studio to compile
|
||||
your entry. Nevertheless some of the better IDEs have command-line
|
||||
your submission. Nevertheless some of the better IDEs have command-line
|
||||
interfaces to their compilers, once one learns how to invoke a shell.
|
||||
|
||||
**`|`** The program must compile and link cleanly in a [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environment Therefore do not assume the system has a
|
||||
@@ -441,7 +495,7 @@ There are at least zero judges who think that Fideism has little
|
||||
or nothing to do with the IOCCC judging process.
|
||||
|
||||
Don't forget that the building of your program should be done
|
||||
***WITHOUT human intervention***. So don't do things such as:
|
||||
**WITHOUT human intervention**. So don't do things such as:
|
||||
|
||||
```
|
||||
prog: prog.c
|
||||
@@ -489,10 +543,10 @@ 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 entry. See the [IOCCC rules](rules.html) for details.
|
||||
Remember, you can submit more than one submission. See the [IOCCC rules](rules.html) for details.
|
||||
|
||||
We suggest that you avoid trying for the 'smallest self-replicating'
|
||||
source. The smallest, a zero byte entry, [won in 1994](../1994/smr/index.html).
|
||||
source. The smallest, a zero byte submission, [won in 1994](../1994/smr/index.html).
|
||||
|
||||
Programs that claim to be the smallest C source that does something, really
|
||||
better be the smallest such program or they risk being rejected because
|
||||
@@ -591,7 +645,7 @@ Some types of programs can't excel (anti-tm) in some areas. Your
|
||||
program doesn't have to excel in all areas, but doing well in several
|
||||
areas really does help.
|
||||
|
||||
**`|`** You are better off explaining what your entry does in your
|
||||
**`|`** You are better off explaining what your submission does in your
|
||||
`remarks.md` file section rather than leaving it obscure for the judges
|
||||
as we might miss something and/or be too tired to notice.
|
||||
|
||||
@@ -628,12 +682,12 @@ Instead of unescaped octets, you should use \octal or \hex escapes:
|
||||
```
|
||||
|
||||
**`|`** It is a very good idea to, in your `remarks.md` file, tell us why you
|
||||
think your entry is obfuscated. This is particularly true if
|
||||
your entry is has some very subtle obfuscations that we might
|
||||
think your submission is obfuscated. This is particularly true if
|
||||
your submission is has some very subtle obfuscations that we might
|
||||
otherwise overlook. **<<-- Hint!**
|
||||
|
||||
Anyone can format their code into a dense blob. A really clever
|
||||
author will try format their entry using a "normal" formatting style
|
||||
author will try format their submission using a "normal" formatting style
|
||||
such that at first glance (if you squint and don't look at the details)
|
||||
the code might pass for non-obfuscated C. Deceptive comments,
|
||||
and misleading formatting, in some cases, may be a plus. On the
|
||||
@@ -641,7 +695,7 @@ other hand, a misleading code style requires more source bytes.
|
||||
|
||||
If you do elect to use misleading formatting and comments, we
|
||||
suggest you remark on this point in your remarks where you talk
|
||||
about why you think your entry is obfuscated. On the other hand,
|
||||
about why you think your submission is obfuscated. On the other hand,
|
||||
if you are pushing up against the size limits, you may be forced
|
||||
into creating a dense blob. Such are the trade-offs that obfuscators face!
|
||||
|
||||
@@ -669,10 +723,10 @@ to pick, choose a 64-bit word size.
|
||||
|
||||
If we 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 entry
|
||||
an emulator of 60-bit CDC Cyber CPU, we might just try your submission
|
||||
on that emulator as well :-)
|
||||
|
||||
If your entry MUST run only in 32-bit mode on an Intel processor, add the
|
||||
If your submission MUST run only in 32-bit mode on an Intel processor, add the
|
||||
following compiler flag:
|
||||
|
||||
```
|
||||
@@ -688,58 +742,58 @@ to your "how to build" make compile line. For example:
|
||||
|
||||
Be even more creative!
|
||||
|
||||
**`|`** If there are limitations in your entry, you are highly encouraged
|
||||
**`|`** If there are limitations in your submission, you are highly encouraged
|
||||
to note such limitations in your `remarks.md` file. For example if your
|
||||
entry factors values up to a certain size, you might want to state:
|
||||
submission factors values up to a certain size, you might want to state:
|
||||
|
||||
```
|
||||
This entry factors values up 2305567963945518424753102147331756070.
|
||||
This submission factors values up 2305567963945518424753102147331756070.
|
||||
Attempting to factor larger values will produce unpredictable results.
|
||||
```
|
||||
|
||||
The judges might try to factor the value -5, so you want to might state:
|
||||
|
||||
```
|
||||
This entry factors positive values up 2305567963945518424753102147331756070.
|
||||
This submission factors positive values up 2305567963945518424753102147331756070.
|
||||
Attempting to factor large values will produce unpredictable results.
|
||||
```
|
||||
|
||||
However the judges might try to also factor 0, so you want to might state:
|
||||
|
||||
```
|
||||
This entry factors values between 1 and 2305567963945518424753102147331756070.
|
||||
This submission factors values between 1 and 2305567963945518424753102147331756070.
|
||||
Attempting to factor values outside that range will produce unpredictable results.
|
||||
```
|
||||
|
||||
Moreover the try to also factor 3.5 or 0x7, or Fred, so you want to might state:
|
||||
|
||||
```
|
||||
This entry factors integers between 1 and 2305567963945518424753102147331756070.
|
||||
This submission factors integers between 1 and 2305567963945518424753102147331756070.
|
||||
Attempting to factor anything else will produce unpredictable results.
|
||||
```
|
||||
|
||||
You entry might be better off catching the attempt to factor bogus values
|
||||
You submission might be better off catching the attempt to factor bogus values
|
||||
and doing something interesting. So you might want to code accordingly and state:
|
||||
|
||||
```
|
||||
This entry factors integers between 1 and 2305567963945518424753102147331756070.
|
||||
This submission factors integers between 1 and 2305567963945518424753102147331756070.
|
||||
Attempting to factor anything else will cause the program to insult your pet fish Eric.
|
||||
```
|
||||
|
||||
The judges might not have a pet fish named Eric, so might want to state:
|
||||
|
||||
```
|
||||
This entry factors integers between 1 and 2305567963945518424753102147331756070.
|
||||
This submission factors integers between 1 and 2305567963945518424753102147331756070.
|
||||
Attempting to factor anything else will cause the program to insult your pet fish Eric,
|
||||
or in the case that you lack such a pet, will insult the pet that you do not have.
|
||||
```
|
||||
|
||||
When all other things are equal, an entry with fewer limitations will be judged
|
||||
better than an entry with lots of limitations. So you might want to code accordingly
|
||||
When all other things are equal, an submission with fewer limitations will be judged
|
||||
better than an submission with lots of limitations. So you might want to code accordingly
|
||||
and state:
|
||||
|
||||
```
|
||||
This entry attempts to a factor value of any size provided that the program is
|
||||
This submission attempts to a factor value of any size provided that the program is
|
||||
given enough time and memory. If the value is not a proper integer, the program
|
||||
might insult a fish named Eric.
|
||||
```
|
||||
@@ -752,7 +806,9 @@ and state:
|
||||
|
||||
**`|`** 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 character tab stop.
|
||||
|
||||
**`|`** We **LIKE** a reading `remarks.md` files, especially if they contain useful, informative, and even humorous content about your entry. Yes, this is a **hint**. :-)
|
||||
**`|`** **PLEASE** observe our [IOCCC markdown guidelines](../markdown.html) when forming your submission's `remarks.md` file. And if your submission contains additional markdown files, please follow those same guidelines. See also [Rule 19](rules.html#rule19).
|
||||
|
||||
**`|`** We **LIKE** a reading `remarks.md` files, especially if they contain useful, informative, and even humorous content about your submission. Yes, this is a **hint**. :-)
|
||||
|
||||
**`|`** We **RECOMMEND** you put a reasonable amount effort into the content of the `remarks.md` file: it is a required for for a reason. :-)
|
||||
|
||||
@@ -771,10 +827,10 @@ entries, regardless of if they receive an award, result in changes to
|
||||
the next year's [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html).
|
||||
|
||||
Legal abuse of the [IOCCC rules](rules.html) is NOT an invitation to violate the
|
||||
[IOCCC rules](rules.html). An entry that violates the [rules](rules.html) in the
|
||||
[IOCCC rules](rules.html). An submission that violates the [rules](rules.html) in the
|
||||
opinion of the judges, **WILL** be
|
||||
disqualified. **_RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!_** If you
|
||||
have an entry that might otherwise be interesting, you might want to
|
||||
have an submission that might otherwise be interesting, you might want to
|
||||
submit two versions; one that does not abuse the [IOCCC rules](rules.html) and one that
|
||||
does.
|
||||
|
||||
@@ -782,19 +838,19 @@ does.
|
||||
indicate so in your `remarks.md` file. You **MUST** try to justify
|
||||
why you consider your rule abuse to be allowed under the
|
||||
[IOCCC rules](rules.html). That is, you must plead your case as to why
|
||||
your entry is valid. Humor and/or creativity help plead a case.
|
||||
your submission is valid. Humor and/or creativity help plead a case.
|
||||
As there is no guarantee that you will succeed, you might consider
|
||||
submitting an alternate version that conforms to the
|
||||
[IOCCC rules](rules.html).
|
||||
|
||||
**`|`** If do bypass the `mkiocccentry(1)` warnings about [Rule
|
||||
2a](rules.html#rule2a) and/or about [Rule 2b](rules.html#rule2b)
|
||||
and submit an entry anyway, you **MUST** try to justify why the IOCCC
|
||||
judges should not reject your entry due to a rule violation.
|
||||
and submit an submission anyway, you **MUST** try to justify why the IOCCC
|
||||
judges should not reject your submission due to a rule violation.
|
||||
|
||||
Abusing the web submission procedure tends to annoy us more
|
||||
than amuse us. Spend your creative energy on content of your
|
||||
entry rather than on the submission process itself.
|
||||
submission rather than on the submission process itself.
|
||||
|
||||
We are often asked why the contest [IOCCC rules](rules.html) and
|
||||
[IOCCC guidelines](guidelines.html) seem too
|
||||
@@ -823,8 +879,8 @@ This is one of the reasons why the [IOCCC rules](rules.html) and
|
||||
|
||||
Entries are judged by Leonid A. Broukhis and Landon Curt Noll.
|
||||
|
||||
Each entry submitted is given a random id number and subdirectory. The
|
||||
entry files including, but not limited to prog.c, Makefile (that we
|
||||
Each submission submitted is given a random id number and subdirectory. The
|
||||
submission files including, but not limited to prog.c, Makefile (that we
|
||||
form from around your "how to build" information), as well as any
|
||||
data files that you submit are all placed under their own directory
|
||||
stored and judged from this directory.
|
||||
@@ -836,7 +892,7 @@ do not win, we do not know who did not win.
|
||||
|
||||
The above process helps keep us biased for/against any one particular
|
||||
individual. Therefore you **MUST** refrain from putting any information
|
||||
that reveals your identity in your entry.
|
||||
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
|
||||
@@ -848,13 +904,13 @@ Honeyman](http://www.citi.umich.edu/u/honey). The judges are on to this trick
|
||||
and therefore consider any obfuscated source or data file claiming to be from
|
||||
Honeyman to not be form Honeyman. This of course creates an interesting paradox
|
||||
known as the "obfuscated Peter Honeyman paradox". Should Peter Honeyman
|
||||
actually submit an obfuscated entry, he alone is excluded from the above, as we
|
||||
actually submit an obfuscated submission, he alone is excluded from the above, as we
|
||||
will likely believe it just another attempt at confusion. This _guideline_ is
|
||||
known as the "Peter Honeyman is exempt" _guideline_.
|
||||
|
||||
BTW: None of the entries claiming to be from Peter Honeyman have ever
|
||||
won an award. So it is theoretically possible that Peter Honeyman
|
||||
did submit an entry in the past. In the past, Peter had denied
|
||||
did submit an submission in the past. In the past, Peter had denied
|
||||
submitting anything to the IOCCC. Perhaps those entries were
|
||||
submitted by one of his students?
|
||||
|
||||
@@ -883,7 +939,7 @@ Judging consists of a number of elimination rounds. During a round,
|
||||
the collection of entries are divided into two roughly equal piles;
|
||||
the pile that advances on to the next round, and the pile that does
|
||||
not. We also re-examine the entries that were eliminated in the
|
||||
previous round. Thus, an entry gets at least two readings.
|
||||
previous round. Thus, an submission gets at least two readings.
|
||||
|
||||
A reading consists of a number of actions:
|
||||
|
||||
@@ -906,11 +962,11 @@ miscellaneous tests on the source and binary.
|
||||
**`|`** This is the very _guideline_ that goes, BING!
|
||||
|
||||
Until we reduce the stack of entries down to about 25 entries, entries
|
||||
are judged on an individual basis. An entry is set aside because it
|
||||
are judged on an individual basis. An submission is set aside because it
|
||||
does not, in our opinion, meet the standard established by the round.
|
||||
When the number of entries thins to about 25 entries, we begin to form
|
||||
award categories. Entries begin to compete with each other for awards.
|
||||
An entry will often compete in several categories.
|
||||
An submission will often compete in several categories.
|
||||
|
||||
The actual award category list will vary depending on the types of entries
|
||||
we receive. A typical category list might be:
|
||||
@@ -941,27 +997,27 @@ the final round are definitely better than the ones that do not
|
||||
make it. The selection of the winners out of the final round, is
|
||||
less clear cut.
|
||||
|
||||
Sometimes a final round entry is good enough to win, but is beat out
|
||||
by a similar, but slightly better entry. For this reason, it is
|
||||
sometimes worthwhile to re-enter an improved version of an entry
|
||||
Sometimes a final round submission is good enough to win, but is beat out
|
||||
by a similar, but slightly better submission. For this reason, it is
|
||||
sometimes worthwhile to re-enter an improved version of an submission
|
||||
that failed to win in a previous year. This assumes, of course,
|
||||
that the entry is worth improving in the first place!
|
||||
that the submission is worth improving in the first place!
|
||||
|
||||
More than one IOCCC judge has been known to bribe another IOCCC judge
|
||||
into voting for a winning entry by offering a bit high quality chocolate.
|
||||
into voting for a winning submission by offering a bit high quality chocolate.
|
||||
This technique is highly discouraged for use by non-IOCCC judges.
|
||||
|
||||
More often than not, we select a small entry (usually one line), a
|
||||
strange/creative layout entry. We sometimes also select an
|
||||
entry that abuses the [IOCCC guidelines](guidelines.html) in an interesting way,
|
||||
More often than not, we select a small submission (usually one line), a
|
||||
strange/creative layout submission. We sometimes also select an
|
||||
submission that abuses the [IOCCC guidelines](guidelines.html) in an interesting way,
|
||||
or that stretches the content rules that while legal, is
|
||||
nevertheless goes against the intent of the rules.
|
||||
|
||||
In the end, we traditionally pick one entry as 'best'. Sometimes such
|
||||
an entry simply far exceeds any of the other entries. More often, the
|
||||
In the end, we traditionally pick one submission as 'best'. Sometimes such
|
||||
an submission simply far exceeds any of the other entries. More often, the
|
||||
'best' is picked because it does well in a number of categories.
|
||||
|
||||
In years past, we renamed the winning entry from prog.c to a
|
||||
In years past, we renamed the winning submission from prog.c to a
|
||||
name related to the submitter(s) names. This is no longer done.
|
||||
Winning source is called prog.c A compiled binary is called prog.
|
||||
|
||||
@@ -969,7 +1025,7 @@ Winning source is called prog.c A compiled binary is called prog.
|
||||
# ANNOUNCEMENT OF WINNERS:
|
||||
|
||||
The judges 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 of the winning submission
|
||||
from the [@IOCCC Mastodon account](https://fosstodon.org/@ioccc). You should
|
||||
follow us on Mastodon and refresh the page (even if you do follow us) as unless
|
||||
you are mentioned you will not get a notification.
|
||||
|
||||
+128
-62
@@ -382,13 +382,12 @@
|
||||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
|
||||
<!-- BEFORE: 1st line of markdown file: next/rules.md -->
|
||||
<!-- START: this line starts content from: inc/rules.closed.hdr -->
|
||||
<p>repo START: this line starts content from: inc/rules.closed.hdr –></p>
|
||||
<h1 id="warning-these-rules-are-out-of-date">WARNING: These rules are OUT OF DATE</h1>
|
||||
<p>These rules are a <strong>VERY TENTATIVE proposal</strong> for the next IOCCC
|
||||
and are <strong>VERY LIKELY</strong> to be updated before the next IOCCC.
|
||||
They are are provided as a <strong>very tentative</strong> hint at <strong>what
|
||||
MIGHT</strong> be used in the next IOCCC.</p>
|
||||
<p>Please regard these rules as a historical archive.</p>
|
||||
<h1 id="the-ioccc-is-closed">The IOCCC is closed</h1>
|
||||
<p>The IOCCC is <strong>NOT</strong> accepting new submissions at this time. See the <a href="../years.html">IOCCC
|
||||
winning entries page</a> for the entries that have won the IOCCC in
|
||||
@@ -434,9 +433,9 @@ IOCCC start with the <strong><code>|</code></strong> symbol.</p>
|
||||
<h1 id="important-ioccc-dates">Important IOCCC dates</h1>
|
||||
<p><strong><code>|</code></strong> This IOCCC runs from <strong>2024-MMM-DD HH:MM:SS UTC</strong> to <strong>202x-MMM-DD HH:MM:SS UTC</strong>.<br>
|
||||
<strong><code>|</code></strong> <strong>XXX - date/time is TBD - XXX</strong></p>
|
||||
<p>Until the start of this IOCCC, these <a href="rules.html">IOCCC rules</a>,
|
||||
<p><strong><code>|</code></strong> Until the start of this IOCCC, these <a href="rules.html">IOCCC rules</a>,
|
||||
<a href="guidelines.html">IOCCC guidelines</a> and iocccsize.c (contained in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||||
toolkit</a> and invoked by the
|
||||
repo</a> and invoked by the
|
||||
<code>mkiocccentry(1)</code> tool) should be considered provisional <strong>BETA</strong> versions and
|
||||
<strong>may be adjusted <em>AT ANY TIME</em></strong>.</p>
|
||||
<p>When the IOCCC is open, the submission URL is:
|
||||
@@ -450,10 +449,10 @@ for <strong>important information</strong> on how to submit to the IOCCC.</p>
|
||||
<p>The official <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</a> will be
|
||||
available on the <a href="../index.html">official IOCCC website</a> on or slightly before
|
||||
the start of this IOCCC. The <code>mkiocccentry</code> toolkit may be obtained at any time
|
||||
at the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit repo</a>.</p>
|
||||
at the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>.</p>
|
||||
<p>Please recheck on or after the start of this IOCCC to be sure you
|
||||
are using the correct versions of these items before using the IOCCC
|
||||
entry submission URL.</p>
|
||||
submission URL.</p>
|
||||
<h1 id="ioccc-rules">IOCCC RULES</h1>
|
||||
<p>To help us with the volume of entries, we ask that you follow these rules:</p>
|
||||
<h2 id="rule-0">Rule 0</h2>
|
||||
@@ -461,11 +460,11 @@ entry submission URL.</p>
|
||||
<div id="rule1">
|
||||
<h2 id="rule-1">Rule 1</h2>
|
||||
</div>
|
||||
<p>Your entry must be a complete program.</p>
|
||||
<p>Your submission must be a complete program.</p>
|
||||
<div id="rule2">
|
||||
<h2 id="rule-2">Rule 2</h2>
|
||||
</div>
|
||||
<p>The size rule requires your entry to satisfy <strong>BOTH</strong> <a href="#rule2a">Rule 2a</a> and <a href="#rule2b">Rule 2b</a>:</p>
|
||||
<p>The size rule requires your submission to satisfy <strong>BOTH</strong> <a href="#rule2a">Rule 2a</a> and <a href="#rule2b">Rule 2b</a>:</p>
|
||||
<div id="rule2a">
|
||||
<h2 id="rule-2a">Rule 2a</h2>
|
||||
</div>
|
||||
@@ -490,9 +489,9 @@ as a command like argument to the <code>iocccsize(1)</code> tool. For example:</
|
||||
<p><strong><code>|</code></strong> When the filename of your program source is given as a command line argument to the latest version
|
||||
of the official IOCCC size tool (hereby referred to as <code>iocccsize(1)</code>), the value printed <strong>should not exceed 2503</strong>.</p>
|
||||
<p><strong><code>|</code></strong> The source to <code>iocccsize(1)</code> may be found in the
|
||||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry tool repo</a>.</p>
|
||||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>.</p>
|
||||
<p><strong><code>|</code></strong> If you use the <code>mkiocccentry(1)</code> tool, which we <strong>STRONGLY recommend you use</strong>,
|
||||
then <code>mkiocccentry(1)</code> will invoke <code>iocccsize(1)</code> before packaging your entry for submission.</p>
|
||||
then <code>mkiocccentry(1)</code> will invoke <code>iocccsize(1)</code> before packaging your submission.</p>
|
||||
<p><strong><code>|</code></strong> The <code>mkiocccentry(1)</code> tool will give you the option of overriding the <a href="#rule2b">Rule 2b</a> warning.
|
||||
Overriding a <a href="#rule2b">Rule 2b</a> warning carries a <strong>fair amount of risk</strong> that your submission
|
||||
will be <strong>rejected</strong>. Be sure to consult the <a href="guidelines.html">IOCCC guidelines</a>
|
||||
@@ -517,18 +516,22 @@ the <a href="../faq.html#submit">How to enter FAQ</a>.</p>
|
||||
<div id="rule4">
|
||||
<h2 id="rule-4">Rule 4</h2>
|
||||
</div>
|
||||
<p>If your entry is selected as a winner, it will be modified as follows:</p>
|
||||
<p>Your ‘build’ instructions will be incorporated into a Makefile.</p>
|
||||
<p>Your source code will be the file <strong>prog.c</strong>. The compiled binary
|
||||
will be called <strong>prog</strong>.</p>
|
||||
<p><strong><code>|</code></strong> If your submission is selected as a winner, it may be modified in order
|
||||
for into the Makefile structure of the <a href="https://www.ioccc.org/index.html">Official IOCCC winner website</a>.</p>
|
||||
<p><strong><code>|</code></strong> For example, your submission’s ‘Makefile’ maybe be modified.</p>
|
||||
<p><strong><code>|</code></strong> Your source code will be the file <strong>prog.c</strong>. The compiled binary
|
||||
will be called <strong>prog</strong>. If you submission requires different filenames,
|
||||
then modify your submission’s ‘Makefile’ to <strong>COPY</strong> (<strong>NOT</strong> move)
|
||||
the files accordingly.</p>
|
||||
<p><strong><code>|</code></strong> See also <a href="#rile5">Rule 5</a>, <a href="#rule18">Rule 18</a> and <a href="#rule21">Rule 21</a>.</p>
|
||||
<div id="rule5">
|
||||
<h2 id="rule-5">Rule 5</h2>
|
||||
</div>
|
||||
<p>Your entry <strong>MUST</strong> not modify the content or filename of any part of your
|
||||
original entry including, but not limited to <strong>prog.c</strong>, the <strong>Makefile</strong>
|
||||
<p>Your submission <strong>MUST</strong> not modify the content or filename of any part of your
|
||||
original submission including, but not limited to <strong>prog.c</strong>, the <strong>Makefile</strong>
|
||||
(that we create from your how to build instructions), as well as any data
|
||||
files you submit.</p>
|
||||
<p>If you entry wishes to modify such content, it <strong>MUST</strong> first copy the
|
||||
<p>If you submission wishes to modify such content, it <strong>MUST</strong> first copy the
|
||||
file to a new filename and then modify that copy.</p>
|
||||
<div id="rule6">
|
||||
<h2 id="rule-6">Rule 6</h2>
|
||||
@@ -545,7 +548,6 @@ file to a new filename and then modify that copy.</p>
|
||||
you must have permission from the owner(s) to submit their content
|
||||
under the following license:</p>
|
||||
<p><strong><code>|</code></strong> <strong><a href="https://creativecommons.org/licenses/by-sa/4.0/">CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International</a></strong></p>
|
||||
<p>See also <a href="#rule18">Rule 18</a>.</p>
|
||||
<p>If you submit any content that is owned by others, you <strong>MUST</strong>
|
||||
detail that ownership (i.e., who owns what) <strong>AND document the
|
||||
permission you obtained</strong>.</p>
|
||||
@@ -561,7 +563,7 @@ before the close of the contest.</p>
|
||||
<h2 id="rule-9">Rule 9</h2>
|
||||
</div>
|
||||
<p><strong><code>|</code></strong> Each person may submit up to and including 10.000000 entries per contest.</p>
|
||||
<p>Each entry must be submitted separately.</p>
|
||||
<p>Each submission must be submitted separately.</p>
|
||||
<div id="rule10">
|
||||
<h2 id="rule-10">Rule 10</h2>
|
||||
</div>
|
||||
@@ -577,63 +579,130 @@ them</strong> in the remarks file.</p>
|
||||
<div id="rule12">
|
||||
<h2 id="rule-12">Rule 12</h2>
|
||||
</div>
|
||||
<p>Legal abuse of the rules is somewhat encouraged. An entry that, in
|
||||
<p>Legal abuse of the rules is somewhat encouraged. An submission that, in
|
||||
the opinion of the judges, violates the rules will be disqualified.
|
||||
Entries that attempt to abuse the rules <strong>MUST</strong> try to justify why
|
||||
their rule abuse is legal, in the remarks file.</p>
|
||||
their rule abuse is legal, in the submission’s <code>remarks.md</code> file.</p>
|
||||
<div id="rule13">
|
||||
<h2 id="rule-13">Rule 13</h2>
|
||||
</div>
|
||||
<p>Any C source that fails to compile because of unescaped octets with
|
||||
the high bit set (octet value >= 128) will be rejected.</p>
|
||||
<p><strong><code>|</code></strong> Any C source that fails to compile because of unescaped octets with
|
||||
the high bit set (octet value >= 128) might be rejected.</p>
|
||||
<div id="rule14">
|
||||
<h2 id="rule-14">Rule 14</h2>
|
||||
</div>
|
||||
<p>Any C source that fails to compile because of lines with trailing
|
||||
control-M’s (i.e., lines with a tailing octet <code>015</code>) will be rejected.</p>
|
||||
<p>Please do not put trailing control-M’s on remarks file lines.
|
||||
<p><strong><code>|</code></strong> Any C source that fails to compile because of lines with trailing
|
||||
control-M’s (i.e., lines with a tailing octet <code>015</code>) might be rejected.</p>
|
||||
<p>Please do <strong>NOT</strong> put trailing control-M’s on remarks file lines.
|
||||
Please check to be sure, before submitting, that you have removed
|
||||
any control-M at the end of remark file lines.</p>
|
||||
<div id="rule15">
|
||||
<h2 id="rule-15">Rule 15</h2>
|
||||
</div>
|
||||
<p>When you submit your entry you must have a valid email address
|
||||
that can both send and receive email. The online submission
|
||||
method is a two phase process that requires the use of an
|
||||
approval code. This code will be emailed to you as part of
|
||||
phase 1.</p>
|
||||
<p>Entries submitted without a working or valid email address will
|
||||
be disqualified.</p>
|
||||
<p><strong><code>|</code></strong> In order to register for the IOCCC, you <strong>MUST</strong> have a valid Email address.</p>
|
||||
<p>The judges are not responsible for delays in email, please plan
|
||||
enough time for one automated exchange of email as part of your
|
||||
submission.</p>
|
||||
<p>After your email address has been confirmed, the submission code will
|
||||
be valid for submitting and editing the entry for the lifetime of the
|
||||
competition.</p>
|
||||
<p>See also <a href="../faq.html#submit">How may I submit to the IOCCC?</a> in the
|
||||
<a href="../faq.html">FAQ</a>.</p>
|
||||
<p><strong><code>|</code></strong> See <a href="../faq.html#register">How may I register for the IOCCC?</a> in the
|
||||
<a href="../faq.html">FAQ</a> for details.</p>
|
||||
<div id="rule16">
|
||||
<h2 id="rule-16">Rule 16</h2>
|
||||
</div>
|
||||
<p>You are <strong>STRONGLY</strong> encouraged to submit a previously unpublished <em>AND</em>
|
||||
original entry. Submissions that are similar to previous entries are
|
||||
original submission. Submissions that are similar to previous entries are
|
||||
discouraged. As we judge anonymously, submissions that have already
|
||||
been published may be disqualified.</p>
|
||||
<div id="rule17">
|
||||
<h2 id="rule-17">Rule 17</h2>
|
||||
</div>
|
||||
<p><strong><code>|</code></strong> The total size of your submission: the sum of the size of the program,
|
||||
<h3 id="tldr-rule-17---use-mkiocccentry1">TL;DR Rule 17 - Use <code>mkiocccentry(1)</code></h3>
|
||||
<p><strong><code>|</code></strong> This is a <strong>COMPLEX</strong> rule. Violating this rule will cause your submission to <strong>REJECTED</strong>.
|
||||
To help you avoid such a rejection, you are <strong>HIGHLY ENCOURAGED</strong> to use the <code>mkiocccentry(1)</code> tool,
|
||||
based on the latest release of the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>,
|
||||
to form your submission’s bzip2 compressed tarball.</p>
|
||||
<p><strong><code>|</code></strong> The <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>
|
||||
contains <strong>IMPORTANT</strong> tools such as:</p>
|
||||
<ul>
|
||||
<li><code>chkentry(1)</code></li>
|
||||
<li><code>iocccsize(1)</code></li>
|
||||
<li><code>mkiocccentry(1)</code></li>
|
||||
<li><code>txzchk(1)</code></li>
|
||||
</ul>
|
||||
<p><strong><code>|</code></strong> The above mentioned tools will help you verify that your submission
|
||||
conforms to <a href="#rule17">Rule 17</a>.</p>
|
||||
<p><strong><code>|</code></strong> Each above mentioned tools has a <strong><code>-h</code></strong> that provides command line help. For additional details, see the tool man pages.</p>
|
||||
<h3 id="rule-17---the-complex-details">Rule 17 - The COMPLEX details</h3>
|
||||
<p><strong><code>|</code></strong> Each submission <strong>MUST</strong> be in the form of a bzip2 compressed tarball file.</p>
|
||||
<p><strong><code>|</code></strong> The bzip2 compressed tarball filename must be of the form:</p>
|
||||
<ul>
|
||||
<li>^submit.” + <em>username</em> + - + <em>slot_num</em> + .[1-9][0-9]{9,}.txz$</li>
|
||||
</ul>
|
||||
<p>where <em><code>username</code></em> is the your IOCCC registration username in the form of a
|
||||
<a href="https://en.wikipedia.org/wiki/Universally_unique_identifier">UUID</a> (see
|
||||
<a href="https://datatracker.ietf.org/doc/html/rfc9562">RFC 9562</a> for
|
||||
details), and where <em><code>slot_num</code></em> is a single decimal digit integer
|
||||
(i.e., >= 0 and < 9), and where <em><code>+</code></em> is the concatenation operator,</p>
|
||||
<p><strong><code>|</code></strong> Your bzip2 compressed tarball file <strong>MUST</strong> contain, at a minimum,
|
||||
the following files:</p>
|
||||
<ul>
|
||||
<li><code>Makefile</code></li>
|
||||
<li><code>prog.c</code></li>
|
||||
<li><code>remarks.md</code></li>
|
||||
<li><code>.info.json</code></li>
|
||||
<li><code>.auth.json</code></li>
|
||||
</ul>
|
||||
<p><strong><code>|</code></strong> The <code>.info.json</code> must be valid JSON and pass the <code>chkentry(1)</code> test.</p>
|
||||
<p><strong><code>|</code></strong> The <code>.auth.json</code> must be valid JSON and pass the <code>chkentry(1)</code> test.</p>
|
||||
<p><strong><code>|</code></strong> You submission may have additional files, however <code>basename(1)</code> of the filenames of those additional files <strong>MUST</strong>:</p>
|
||||
<ul>
|
||||
<li>Be less than <strong>100</strong> characters in length</li>
|
||||
<li>Match the regular expression: <code>^[0-9A-Za-z][0-9A-Za-z._+-]*$</code></li>
|
||||
</ul>
|
||||
<p><strong><code>|</code></strong> The <code>Makefile</code> must be a non-empty file in <a href="https://www.gnu.org/software/make/manual/make.html">Gnu Makefile</a> form.</p>
|
||||
<p><strong><code>|</code></strong> The <code>remarks.md</code> must be a non-empty file in markdown form. See also <a href="#rule18">Rule 18</a>.</p>
|
||||
<p><strong><code>|</code></strong> The bzip2 compressed tarball file <strong>MUST</strong> be less than
|
||||
or equal <strong>3999971</strong> octets in size.</p>
|
||||
<p><strong><code>|</code></strong> When your submission’s bzip2 compressed tarball is uncompressed,
|
||||
the total size of your submission: the sum of the size of the program,
|
||||
hints, comments, build and info files <strong>MUST</strong> be less than or equal
|
||||
to 28314624 octets (27651K) in size.</p>
|
||||
<p><strong><code>|</code></strong> When your submission is formed into a bzip2 compressed tarball file,
|
||||
that file must than or equal 3999971 octets in size.</p>
|
||||
<p><strong><code>|</code></strong> The <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
|
||||
(see <code>mkiocccentry(1)</code> and <code>txzchk(1)</code>) will help you verify that your
|
||||
submission conforms to this <a href="#rule17">Rule 17</a>.</p>
|
||||
<p><strong><code>|</code></strong> You are <strong>HIGHLY ENCOURAGED</strong> to use the <code>mkiocccentry(1)</code>
|
||||
tool to form your submission’s bzip2 compressed tarball. The</p>
|
||||
<p><strong><code>|</code></strong> You submission may have additional files, however filenames of those additional files <strong>MUST</strong>:</p>
|
||||
<ul>
|
||||
<li>be less than <strong>100</strong> characters in length</li>
|
||||
<li>conform to the regular expression: <code>^[0-9A-Za-z][0-9A-Za-z._+-]*$</code></li>
|
||||
</ul>
|
||||
<p><strong><code>|</code></strong> Your entry may have sub-directories, however the sub-directories <strong>MUST</strong> only
|
||||
reside under the submission’s top level directory.</p>
|
||||
<p><strong><code>|</code></strong> The directory names of sub-directories path, <strong>MUST</strong>:</p>
|
||||
<ul>
|
||||
<li>Be less than <strong>100</strong> characters in length</li>
|
||||
<li><strong>NOT</strong> start with: <strong><code>/</code></strong></li>
|
||||
<li><strong>NOT</strong> contain a path component of: <strong><code>.</code></strong></li>
|
||||
<li><strong>NOT</strong> contain a path component of: <strong><code>..</code></strong></li>
|
||||
<li>Match the regular expression <code>^[0-9A-Za-z][0-9A-Za-z._+-]*$</code>.</li>
|
||||
</ul>
|
||||
<p><strong><code>|</code></strong> The <code>Makefile</code> must be a non-empty file.</p>
|
||||
<p><strong><code>|</code></strong> The <code>remarks.md</code> must be a non-empty file in markdown form. See also <a href="#rule18">Rule 18</a>.</p>
|
||||
<p><strong><code>|</code></strong> The bzip2 compressed tarball file <strong>MUST</strong> be less than
|
||||
or equal <strong>3999971</strong> octets in size.</p>
|
||||
<p><strong><code>|</code></strong> When your submission’s bzip2 compressed tarball is uncompressed,
|
||||
the total size of your submission: the sum of the size of the program,
|
||||
hints, comments, build and info files <strong>MUST</strong> be less than or equal
|
||||
to 28314624 octets (27651K) in size.</p>
|
||||
<p><strong><code>|</code></strong> Your submission’s bzip2 compressed tarball <strong>MUST</strong> pass the <code>txzchk(1)</code> test.</p>
|
||||
<p><strong><code>|</code></strong> Where <a href="#rule17">Rule 17</a> and the tools from the latest
|
||||
release of the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>
|
||||
conflict, the <a href="../judges.html">IOCCC Judges</a> will use their best judgment which
|
||||
is likely to favor <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a> code.</p>
|
||||
<p><strong><code>|</code></strong> To state the obvious: submissions that violate <a href="#rule17">Rule 17</a> <strong>will be rejected</strong>,
|
||||
so be sure to use the latest release of the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>,
|
||||
to form and test your submission’s bzip2 compressed tarball.</p>
|
||||
<div id="rule18">
|
||||
<h2 id="rule-18">Rule 18</h2>
|
||||
</div>
|
||||
<p>The entirety of your entry must be submitted under the following license:</p>
|
||||
<p>The entirety of your submission must be submitted under the following license:</p>
|
||||
<p><strong><code>|</code></strong> <strong><a href="https://creativecommons.org/licenses/by-sa/4.0/">CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International</a></strong></p>
|
||||
<p>You (the author(s)) <strong>MUST</strong> own the contents of your submission <strong>OR</strong>
|
||||
you <strong>MUST HAVE PERMISSION</strong> from the owner(s) to submit their content.</p>
|
||||
@@ -641,40 +710,36 @@ you <strong>MUST HAVE PERMISSION</strong> from the owner(s) to submit their cont
|
||||
<div id="rule19">
|
||||
<h2 id="rule-19">Rule 19</h2>
|
||||
</div>
|
||||
<p>The remarks file must be written in markdown format. See
|
||||
<p><strong><code>|</code></strong> The <code>remarks.md</code> file, a required non-empty file, must be written in markdown format. See
|
||||
the Daring Fireball <a href="http://daringfireball.net/projects/markdown/basics">Markdown: Basics</a>
|
||||
for more information.</p>
|
||||
<p><strong><code>|</code></strong> We currently use <a href="https://pandoc.org">pandoc</a> to convert markdown to HTML.</p>
|
||||
<p><strong><code>|</code></strong> Please see our <a href="../markdown.html">IOCCC markdown guidelines</a> for additional markdown guidance.</p>
|
||||
<div id="rule20">
|
||||
<h2 id="rule-20">Rule 20</h2>
|
||||
</div>
|
||||
<p>The how to build instructions must be in Makefile format. See <a href="../faq.html#make_compatibility">the FAQ about
|
||||
make(1) compatibility the IOCCC
|
||||
supports</a> for more details.</p>
|
||||
<p><strong><code>|</code></strong> You are <strong>ENCOURAGED</strong> to use
|
||||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example">Makefile.example</a>,
|
||||
renamed as <code>Makefile</code> of course, for help in constructing your Makefile.</p>
|
||||
<p>The target of the Makefile must be called <code>prog</code>. The original
|
||||
C source file must be called <code>prog.c</code>.</p>
|
||||
<p>To invoke the C compiler, use <code>${CC}</code>.
|
||||
To invoke the C preprocessor use <code>${CPP}</code>.</p>
|
||||
<p>Do not assume that <code>.</code> (the current directory) is in the <code>$PATH</code>.</p>
|
||||
<p>Use a shell command syntax that is compatible with bash.</p>
|
||||
<p><strong><code>|</code></strong> Your <code>Makefile</code> <strong>MUST</strong> use a syntax that is compatible with bash. You are <strong>ENCOURAGED</strong> to use set <code>SHELL= bash</code> in your <code>Makefile.</code></p>
|
||||
<p><strong><code>|</code></strong> Assume that commands commonly 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> are
|
||||
available in the <code>$PATH</code> search path.</p>
|
||||
<p>Do not assume any particular given value of <code>${CFLAGS}</code> or other
|
||||
commonly used make variables. In other words you <strong>MUST</strong> specify the <code>CFLAGS</code>
|
||||
to use.</p>
|
||||
<p>See also the
|
||||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example">Makefile.example</a>
|
||||
for help in constructing your Makefile. The <code>mkiocccentry</code>, which can be found
|
||||
at the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>, tries to
|
||||
detect if required rules exist in your Makefile.</p>
|
||||
<div id="rule21">
|
||||
<h2 id="rule-21">Rule 21</h2>
|
||||
</div>
|
||||
<p>Your entry must not create or modify files above the current directory
|
||||
with the exception of the <code>/tmp</code> and the <code>/var/tmp</code> directories. Your entry
|
||||
<p>Your submission must not create or modify files above the current directory
|
||||
with the exception of the <code>/tmp</code> and the <code>/var/tmp</code> directories. Your submission
|
||||
<strong>MAY</strong> create subdirectories below the current directory, or in <code>/tmp</code>,
|
||||
or in <code>/var/tmp</code> provided that <code>.</code> is <strong>NOT</strong> the first octet in any
|
||||
directory name or filename you submit.</p>
|
||||
@@ -686,10 +751,10 @@ directory name or filename you submit.</p>
|
||||
identify the authors of your code. The judges <strong>STRONGLY prefer</strong> to
|
||||
NOT know who is submitting entries to the IOCCC.</p>
|
||||
<p>Even if you are a previous IOCCC winner, catch 22 still applies.</p>
|
||||
<p>Identifying the author(s) of your entry in an obvious way anywhere
|
||||
<p>Identifying the author(s) of your submission in an obvious way anywhere
|
||||
within your code, data, remarks or program output (unless you are
|
||||
<em>Peter Honeyman</em> or pretending to be <em>Peter Honeyman</em>) will be grounds
|
||||
for disqualification of your entry.</p>
|
||||
for disqualification of your submission.</p>
|
||||
<p>Yes, Virginia, <strong>WE REALLY MEAN IT!</strong></p>
|
||||
<div id="rule23">
|
||||
<h2 id="rule-23">Rule 23</h2>
|
||||
@@ -711,7 +776,8 @@ for disqualification of your entry.</p>
|
||||
<strong><code>|</code></strong> “How vexingly quick daft zebras jump!”<br>
|
||||
<strong><code>|</code></strong> “Sphinx of black quartz, judge my vow.”<br>
|
||||
<strong><code>|</code></strong> “Waltz, bad nymph, for quick jigs vex.”<br>
|
||||
<strong><code>|</code></strong> “Mr. Jock, TV quiz PhD, bags few lynx.”</p>
|
||||
<strong><code>|</code></strong> “Mr. Jock, TV quiz PhD, bags few lynx.”<br>
|
||||
<strong><code>|</code></strong> “abcdefg, hijklmnop, qrstu&v, wxy&z.”</p>
|
||||
<div id="rule27">
|
||||
<h2 id="rule-27">Rule 27</h2>
|
||||
</div>
|
||||
@@ -719,7 +785,7 @@ for disqualification of your entry.</p>
|
||||
<div id="rule28">
|
||||
<h2 id="rule-28">Rule 28</h2>
|
||||
</div>
|
||||
<p><strong><code>|</code></strong> <a href="#rule28">Rule 28</a> is a perfect way end to the list of <a href="rules.html">IOCCC rules</a> as we do not plan to have 496 rules. :-)</p>
|
||||
<p><strong><code>|</code></strong> <a href="#rule28">Rule 28</a> is a perfect way end to the list of <a href="rules.html">IOCCC rules</a> as we do <strong>NOT</strong> plan to have <strong>496</strong> rules. :-)</p>
|
||||
<h1 id="for-more-information">FOR MORE INFORMATION:</h1>
|
||||
<p><strong><code>|</code></strong> For questions or comments about the contest, see <a href="../contact.html">Contacting the IOCCC</a>.</p>
|
||||
<p><strong><code>|</code></strong> Be sure to review the <a href="index.html">IOCCC Rules and Guidelines</a> as
|
||||
|
||||
+152
-68
@@ -1,4 +1,4 @@
|
||||
<!-- START: this line starts content from: inc/rules.closed.hdr -->
|
||||
repo START: this line starts content from: inc/rules.closed.hdr -->
|
||||
|
||||
# WARNING: These rules are OUT OF DATE
|
||||
|
||||
@@ -7,8 +7,6 @@ and are **VERY LIKELY** to be updated before the next IOCCC.
|
||||
They are are provided as a **very tentative** hint at **what
|
||||
MIGHT** be used in the next IOCCC.
|
||||
|
||||
Please regard these rules as a historical archive.
|
||||
|
||||
|
||||
# The IOCCC is closed
|
||||
|
||||
@@ -77,9 +75,9 @@ The goals of the IOCCC:
|
||||
**`|`** This IOCCC runs from **2024-MMM-DD HH:MM:SS UTC** to **202x-MMM-DD HH:MM:SS UTC**.<br>
|
||||
**`|`** **XXX - date/time is TBD - XXX**
|
||||
|
||||
Until the start of this IOCCC, these [IOCCC rules](rules.html),
|
||||
**`|`** Until the start of this IOCCC, these [IOCCC rules](rules.html),
|
||||
[IOCCC guidelines](guidelines.html) and iocccsize.c (contained in the [mkiocccentry
|
||||
toolkit](https://github.com/ioccc-src/mkiocccentry) and invoked by the
|
||||
repo](https://github.com/ioccc-src/mkiocccentry) and invoked by the
|
||||
`mkiocccentry(1)` tool) should be considered provisional **BETA** versions and
|
||||
**may be adjusted _AT ANY TIME_**.
|
||||
|
||||
@@ -98,11 +96,11 @@ Please wait to submit your entries until after that time.
|
||||
The official [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html) will be
|
||||
available on the [official IOCCC website](../index.html) on or slightly before
|
||||
the start of this IOCCC. The `mkiocccentry` toolkit may be obtained at any time
|
||||
at the [mkiocccentry toolkit repo](https://github.com/ioccc-src/mkiocccentry).
|
||||
at the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
|
||||
|
||||
Please recheck on or after the start of this IOCCC to be sure you
|
||||
are using the correct versions of these items before using the IOCCC
|
||||
entry submission URL.
|
||||
submission URL.
|
||||
|
||||
|
||||
# IOCCC RULES
|
||||
@@ -119,14 +117,14 @@ We need a rule 0. :-)
|
||||
## Rule 1
|
||||
</div>
|
||||
|
||||
Your entry must be a complete program.
|
||||
Your submission must be a complete program.
|
||||
|
||||
|
||||
<div id="rule2">
|
||||
## Rule 2
|
||||
</div>
|
||||
|
||||
The size rule requires your entry to satisfy **BOTH** [Rule 2a](#rule2a) and [Rule 2b](#rule2b):
|
||||
The size rule requires your submission to satisfy **BOTH** [Rule 2a](#rule2a) and [Rule 2b](#rule2b):
|
||||
|
||||
|
||||
<div id="rule2a">
|
||||
@@ -165,10 +163,10 @@ as a command like argument to the `iocccsize(1)` tool. For example:
|
||||
of the official IOCCC size tool (hereby referred to as `iocccsize(1)`), the value printed **should not exceed 2503**.
|
||||
|
||||
**`|`** The source to `iocccsize(1)` may be found in the
|
||||
[mkiocccentry tool repo](https://github.com/ioccc-src/mkiocccentry).
|
||||
[mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
|
||||
|
||||
**`|`** If you use the `mkiocccentry(1)` tool, which we **STRONGLY recommend you use**,
|
||||
then `mkiocccentry(1)` will invoke `iocccsize(1)` before packaging your entry for submission.
|
||||
then `mkiocccentry(1)` will invoke `iocccsize(1)` before packaging your submission.
|
||||
|
||||
**`|`** The `mkiocccentry(1)` tool will give you the option of overriding the [Rule 2b](#rule2b) warning.
|
||||
Overriding a [Rule 2b](#rule2b) warning carries a **fair amount of risk** that your submission
|
||||
@@ -208,24 +206,29 @@ Please wait to submit your entries until after that time.
|
||||
## Rule 4
|
||||
</div>
|
||||
|
||||
If your entry is selected as a winner, it will be modified as follows:
|
||||
**`|`** If your submission is selected as a winner, it may be modified in order
|
||||
for into the Makefile structure of the [Official IOCCC winner website](https://www.ioccc.org/index.html).
|
||||
|
||||
Your 'build' instructions will be incorporated into a Makefile.
|
||||
**`|`** For example, your submission's 'Makefile' maybe be modified.
|
||||
|
||||
Your source code will be the file **prog.c**. The compiled binary
|
||||
will be called **prog**.
|
||||
**`|`** Your source code will be the file **prog.c**. The compiled binary
|
||||
will be called **prog**. If you submission requires different filenames,
|
||||
then modify your submission's 'Makefile' to **COPY** (**NOT** move)
|
||||
the files accordingly.
|
||||
|
||||
**`|`** See also [Rule 5](#rile5), [Rule 18](#rule18) and [Rule 21](#rule21).
|
||||
|
||||
|
||||
<div id="rule5">
|
||||
## Rule 5
|
||||
</div>
|
||||
|
||||
Your entry **MUST** not modify the content or filename of any part of your
|
||||
original entry including, but not limited to **prog.c**, the **Makefile**
|
||||
Your submission **MUST** not modify the content or filename of any part of your
|
||||
original submission including, but not limited to **prog.c**, the **Makefile**
|
||||
(that we create from your how to build instructions), as well as any data
|
||||
files you submit.
|
||||
|
||||
If you entry wishes to modify such content, it **MUST** first copy the
|
||||
If you submission wishes to modify such content, it **MUST** first copy the
|
||||
file to a new filename and then modify that copy.
|
||||
|
||||
|
||||
@@ -252,8 +255,6 @@ under the following license:
|
||||
|
||||
**`|`** **[CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/)**
|
||||
|
||||
See also [Rule 18](#rule18).
|
||||
|
||||
If you submit any content that is owned by others, you **MUST**
|
||||
detail that ownership (i.e., who owns what) **AND document the
|
||||
permission you obtained**.
|
||||
@@ -279,7 +280,7 @@ before the close of the contest.
|
||||
|
||||
**`|`** Each person may submit up to and including 10.000000 entries per contest.
|
||||
|
||||
Each entry must be submitted separately.
|
||||
Each submission must be submitted separately.
|
||||
|
||||
|
||||
<div id="rule10">
|
||||
@@ -304,28 +305,28 @@ them** in the remarks file.
|
||||
## Rule 12
|
||||
</div>
|
||||
|
||||
Legal abuse of the rules is somewhat encouraged. An entry that, in
|
||||
Legal abuse of the rules is somewhat encouraged. An submission that, in
|
||||
the opinion of the judges, violates the rules will be disqualified.
|
||||
Entries that attempt to abuse the rules **MUST** try to justify why
|
||||
their rule abuse is legal, in the remarks file.
|
||||
their rule abuse is legal, in the submission's `remarks.md` file.
|
||||
|
||||
|
||||
<div id="rule13">
|
||||
## Rule 13
|
||||
</div>
|
||||
|
||||
Any C source that fails to compile because of unescaped octets with
|
||||
the high bit set (octet value >= 128) will be rejected.
|
||||
**`|`** Any C source that fails to compile because of unescaped octets with
|
||||
the high bit set (octet value >= 128) might be rejected.
|
||||
|
||||
|
||||
<div id="rule14">
|
||||
## Rule 14
|
||||
</div>
|
||||
|
||||
Any C source that fails to compile because of lines with trailing
|
||||
control-M's (i.e., lines with a tailing octet `015`) will be rejected.
|
||||
**`|`** Any C source that fails to compile because of lines with trailing
|
||||
control-M's (i.e., lines with a tailing octet `015`) might be rejected.
|
||||
|
||||
Please do not put trailing control-M's on remarks file lines.
|
||||
Please do **NOT** put trailing control-M's on remarks file lines.
|
||||
Please check to be sure, before submitting, that you have removed
|
||||
any control-M at the end of remark file lines.
|
||||
|
||||
@@ -334,25 +335,14 @@ any control-M at the end of remark file lines.
|
||||
## Rule 15
|
||||
</div>
|
||||
|
||||
When you submit your entry you must have a valid email address
|
||||
that can both send and receive email. The online submission
|
||||
method is a two phase process that requires the use of an
|
||||
approval code. This code will be emailed to you as part of
|
||||
phase 1.
|
||||
|
||||
Entries submitted without a working or valid email address will
|
||||
be disqualified.
|
||||
**`|`** In order to register for the IOCCC, you **MUST** have a valid Email address.
|
||||
|
||||
The judges are not responsible for delays in email, please plan
|
||||
enough time for one automated exchange of email as part of your
|
||||
submission.
|
||||
|
||||
After your email address has been confirmed, the submission code will
|
||||
be valid for submitting and editing the entry for the lifetime of the
|
||||
competition.
|
||||
|
||||
See also [How may I submit to the IOCCC?](../faq.html#submit) in the
|
||||
[FAQ](../faq.html).
|
||||
**`|`** See [How may I register for the IOCCC?](../faq.html#register) in the
|
||||
[FAQ](../faq.html) for details.
|
||||
|
||||
|
||||
<div id="rule16">
|
||||
@@ -360,7 +350,7 @@ See also [How may I submit to the IOCCC?](../faq.html#submit) in the
|
||||
</div>
|
||||
|
||||
You are **STRONGLY** encouraged to submit a previously unpublished _AND_
|
||||
original entry. Submissions that are similar to previous entries are
|
||||
original submission. Submissions that are similar to previous entries are
|
||||
discouraged. As we judge anonymously, submissions that have already
|
||||
been published may be disqualified.
|
||||
|
||||
@@ -369,23 +359,120 @@ been published may be disqualified.
|
||||
## Rule 17
|
||||
</div>
|
||||
|
||||
**`|`** The total size of your submission: the sum of the size of the program,
|
||||
|
||||
### TL;DR Rule 17 - Use `mkiocccentry(1)`
|
||||
|
||||
**`|`** This is a **COMPLEX** rule. Violating this rule will cause your submission to **REJECTED**.
|
||||
To help you avoid such a rejection, you are **HIGHLY ENCOURAGED** to use the `mkiocccentry(1)` tool,
|
||||
based on the latest release of the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry),
|
||||
to form your submission's bzip2 compressed tarball.
|
||||
|
||||
**`|`** The [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
|
||||
contains **IMPORTANT** tools such as:
|
||||
|
||||
* `chkentry(1)`
|
||||
* `iocccsize(1)`
|
||||
* `mkiocccentry(1)`
|
||||
* `txzchk(1)`
|
||||
|
||||
**`|`** The above mentioned tools will help you verify that your submission
|
||||
conforms to [Rule 17](#rule17).
|
||||
|
||||
**`|`** Each above mentioned tools has a **`-h`** that provides command line help. For additional details, see the tool man pages.
|
||||
|
||||
|
||||
### Rule 17 - The COMPLEX details
|
||||
|
||||
**`|`** Each submission **MUST** be in the form of a bzip2 compressed tarball file.
|
||||
|
||||
**`|`** The bzip2 compressed tarball filename must be of the form:
|
||||
|
||||
* ^submit\." + _username_ + - + _slot_num_ + \.[1-9][0-9]{9,}\.txz$
|
||||
|
||||
where _`username`_ is the your IOCCC registration username in the form of a
|
||||
[UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) (see
|
||||
[RFC 9562](https://datatracker.ietf.org/doc/html/rfc9562) for
|
||||
details), and where _`slot_num`_ is a single decimal digit integer
|
||||
(i.e., >= 0 and < 9), and where _`+`_ is the concatenation operator,
|
||||
|
||||
**`|`** Your bzip2 compressed tarball file **MUST** contain, at a minimum,
|
||||
the following files:
|
||||
|
||||
* `Makefile`
|
||||
* `prog.c`
|
||||
* `remarks.md`
|
||||
* `.info.json`
|
||||
* `.auth.json`
|
||||
|
||||
**`|`** The `.info.json` must be valid JSON and pass the `chkentry(1)` test.
|
||||
|
||||
**`|`** The `.auth.json` must be valid JSON and pass the `chkentry(1)` test.
|
||||
|
||||
**`|`** You submission may have additional files, however `basename(1)` of the filenames of those additional files **MUST**:
|
||||
|
||||
* Be less than **100** characters in length
|
||||
* Match the regular expression: `^[0-9A-Za-z][0-9A-Za-z._+-]*$`
|
||||
|
||||
**`|`** The `Makefile` must be a non-empty file in [Gnu Makefile](https://www.gnu.org/software/make/manual/make.html) form.
|
||||
|
||||
**`|`** The `remarks.md` must be a non-empty file in markdown form. See also [Rule 18](#rule18).
|
||||
|
||||
**`|`** The bzip2 compressed tarball file **MUST** be less than
|
||||
or equal **3999971** octets in size.
|
||||
|
||||
**`|`** When your submission's bzip2 compressed tarball is uncompressed,
|
||||
the total size of your submission: the sum of the size of the program,
|
||||
hints, comments, build and info files **MUST** be less than or equal
|
||||
to 28314624 octets (27651K) in size.
|
||||
|
||||
**`|`** When your submission is formed into a bzip2 compressed tarball file,
|
||||
that file must than or equal 3999971 octets in size.
|
||||
**`|`** You are **HIGHLY ENCOURAGED** to use the `mkiocccentry(1)`
|
||||
tool to form your submission's bzip2 compressed tarball. The
|
||||
|
||||
**`|`** The [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
|
||||
(see `mkiocccentry(1)` and `txzchk(1)`) will help you verify that your
|
||||
submission conforms to this [Rule 17](#rule17).
|
||||
**`|`** You submission may have additional files, however filenames of those additional files **MUST**:
|
||||
|
||||
* be less than **100** characters in length
|
||||
* conform to the regular expression: `^[0-9A-Za-z][0-9A-Za-z._+-]*$`
|
||||
|
||||
**`|`** Your entry may have sub-directories, however the sub-directories **MUST** only
|
||||
reside under the submission's top level directory.
|
||||
|
||||
**`|`** The directory names of sub-directories path, **MUST**:
|
||||
|
||||
* Be less than **100** characters in length
|
||||
* **NOT** start with: **`/`**
|
||||
* **NOT** contain a path component of: **`.`**
|
||||
* **NOT** contain a path component of: **`..`**
|
||||
* Match the regular expression `^[0-9A-Za-z][0-9A-Za-z._+-]*$`.
|
||||
|
||||
**`|`** The `Makefile` must be a non-empty file.
|
||||
|
||||
**`|`** The `remarks.md` must be a non-empty file in markdown form. See also [Rule 18](#rule18).
|
||||
|
||||
**`|`** The bzip2 compressed tarball file **MUST** be less than
|
||||
or equal **3999971** octets in size.
|
||||
|
||||
**`|`** When your submission's bzip2 compressed tarball is uncompressed,
|
||||
the total size of your submission: the sum of the size of the program,
|
||||
hints, comments, build and info files **MUST** be less than or equal
|
||||
to 28314624 octets (27651K) in size.
|
||||
|
||||
**`|`** Your submission's bzip2 compressed tarball **MUST** pass the `txzchk(1)` test.
|
||||
|
||||
**`|`** Where [Rule 17](#rule17) and the tools from the latest
|
||||
release of the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
|
||||
conflict, the [IOCCC Judges](../judges.html) will use their best judgment which
|
||||
is likely to favor [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) code.
|
||||
|
||||
**`|`** To state the obvious: submissions that violate [Rule 17](#rule17) **will be rejected**,
|
||||
so be sure to use the latest release of the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry),
|
||||
to form and test your submission's bzip2 compressed tarball.
|
||||
|
||||
|
||||
<div id="rule18">
|
||||
## Rule 18
|
||||
</div>
|
||||
|
||||
The entirety of your entry must be submitted under the following license:
|
||||
The entirety of your submission must be submitted under the following license:
|
||||
|
||||
**`|`** **[CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/)**
|
||||
|
||||
@@ -399,12 +486,14 @@ You must not submit anything that cannot be submitted under that license.
|
||||
## Rule 19
|
||||
</div>
|
||||
|
||||
The remarks file must be written in markdown format. See
|
||||
**`|`** The `remarks.md` file, a required non-empty file, must be written in markdown format. See
|
||||
the Daring Fireball [Markdown: Basics](http://daringfireball.net/projects/markdown/basics)
|
||||
for more information.
|
||||
|
||||
**`|`** We currently use [pandoc](https://pandoc.org) to convert markdown to HTML.
|
||||
|
||||
**`|`** Please see our [IOCCC markdown guidelines](../markdown.html) for additional markdown guidance.
|
||||
|
||||
|
||||
<div id="rule20">
|
||||
## Rule 20
|
||||
@@ -414,6 +503,10 @@ The how to build instructions must be in Makefile format. See [the FAQ about
|
||||
make(1) compatibility the IOCCC
|
||||
supports](../faq.html#make_compatibility) for more details.
|
||||
|
||||
**`|`** You are **ENCOURAGED** to use
|
||||
[Makefile.example](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example),
|
||||
renamed as `Makefile` of course, for help in constructing your Makefile.
|
||||
|
||||
The target of the Makefile must be called `prog`. The original
|
||||
C source file must be called `prog.c`.
|
||||
|
||||
@@ -422,7 +515,7 @@ To invoke the C preprocessor use `${CPP}`.
|
||||
|
||||
Do not assume that `.` (the current directory) is in the `$PATH`.
|
||||
|
||||
Use a shell command syntax that is compatible with bash.
|
||||
**`|`** Your `Makefile` **MUST** use a syntax that is compatible with bash. You are **ENCOURAGED** to use set `SHELL= bash` in your `Makefile.`
|
||||
|
||||
**`|`** Assume that commands commonly found in [Single UNIX
|
||||
Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
|
||||
@@ -430,23 +523,13 @@ environments and systems that conform to the [Single UNIX
|
||||
Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) are
|
||||
available in the `$PATH` search path.
|
||||
|
||||
Do not assume any particular given value of `${CFLAGS}` or other
|
||||
commonly used make variables. In other words you **MUST** specify the `CFLAGS`
|
||||
to use.
|
||||
|
||||
See also the
|
||||
[Makefile.example](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example)
|
||||
for help in constructing your Makefile. The `mkiocccentry`, which can be found
|
||||
at the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry), tries to
|
||||
detect if required rules exist in your Makefile.
|
||||
|
||||
|
||||
<div id="rule21">
|
||||
## Rule 21
|
||||
</div>
|
||||
|
||||
Your entry must not create or modify files above the current directory
|
||||
with the exception of the `/tmp` and the `/var/tmp` directories. Your entry
|
||||
Your submission must not create or modify files above the current directory
|
||||
with the exception of the `/tmp` and the `/var/tmp` directories. Your submission
|
||||
**MAY** create subdirectories below the current directory, or in `/tmp`,
|
||||
or in `/var/tmp` provided that `.` is **NOT** the first octet in any
|
||||
directory name or filename you submit.
|
||||
@@ -464,10 +547,10 @@ NOT know who is submitting entries to the IOCCC.
|
||||
|
||||
Even if you are a previous IOCCC winner, catch 22 still applies.
|
||||
|
||||
Identifying the author(s) of your entry in an obvious way anywhere
|
||||
Identifying the author(s) of your submission in an obvious way anywhere
|
||||
within your code, data, remarks or program output (unless you are
|
||||
_Peter Honeyman_ or pretending to be _Peter Honeyman_) will be grounds
|
||||
for disqualification of your entry.
|
||||
for disqualification of your submission.
|
||||
|
||||
Yes, Virginia, **WE REALLY MEAN IT!**
|
||||
|
||||
@@ -502,7 +585,8 @@ Even though 24 is not prime, you should still see [Rule 23](#rule23).
|
||||
**`|`** "How vexingly quick daft zebras jump!"<br>
|
||||
**`|`** "Sphinx of black quartz, judge my vow."<br>
|
||||
**`|`** "Waltz, bad nymph, for quick jigs vex."<br>
|
||||
**`|`** "Mr. Jock, TV quiz PhD, bags few lynx."
|
||||
**`|`** "Mr. Jock, TV quiz PhD, bags few lynx."<br>
|
||||
**`|`** "abcdefg, hijklmnop, qrstu&v, wxy&z."
|
||||
|
||||
|
||||
<div id="rule27">
|
||||
@@ -516,7 +600,7 @@ Even though 24 is not prime, you should still see [Rule 23](#rule23).
|
||||
## Rule 28
|
||||
</div>
|
||||
|
||||
**`|`** [Rule 28](#rule28) is a perfect way end to the list of [IOCCC rules](rules.html) as we do not plan to have 496 rules. :-)
|
||||
**`|`** [Rule 28](#rule28) is a perfect way end to the list of [IOCCC rules](rules.html) as we do **NOT** plan to have **496** rules. :-)
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user