Merge pull request #2419 from xexyl/fmt-typo-next
Finish format/typo checks in next/
This commit is contained in:
6 files changed
+419
-364
No files matched your search
@@ -1,22 +1,22 @@
|
||||
<!-- START: this line starts content from: inc/guidelines.closed.hdr -->
|
||||
|
||||
# WARNING: These guidelines are OUT OF DATE
|
||||
|
||||
They are a **very tentative proposal** for the next IOCCC
|
||||
that is **VERY LIKELY** to be updated before the next IOCCC.
|
||||
They are are provided as a **very tentative** hint at what
|
||||
might be used in a future IOCCC.
|
||||
These guidelines are a **VERY TENTATIVE proposal** for the next IOCCC
|
||||
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 guidelines as a historic archive.
|
||||
Please regard these guidelines as a historical archive.
|
||||
|
||||
|
||||
# The IOCCC is closed
|
||||
|
||||
The IOCCC is **NOT** accepting new submissions at this time. See the
|
||||
[IOCCC winning entries page](../years.html) for the entries that have won the IOCCC.
|
||||
[IOCCC winning entries page](../years.html) for the entries that have won the
|
||||
IOCCC in the past.
|
||||
|
||||
Watch both [the IOCCC status page](../status.html) and the
|
||||
[@IOCCC mastodon feed](https://fosstodon.org/@ioccc) for information about future IOCCC openings.
|
||||
[@IOCCC mastodon feed](https://fosstodon.org/@ioccc) for information about
|
||||
future IOCCC openings.
|
||||
|
||||
<!-- END: the next line ends content from: inc/guidelines.closed.hdr -->
|
||||
<!-- This is the last line modified by the tool: bin/gen-status.sh -->
|
||||
+11
-8
@@ -2,21 +2,24 @@
|
||||
|
||||
# WARNING: These rules are OUT OF DATE
|
||||
|
||||
They are a **very tentative proposal** for the next IOCCC
|
||||
that is **VERY LIKELY** to be updated before the next IOCCC.
|
||||
They are are provided as a **very tentative** hint at what
|
||||
might be used in a future IOCCC.
|
||||
These rules are a **VERY TENTATIVE proposal** for the next IOCCC
|
||||
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 historic archive.
|
||||
Please regard these rules as a historical archive.
|
||||
|
||||
|
||||
# The IOCCC is closed
|
||||
|
||||
The IOCCC is **NOT** accepting new submissions at this time. See the
|
||||
[IOCCC winning entries page](../years.html) for the entries that have won the IOCCC.
|
||||
The IOCCC is **NOT** accepting new submissions at this time. See the [IOCCC
|
||||
winning entries page](../years.html) for the entries that have won the IOCCC in
|
||||
the past.
|
||||
|
||||
Watch both [the IOCCC status page](../status.html) and the
|
||||
[@IOCCC mastodon feed](https://fosstodon.org/@ioccc) for information about future IOCCC openings.
|
||||
[@IOCCC mastodon feed](https://fosstodon.org/@ioccc) for information about
|
||||
future IOCCC openings.
|
||||
|
||||
<!-- END: the next line ends content from: inc/rules.closed.hdr -->
|
||||
<!-- This is the last line modified by the tool: bin/gen-status.sh -->
|
||||
|
||||
+144
-126
@@ -382,22 +382,23 @@
|
||||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
|
||||
<!-- BEFORE: 1st line of markdown file: next/guidelines.md -->
|
||||
<!-- START: this line starts content from: inc/guidelines.closed.hdr -->
|
||||
<h1 id="warning-these-guidelines-are-out-of-date">WARNING: These guidelines are OUT OF DATE</h1>
|
||||
<p>These guidelines are a <strong>very tentative proposal</strong> for the next IOCCC
|
||||
that is <strong>VERY LIKELY</strong> to be updated before the next IOCCC.
|
||||
They are are provided as a <strong>very tentative</strong> hint at what
|
||||
might be used in a future IOCCC.</p>
|
||||
<p>Please regard these guidelines as a historic archive.</p>
|
||||
<p>These guidelines 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 guidelines 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.</p>
|
||||
<a href="../years.html">IOCCC winning entries page</a> for the entries that have won the
|
||||
IOCCC in the past.</p>
|
||||
<p>Watch both <a href="../status.html">the IOCCC status page</a> and the
|
||||
<a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> mastodon feed</a> for information about future IOCCC openings.</p>
|
||||
<a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> mastodon feed</a> for information about
|
||||
future IOCCC openings.</p>
|
||||
<!-- END: the next line ends content from: inc/guidelines.closed.hdr -->
|
||||
<!-- This is the last line modified by the tool: bin/gen-status.sh -->
|
||||
<h1 id="th-international-obfuscated-c-code-contest-official-guidelines">28th International Obfuscated C Code Contest Official Guidelines</h1>
|
||||
<p>Copyright © 2024 Leonid A. Broukhis, Landon Curt Noll.</p>
|
||||
<p>Copyright © 2024 Leonid A. Broukhis and Landon Curt Noll.</p>
|
||||
<p>All Rights Reserved. Permission for personal, education or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in
|
||||
@@ -415,10 +416,10 @@ submit entries to the <a href="https://www.ioccc.org">International Obfuscated C
|
||||
(IOCCC)</a>.</p>
|
||||
<p>These are not the IOCCC rules, though it does contain comments about
|
||||
them. The guidelines should be viewed as <em>hints</em> and <em>suggestions</em>.
|
||||
Entries that violate the guidelines but remain within the rules are
|
||||
allowed. Even so, you are safer if you remain within the guidelines.</p>
|
||||
Entries that violate the guidelines but remain within the rules <em>are
|
||||
allowed</em>. Even so, you are safer if you remain within the guidelines.</p>
|
||||
<p>You should read the current <a href="rules.html">IOCCC rules</a>, prior to submitting entries.
|
||||
The rules are typically sent out with these guidelines.</p>
|
||||
The rules are typically published along with these guidelines.</p>
|
||||
<h1 id="whats-new-this-ioccc">WHAT’S NEW THIS IOCCC</h1>
|
||||
<p><strong><code>|</code></strong> This IOCCC runs from <strong>2024-MMM-DD HH:MM:SS UTC</strong> to <strong>YYYY-MMM-DD HH:MM:SS UTC</strong>.
|
||||
** XXX - This date and time is TDB - XXX **.</p>
|
||||
@@ -427,30 +428,31 @@ for be a <strong>fun</strong>ctional UTC time. :-)</p>
|
||||
<p>Until the start of this IOCCC, these rules, guidelines and iocccsize.c
|
||||
(contained in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||||
toolkit</a>)
|
||||
tool should be considered provisional <strong>BETA</strong> versions and may be
|
||||
adjusted <strong>AT ANY TIME</strong>.</p>
|
||||
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> The submit URL should be active on or slightly before <strong>2024-MMM-DD HH:MM:SS UTC</strong>.
|
||||
** XXX - This date and time is TDB - XXX **.</p>
|
||||
<strong>XXX - This date and time is TDB - XXX </strong>.</p>
|
||||
<p>Please wait to submit your entries until after that time.</p>
|
||||
<p>The official rules, guidelines 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 <a href="../faq.html#submit">How to submit</a>.
|
||||
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>The official rules, guidelines 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>
|
||||
<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
|
||||
may not be valid entries this year. What was unique and novel one year
|
||||
might be ‘old’ the next year.</p>
|
||||
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>
|
||||
<ul>
|
||||
<li>look at the original source</li>
|
||||
<li>convert ANSI trigraphs to ASCII</li>
|
||||
<li>C pre-process the source ignoring ‘#include’ lines</li>
|
||||
<li>C pre-process the source ignoring ‘#define’ and ‘#include’ lines</li>
|
||||
<li>C pre-process the source ignoring <code>#include</code> lines</li>
|
||||
<li>C pre-process the source ignoring <code>#define</code> <em>and</em> <code>#include</code> lines</li>
|
||||
<li>run it through a C beautifier</li>
|
||||
<li>examine the algorithm</li>
|
||||
<li>compile it (with flags to enable all warnings)</li>
|
||||
@@ -461,45 +463,48 @@ You should ask yourself if your entry 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
|
||||
cases, a test is not important. Entries that compete for the
|
||||
‘strangest/most creative source layout’ need not do as well as
|
||||
‘<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
|
||||
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 real life
|
||||
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 ‘worst abuse of the
|
||||
rules’ to an entry that illustrates this point in an ironic way.</p>
|
||||
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
|
||||
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 ‘worst abuse of the rules’
|
||||
and then plug the hole next year.</p>
|
||||
to attempt to exploit them. We will award ‘<em>Worst abuse of the rules</em>’ or
|
||||
‘<em>Best abuse of the rules</em>’ and then plug the hole next year.</p>
|
||||
<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 guidelines 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
|
||||
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>We tend to look down on a prime number printer that claims that
|
||||
<p>We tend to look down on a <a href="https://en.wikipedia.org/wiki/Prime_number">prime
|
||||
number</a> printer that claims that
|
||||
16 is a prime number. 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,
|
||||
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
|
||||
under certain conditions. Wise people, when submitting something clever
|
||||
will fully explain such cleverness in their entry’s remarks file.</p>
|
||||
<p>People who are considering to just use some complex mathematical
|
||||
function or state machine to spell out something such as “hello,
|
||||
world!” really really, and we do mean really, do need to be more creative.</p>
|
||||
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>
|
||||
<p>Ultra-obfuscated programs are, in some cases, easier to
|
||||
deobfuscate than subtly-obfuscated programs. Consider using
|
||||
misleading or subtle tricks layered on top of or under an
|
||||
appropriate level of obfuscation. A clean looking program with
|
||||
misleading comments and variable names might be a good start.</p>
|
||||
<p>When programs use VTxxx/ANSI sequences, they should NOT limited to a
|
||||
<p>When programs use VTxxx/ANSI sequences, they should NOT be limited to a
|
||||
specific terminal brand. Those programs that work in a standard xterm
|
||||
are considered more portable.</p>
|
||||
<p><strong><code>|</code></strong> Rule 2 (the size rule) refers to the use of the IOCCC size tool called <code>iocccsize</code>.</p>
|
||||
<p><strong><code>|</code></strong> See the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a> for how to compile and <code>iocccsize</code>.</p>
|
||||
<p><strong><code>|</code></strong> See the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a> for how to compile <code>iocccsize.c</code>.</p>
|
||||
<p><strong><code>|</code></strong> To further clarify rule 2, we subdivided it into two parts, 2a and 2b.</p>
|
||||
<p><strong><code>|</code></strong> Your entry must satisfy BOTH the maximum size rule 2a AND your entry
|
||||
must satisfy the IOCCC size tool rule 2b.</p>
|
||||
@@ -520,32 +525,33 @@ ASCII formfeed, and ASCII carriage return.</p>
|
||||
<p>In cases where the above summary and the algorithm implemented by
|
||||
the IOCCC size tool source code conflict, the algorithm implemented
|
||||
by the IOCCC size tool source code is preferred by the judges.</p>
|
||||
<p><strong><code>|</code></strong> There are at least 2 other reasons for selecting 2503 as the 2nd limit
|
||||
<strong><code>|</code></strong> besides the fact that 2053 is a prime. These reasons
|
||||
<strong><code>|</code></strong> may be searched for and discovered if you are <a href="https://t5k.org/curios/page.php/2503.html">“Curios!” about 2503</a>. :-)
|
||||
<strong><code>|</code></strong> Moreover, 2053 was the number of the kernel disk pack of one of the
|
||||
<strong><code>|</code></strong> judge’s BESM-6, and 2503 is a decimal anagram of 2053.</p>
|
||||
<p><strong><code>|</code></strong> There are at least 2 other reasons for selecting 2503 as the 2nd limit</p>
|
||||
<p><strong><code>|</code></strong> besides the fact that 2503 is a prime. These reasons</p>
|
||||
<p><strong><code>|</code></strong> may be searched for and discovered if you are <a href="https://t5k.org/curios/page.php/2503.html">“Curios!” about 2503</a>. :-)</p>
|
||||
<p><strong><code>|</code></strong> Moreover, 2053 was the number of the kernel disk pack of one of the</p>
|
||||
<p><strong><code>|</code></strong> judge’s BESM-6, and 2503 is a decimal anagram of 2053.</p>
|
||||
<p>Take note that this secondary limit imposed by the IOCCC size tool
|
||||
obviates some of the need to #define C reserved words in an effort
|
||||
obviates some of the need to <code>#define</code> C reserved words in an effort
|
||||
to get around the size limits of rule 2.</p>
|
||||
<p>Yes Virginia, <strong>that is a hint</strong>!</p>
|
||||
<p>We applaud programs that do not issue warnings when compiled.
|
||||
To avoid warnings, you might be tempted to add various -Wno-foobar
|
||||
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</li>
|
||||
<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
|
||||
uses appropriate disable compiler warnings flags for
|
||||
use the appropriate disable compiler warnings flags for
|
||||
both clang and gcc</li>
|
||||
<li>Do something creative</li>
|
||||
</ol>
|
||||
<h1 id="our-likes-and-dislikes">OUR LIKES AND DISLIKES:</h1>
|
||||
<p>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
|
||||
<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
|
||||
as a program that is more well rounded in confusion.</p>
|
||||
<p>Many C compilers dislike the following code, and so do we:</p>
|
||||
<pre><code> #define d define
|
||||
@@ -569,15 +575,15 @@ to compile compile your code using:</p>
|
||||
<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 see <a href="../faq.html#faq3_11">Why do Makefiles use -Weverything with
|
||||
clang?</a> in the <a href="../faq.html">FAQ</a>.</p>
|
||||
<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>be sure to clearly state so in your remarks AS WELL AS in
|
||||
<p>be sure to clearly state so in your remarks <strong>AS WELL AS</strong> in
|
||||
your “how to build” / Makefile.</p>
|
||||
<p>All other things being equal, a program that must turn off fewer
|
||||
warnings will be considered better, for certain values of better.</p>
|
||||
<p>Unless you clearly state otherwise in your remarks AS WELL AS in
|
||||
<p>Unless you clearly state otherwise in your remarks <strong>AS WELL AS</strong> in
|
||||
your “how to build” / Makefile we will compile using:</p>
|
||||
<pre><code> -O3 -std=c11</code></pre>
|
||||
<p>Anyone care to submit an entry that makes gratuitous use of all
|
||||
@@ -596,10 +602,10 @@ flags that would make the program less portable.</p>
|
||||
<p>One side effect of the above is that you cannot assume the use
|
||||
of nested functions such as:</p>
|
||||
<pre><code> main() {
|
||||
| void please_dont_submit_this() {
|
||||
| printf("The machine that goes BING!!\n");
|
||||
void please_dont_submit_this() {
|
||||
printf("The machine that goes BING!!\n");
|
||||
}
|
||||
| please_dont_submit_this();
|
||||
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>
|
||||
@@ -625,7 +631,7 @@ not portable and must not be used:</p>
|
||||
<p>Avoid using <code>varargs.h</code>. Use <code>stdarg.h</code> instead.</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 void. Some broken systems have <code>exit(3)</code>
|
||||
<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>
|
||||
<p><strong><code>|</code></strong> This guideline has a change mark at the very start of this line.</p>
|
||||
<p>Small programs are best when they are short, obscure and concise.
|
||||
@@ -633,8 +639,10 @@ While such programs are not as complex as other winners, they do
|
||||
serve a useful purpose. They are often the only program that people
|
||||
attempt to completely understand. For this reason, we look for
|
||||
programs that are compact, and are instructional.</p>
|
||||
<p>While those who are used to temperatures found on dwarf planet,
|
||||
(yes Virginia, dwarf planets are planets) such as Pluto might be able to
|
||||
<p>While those who are used to temperatures found on <a href="https://science.nasa.gov/dwarf-planets/">dwarf
|
||||
planet</a>,
|
||||
(<strong>yes Virginia, dwarf planets are planets</strong>) such as
|
||||
<a href="https://science.nasa.gov/dwarf-planets/pluto/">Pluto</a> might be able to
|
||||
explain to the Walrus why our seas are boiling hot, the question of
|
||||
whether pigs have wings is likely to remain a debatable point to most.</p>
|
||||
<p>One line programs should be short one line programs: say around 80 to 120
|
||||
@@ -666,21 +674,24 @@ mandate that one must use Microsoft Visual Studio to compile
|
||||
your entry. Nevertheless some of the better IDEs have command-line
|
||||
interfaces to their compilers, once one learns how to invoke a shell.</p>
|
||||
<p>The program must compile and link cleanly in a POSIX-like environment.
|
||||
Therefore do not assume the system has a windows.h include file:</p>
|
||||
Therefore do not assume the system has a
|
||||
<a href="https://en.wikipedia.org/wiki/Windows.h">windows.h</a> include file:</p>
|
||||
<pre><code> #include <windows.h> /* we dislike this include */</code></pre>
|
||||
<p>Unless you are cramped for space, or unless you are entering the
|
||||
‘best one liner’ category, we suggest that you format your program
|
||||
‘<em>Best one liner</em>’ category, we suggest that you format your program
|
||||
in a more creative way than simply forming excessively long lines.</p>
|
||||
<p>At least one judge prefers to maintain the use of the leap-second
|
||||
<p>At least one judge prefers to maintain the use of the
|
||||
<a href="https://en.wikipedia.org/wiki/Leap_second">leap-second</a>
|
||||
as part of the world’s time standard. If your code prints time
|
||||
with seconds, we prefer that your code be capable of printing the
|
||||
time of day during a leap-second where the value in seconds
|
||||
after the minute mark is 60.</p>
|
||||
<p>The “how to build” make process should not be used to try and get
|
||||
around the size limit. It is one thing to make use of a several -D’s
|
||||
<p>The “<em>how to build</em>” make process should not be used to try and get
|
||||
around the size limit. It is one thing to make use of a several <code>-D</code>s
|
||||
on the compile line to help out, but it is quite another to use many
|
||||
bytes of -D’s in order to try and squeeze the source under the size limit.</p>
|
||||
<p>Your source code, post-pre-processing, should not exceed the size of Windows. :-)</p>
|
||||
bytes of <code>-D</code>s in order to try and squeeze the source under the size limit.</p>
|
||||
<p>Your source code, post-pre-processing, should not exceed the size of
|
||||
<a href="https://en.wikipedia.org/wiki/Microsoft_Windows">Windows</a>. :-)</p>
|
||||
<p>The judges, as a group, have a history giving wide degree of latitude
|
||||
to reasonable entries. And recently they have had as much longitudinal
|
||||
variation as it is possible to have on Earth. :-)</p>
|
||||
@@ -711,7 +722,7 @@ For example, one could use the build instructions:</p>
|
||||
<p>and then include special notes in the program “remarks” for
|
||||
alternate / human intervention based building.</p>
|
||||
<p>We want to get away from source that is simply a compact blob of
|
||||
octets. Really try to be more creative than blob coding. <em>HINT!</em></p>
|
||||
octets. Really try to be more creative than blob coding. <strong>HINT!</strong></p>
|
||||
<p>Please do not use things like <code>gzip(1)</code> to get around the size limit.
|
||||
Please try to be much more creative.</p>
|
||||
<p>We really dislike entries that make blatant use of including
|
||||
@@ -760,12 +771,12 @@ software that is not in wide spread use.</p>
|
||||
<p>This is the only guideline that contains the word fizzbin.
|
||||
<strong><code>|</code></strong> However, do you know how to play <a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>?
|
||||
You do?!? (Except on Tuesday)</p>
|
||||
<p>We don’t like entries that use proprietary toolkits such as the M<em>tif,
|
||||
Xv</em>ew, or OpenL*ok toolkits, since not everyone has them. Use of an
|
||||
<p>We don’t like entries that use proprietary toolkits such as the <code>M*tif</code>,
|
||||
<code>Xv*ew</code>, or <code>OpenL*ok</code> toolkits, since not everyone has them. Use an
|
||||
open source toolkit that is widely and freely available instead.</p>
|
||||
<p><strong>NOTE</strong>: The previous guideline in this spot has been replaced by this guideline:</p>
|
||||
<p>X client entries should not to depend on particular items on
|
||||
.Xdefaults. If you must do so, be sure to note the required lines
|
||||
<code>.Xdefaults</code>. If you must do so, be sure to note the required lines
|
||||
in the program “remarks”. They should also not depend on any
|
||||
particular window manager.</p>
|
||||
<p>Try to avoid entries that play silent sound segments or play the
|
||||
@@ -792,7 +803,7 @@ parliament should you have one.</p>
|
||||
<li>do something at least quasi-interesting</li>
|
||||
<li>are portable</li>
|
||||
<li>are unique or novel in their obfuscation style</li>
|
||||
<li>MAKE USE OF A NUMBER OF DIFFERENT TYPES OF OBFUSCATION <== HINT!!</li>
|
||||
<li>MAKE USE OF A NUMBER OF DIFFERENT TYPES OF OBFUSCATION <strong><== HINT!!</strong></li>
|
||||
<li>make us laugh and/or throw up :-) (humor really helps!)</li>
|
||||
<li>make us want to eat good chocolate.</li>
|
||||
</ul>
|
||||
@@ -820,7 +831,8 @@ or Linux curses.</p>
|
||||
<p>Rule 13 states any C source that fails to compile because of unescaped
|
||||
octets with the high bit set (octet value >= 128) will be rejected.
|
||||
Instead of unescaped octets, you should use or escapes:</p>
|
||||
<pre><code> /* 123456789 123456789 123456789 123456 */
|
||||
<pre><code>
|
||||
/* 123456789 123456789 123456789 123456 */
|
||||
char *foo = "This string is 36 octets in length \263";
|
||||
/* This octet requires 4 octets of source ^^^^ */
|
||||
if (strlen(foo) == 36) printf("foo is 36 octets plus a final NUL\n");
|
||||
@@ -833,13 +845,13 @@ otherwise overlook. <strong><<– Hint!</strong></p>
|
||||
author will try format their entry 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 mis-leading formatting, in some cases, may be a plus. On the
|
||||
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,
|
||||
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>
|
||||
into creating a dense blob. Such are the trade-offs that obfuscators face!</p>
|
||||
<p>We prefer code that can run on either a 64-bit or 32-bit processor.
|
||||
However, it is unwise to assume it will run on an i386 or x86 architecture.</p>
|
||||
<p>We believe that Mark Twain’s remark:</p>
|
||||
@@ -848,7 +860,7 @@ However, it is unwise to assume it will run on an i386 or x86 architecture.</p>
|
||||
<p><strong><code>|</code></strong> The <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">IOCCC size tool source</a>
|
||||
is not an original work,
|
||||
unless you are Anthony C Howe, in which case it is original!
|
||||
Submitting source that uses the content iocccsize.c, unless you are
|
||||
Submitting source that uses the content of iocccsize.c, unless you are
|
||||
Anthony C Howe, might run the risk of violating rule 7.</p>
|
||||
<p>Rule 7 does not prohibit you from writing your own obfuscated IOCCC size tool.
|
||||
However if you do, you might wish to make your tool do something more
|
||||
@@ -897,46 +909,47 @@ and state:</p>
|
||||
is given enough time and memory. If the value is not a proper integer, the
|
||||
program will insult a fish named Eric, even if such a fish does not exist.</code></pre>
|
||||
<h1 id="abusing-the-rules">ABUSING THE RULES:</h1>
|
||||
<p>Legal abuse of the rules is somewhat encouraged. Legal rule abuse may
|
||||
involve, but is not limited to, doing things that are technically
|
||||
allowed by the rules and yet do not fit the spirit of what we intended
|
||||
to be submitted.</p>
|
||||
<p>Legal abuse of the <a href="rules.html">rules</a> is somewhat encouraged. Legal rule abuse
|
||||
may involve, but is not limited to, doing things that are technically allowed by
|
||||
the <a href="rules.html">rules</a> and yet do not fit the spirit of what we intended to be
|
||||
submitted.</p>
|
||||
<p>Legal rule abuse is encouraged to help promote creativity. Rule abuse
|
||||
entries, regardless of if they receive an award, result in changes to
|
||||
the next year’s rules and guidelines.</p>
|
||||
<p>Legal abuse of the rules is NOT an invitation to violate the rules.
|
||||
An entry that violates the rules in the opinion of the judges, WILL be
|
||||
disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK! If you
|
||||
the next year’s <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a>.</p>
|
||||
<p>Legal abuse of the <a href="rules.html">rules</a> is NOT an invitation to violate the
|
||||
<a href="rules.html">rules</a>. An entry 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
|
||||
submit two versions; one that does not abuse the rules and one that
|
||||
submit two versions; one that does not abuse the <a href="rules.html">rules</a> and one that
|
||||
does.</p>
|
||||
<p>If you intend to abuse the rules, indicate so in the program
|
||||
“remarks”. You must try to justify why you consider your rule abuse
|
||||
to be allowed under the rules. That is, you must plead your case as
|
||||
to why your entry is valid. Humor and/or creativity help plead a
|
||||
case.</p>
|
||||
<p>If you intend to abuse the <a href="rules.html">rules</a>, indicate so in the program
|
||||
“remarks”. You must try to justify why you consider your rule abuse to be
|
||||
allowed under the <a href="rules.html">rules</a>. That is, you must plead your case as to
|
||||
why your entry is valid. Humor and/or creativity help plead a case.</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>
|
||||
<p>We are often asked why the contest rules and guidelines seem too
|
||||
<p>We are often asked why the contest <a href="rules.html">rules</a> and
|
||||
<a href="guidelines.html">guidelines</a> seem too
|
||||
strange or contain mistakes, flaws or grammatical errors. One reason
|
||||
is that we sometimes make genuine mistakes. But in many cases such
|
||||
problems, flaws or areas of confusion are deliberate. Changes to
|
||||
rules and guidelines in response to rule abuses, are done in a minimal
|
||||
<a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a> in response to rule abuses, are done in a minimal
|
||||
fashion. Often we will deliberately leave behind holes (or introduce
|
||||
new ones) so that future rule abuse may continue. A cleaver author
|
||||
should be able to read them and “drive a truck through the holes” in
|
||||
the rules and guidelines.</p>
|
||||
<p>At the risk of stating the obvious, this contest is a parody of the
|
||||
software development process. The rules and guidelines are only a
|
||||
small part of the overall contest. Even so, one may think the contest
|
||||
rules and guideline process as a parody of the sometimes tragic
|
||||
mismatch between what a customer (or marketing) wants and what
|
||||
engineering delivers. Real programmers must face obfuscated
|
||||
and sometimes conflicting specifications and requirements from marketing,
|
||||
sales, product management an even from customers themselves on a
|
||||
all too regular basis. This is one of the reasons why the rules and
|
||||
guidelines are written in obfuscated form.</p>
|
||||
the <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a>.</p>
|
||||
<p>At the risk of stating the obvious, this contest is a parody of the software
|
||||
development process. The <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a>
|
||||
are only a small part of the overall contest. Even so, one may think the
|
||||
contest <a href="rules.html">rules</a> and <a href="guidelines.html">guideline</a> process as a parody
|
||||
of the sometimes tragic mismatch between what a customer (or marketing) wants
|
||||
and what engineering delivers. Real programmers must face obfuscated and
|
||||
sometimes conflicting specifications and requirements from marketing, sales,
|
||||
product management an even from customers themselves on a all too regular basis.
|
||||
This is one of the reasons why the <a href="rules.html">rules</a> and
|
||||
<a href="guidelines.html">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
|
||||
@@ -949,30 +962,29 @@ the judging process is complete, and then only from entries that have
|
||||
won an award. Because we do not read this information for entries that
|
||||
do not win, we do not know who did not win.</p>
|
||||
<p>The above process helps keep us biased for/against any one particular
|
||||
individual. Therefore you MUST refrain from putting any information
|
||||
individual. Therefore you <strong>MUST</strong> refrain from putting any information
|
||||
that reveals your identity in your entry.</p>
|
||||
<p>Now some people point out that coding style might reveal the information
|
||||
about the others. However we consider this to be simply circumstantial
|
||||
and outside the scope of the above paragraph.</p>
|
||||
<p>Some people, in the past, have attempted to obfuscate their identity by
|
||||
including comments of famous Internet personalities such as Peter Honeyman
|
||||
(<a href="http://www.citi.umich.edu/u/honey/" class="uri">http://www.citi.umich.edu/u/honey/</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 will likely believe
|
||||
it just another attempt at confusion. This guideline is known
|
||||
as the “Peter Honeyman is exempt” guideline.</p>
|
||||
including comments of famous Internet personalities such as <a href="http://www.citi.umich.edu/u/honey">Peter
|
||||
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
|
||||
will likely believe it just another attempt at confusion. This guideline is
|
||||
known as the “Peter Honeyman is exempt” guideline.</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
|
||||
submitting anything to the IOCCC. Perhaps those entries were
|
||||
submitted by one of his students?</p>
|
||||
<p>Hopefully we are <strong>VERY CLEAR</strong> on this point! The rules now strongly state:
|
||||
PLEASE DO NOT put a name of an author, in an obvious way, into your
|
||||
<strong>PLEASE <em>DO NOT</em> put a name of an author</strong>, in an obvious way, into your
|
||||
source code, remarks, data files, etc. The above “Peter Honeyman is
|
||||
exempt” not withstanding.</p>
|
||||
exempt” notwithstanding.</p>
|
||||
<p>We seemed to have digressed again … :-) Returning to the judging process:</p>
|
||||
<p>We prefer to be kept in the dark as much as you are until the final
|
||||
awards are given. We enjoy the surprise of finding out in the end,
|
||||
@@ -983,7 +995,8 @@ attempts to send non-winners into oblivion. We remove all non-winning
|
||||
files, and shred all related paper. By tradition, we do not even
|
||||
reveal the number of entries that we received.</p>
|
||||
<p>During the judging process, a process that spans multiple sessions
|
||||
over a few weeks, post general updates from our <span class="citation" data-cites="IOCCC">@IOCCC</span> twitter account.</p>
|
||||
over a few weeks, post general updates from our <a href="https://fosstodon.org/@ioccc">Mastodon
|
||||
account</a>.</p>
|
||||
<p>Once we have selected the winners, for each category we will tweet:</p>
|
||||
<ul>
|
||||
<li>category name</li>
|
||||
@@ -998,11 +1011,9 @@ entry. They are given the chance to correct mistakes and typos. We
|
||||
often accept their suggestions/comments about our remarks as well.
|
||||
This is done prior to posting the winners to the wide world.</p>
|
||||
<h2 id="an-important-update-to-how-winners-are-announced">An important update to how winners are announced</h2>
|
||||
<p>The IOCCC no longer uses twitter. IOCCC entries will be announced
|
||||
by a git commit to the <a href="https://github.com/ioccc-src/winner">IOCCC entries
|
||||
repo</a>.</p>
|
||||
<p>that, in turn, updates the <a href="https://www.ioccc.org/index.html">official IOCCC
|
||||
website</a>.</p>
|
||||
<p>The IOCCC no longer uses twitter. IOCCC entries will be announced by a git
|
||||
commit to the <a href="https://github.com/ioccc-src/winner">IOCCC entries repo</a> that, in
|
||||
turn, updates the <a href="https://www.ioccc.org/index.html">official IOCCC website</a>.</p>
|
||||
<p>In addition a note is posted to the IOCCC Mastodon account
|
||||
(<a href="https://fosstodon.org/@ioccc" class="uri">https://fosstodon.org/@ioccc</a>).</p>
|
||||
<h2 id="back-to-the-judging-process">Back to the Judging process</h2>
|
||||
@@ -1081,10 +1092,11 @@ an entry simply far exceeds any of the other entries. More often, the
|
||||
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 tweet initial announcement of who won, the name
|
||||
<p>The judges will toot initial announcement of who won, the name
|
||||
of their award, and a very brief description of the winning entry
|
||||
from the <span class="citation" data-cites="IOCCC">@IOCCC</span> twitter handle. Non-twitter users should visit:</p>
|
||||
<pre><code> https://twitter.com/ioccc</code></pre>
|
||||
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>
|
||||
<h2 id="how-the-new-ioccc-winners-will-be-announced">How the new IOCCC winners will be announced</h2>
|
||||
<p><strong><code>|</code></strong> The <a href="../status.html">Current status of the IOCCC</a> will change from <strong>judging</strong> to <strong>closed</strong> .</p>
|
||||
<p><strong><code>|</code></strong> The <strong>contest_status</strong> in the <a href="../status.json">status.json</a> file will change from <strong>judging</strong> to <strong>closed</strong> as well.</p>
|
||||
@@ -1110,10 +1122,16 @@ and on T-Shirts. More than one winner has been turned in a tattoo!</p>
|
||||
<p>Last, but not least, winners receive international fame and flames! :-)</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 rules and the guidelines may (and often do) change from year to year.</p>
|
||||
<p><strong><code>|</code></strong> You should be sure you have the current rules and guidelines prior to submitting entries.</p>
|
||||
<p><strong><code>|</code></strong> Be sure to review the <a href="index.html">IOCCC Rules and Guidelines</a> as
|
||||
<a href="rules.html">rules</a> and the <a href="guidelines.html">guidelines</a> may (and often do) change from year to year.</p>
|
||||
<p><strong><code>|</code></strong> You should be sure you have the current <a href="rules.html">rules</a> and
|
||||
<a href="guidelines.html">guidelines</a> prior to submitting entries.</p>
|
||||
<p><strong><code>|</code></strong> See the <a href="../news.html">Official IOCCC website news</a> for additional information.</p>
|
||||
<p><strong><code>|</code></strong> For the updates and breaking IOCCC news, you are encouraged to follow the <a href="https://fosstodon.org/@ioccc">IOCCC on Mastodon</a> account. See our <a href="../faq.html#try_mastodon">FAQ</a> for more information.</p>
|
||||
<p><strong><code>|</code></strong> For the updates and breaking IOCCC news, you are encouraged to follow
|
||||
the <a href="https://fosstodon.org/@ioccc">IOCCC on Mastodon</a> account. See our
|
||||
<a href="../faq.html#try_mastodon">FAQ</a> for more information. Please be aware that
|
||||
unless you are mentioned you most likely will <strong>NOT</strong> get a notification from
|
||||
the app so you should make sure to check the page.</p>
|
||||
<p><strong><code>|</code></strong> Check out the <a href="https://www.ioccc.org/index.html">Official IOCCC winner web site</a> in general.</p>
|
||||
<p>Leonid A. Broukhis<br>
|
||||
chongo (Landon Curt Noll) /\cc/\</p>
|
||||
|
||||
+151
-134
@@ -1,28 +1,28 @@
|
||||
<!-- START: this line starts content from: inc/guidelines.closed.hdr -->
|
||||
|
||||
# WARNING: These guidelines are OUT OF DATE
|
||||
|
||||
These guidelines are a **very tentative proposal** for the next IOCCC
|
||||
that is **VERY LIKELY** to be updated before the next IOCCC.
|
||||
They are are provided as a **very tentative** hint at what
|
||||
might be used in a future IOCCC.
|
||||
These guidelines are a **VERY TENTATIVE proposal** for the next IOCCC
|
||||
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 guidelines as a historic archive.
|
||||
Please regard these guidelines as a historical archive.
|
||||
|
||||
|
||||
# The IOCCC is closed
|
||||
|
||||
The IOCCC is **NOT** accepting new submissions at this time. See the
|
||||
[IOCCC winning entries page](../years.html) for the entries that have won the IOCCC.
|
||||
[IOCCC winning entries page](../years.html) for the entries that have won the
|
||||
IOCCC in the past.
|
||||
|
||||
Watch both [the IOCCC status page](../status.html) and the
|
||||
[@IOCCC mastodon feed](https://fosstodon.org/@ioccc) for information about future IOCCC openings.
|
||||
[@IOCCC mastodon feed](https://fosstodon.org/@ioccc) for information about
|
||||
future IOCCC openings.
|
||||
|
||||
<!-- END: the next line ends content from: inc/guidelines.closed.hdr -->
|
||||
<!-- This is the last line modified by the tool: bin/gen-status.sh -->
|
||||
# 28th International Obfuscated C Code Contest Official Guidelines
|
||||
|
||||
Copyright © 2024 Leonid A. Broukhis, Landon Curt Noll.
|
||||
Copyright © 2024 Leonid A. Broukhis and Landon Curt Noll.
|
||||
|
||||
All Rights Reserved. Permission for personal, education or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
@@ -53,11 +53,11 @@ submit entries to the [International Obfuscated C Code Contest
|
||||
|
||||
These are not the IOCCC rules, though it does contain comments about
|
||||
them. The guidelines should be viewed as _hints_ and _suggestions_.
|
||||
Entries that violate the guidelines but remain within the rules are
|
||||
allowed. Even so, you are safer if you remain within the guidelines.
|
||||
Entries that violate the guidelines but remain within the rules _are
|
||||
allowed_. Even so, you are safer if you remain within the guidelines.
|
||||
|
||||
You should read the current [IOCCC rules](rules.html), prior to submitting entries.
|
||||
The rules are typically sent out with these guidelines.
|
||||
The rules are typically published along with these guidelines.
|
||||
|
||||
|
||||
# WHAT'S NEW THIS IOCCC
|
||||
@@ -71,21 +71,22 @@ for be a **fun**ctional UTC time. :-)
|
||||
Until the start of this IOCCC, these rules, guidelines 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**.
|
||||
tool should be considered provisional **BETA** versions and **may be
|
||||
adjusted _AT ANY TIME_**.
|
||||
|
||||
The IOCCC submission URL is <https://submit.ioccc.org/>.
|
||||
|
||||
**`|`** The submit URL should be active on or slightly before **2024-MMM-DD HH:MM:SS UTC**.
|
||||
** XXX - This date and time is TDB - XXX **.
|
||||
**XXX - This date and time is TDB - XXX **.
|
||||
|
||||
Please wait to submit your entries until after that time.
|
||||
|
||||
The official rules, guidelines 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 [How to submit](../faq.html#submit).
|
||||
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 official rules, guidelines 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.
|
||||
|
||||
|
||||
# HINTS AND SUGGESTIONS:
|
||||
@@ -94,16 +95,16 @@ You are encouraged to examine the winners of previous contests. See
|
||||
**FOR MORE INFORMATION** for details on how to get previous winners.
|
||||
|
||||
Keep in mind that rules change from year to year, so some winning entries
|
||||
may not be valid entries this year. What was unique and novel one year
|
||||
might be 'old' the next year.
|
||||
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:
|
||||
|
||||
* look at the original source
|
||||
* convert ANSI trigraphs to ASCII
|
||||
* C pre-process the source ignoring '#include' lines
|
||||
* C pre-process the source ignoring '#define' and '#include' lines
|
||||
* C pre-process the source ignoring `#include` lines
|
||||
* C pre-process the source ignoring `#define` _and_ `#include` lines
|
||||
* run it through a C beautifier
|
||||
* examine the algorithm
|
||||
* compile it (with flags to enable all warnings)
|
||||
@@ -115,20 +116,22 @@ You should ask yourself if your entry remains obscure after it has been
|
||||
|
||||
Your entry 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
|
||||
'_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
|
||||
does something interesting when you run it.
|
||||
|
||||
We try to avoid limiting creativity in our rules. As such, we leave
|
||||
the contest open for creative rule interpretation. As in real life
|
||||
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 'worst abuse of the
|
||||
rules' to an entry that illustrates this point in an ironic way.
|
||||
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
|
||||
in an ironic way.
|
||||
|
||||
We do realize that there are holes in the rules, and invite entries
|
||||
to attempt to exploit them. We will award 'worst abuse of the rules'
|
||||
and then plug the hole next year.
|
||||
to attempt to exploit them. We will award '_Worst abuse of the rules_' or
|
||||
'_Best abuse of the rules_' and then plug the hole next year.
|
||||
|
||||
**`|`** Even so, we will attempt to use the smallest plug needed, if not smaller. Or, maybe not. :-)
|
||||
|
||||
@@ -139,18 +142,19 @@ the effort to debug an entry 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 printer that claims that
|
||||
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,
|
||||
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
|
||||
under certain conditions. Wise people, when submitting something clever
|
||||
will fully explain such cleverness in their entry's remarks file.
|
||||
|
||||
People who are considering to just use some complex mathematical
|
||||
function or state machine to spell out something such as "hello,
|
||||
world!" really really, and we do mean really, do need to be more creative.
|
||||
function or state machine to spell out something such as "_hello,
|
||||
world!_" really really, and we do mean really, do need to be more creative.
|
||||
|
||||
Ultra-obfuscated programs are, in some cases, easier to
|
||||
deobfuscate than subtly-obfuscated programs. Consider using
|
||||
@@ -158,13 +162,13 @@ misleading or subtle tricks layered on top of or under an
|
||||
appropriate level of obfuscation. A clean looking program with
|
||||
misleading comments and variable names might be a good start.
|
||||
|
||||
When programs use VTxxx/ANSI sequences, they should NOT limited to a
|
||||
When programs use VTxxx/ANSI sequences, they should NOT be limited to a
|
||||
specific terminal brand. Those programs that work in a standard xterm
|
||||
are considered more portable.
|
||||
|
||||
**`|`** Rule 2 (the size rule) refers to the use of the IOCCC size tool called `iocccsize`.
|
||||
|
||||
**`|`** See the [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) for how to compile and `iocccsize`.
|
||||
**`|`** See the [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) for how to compile `iocccsize.c`.
|
||||
|
||||
**`|`** To further clarify rule 2, we subdivided it into two parts, 2a and 2b.
|
||||
|
||||
@@ -200,48 +204,53 @@ the IOCCC size tool source code conflict, the algorithm implemented
|
||||
by the IOCCC size tool source code is preferred by the judges.
|
||||
|
||||
**`|`** There are at least 2 other reasons for selecting 2503 as the 2nd limit
|
||||
**`|`** besides the fact that 2053 is a prime. These reasons
|
||||
|
||||
**`|`** besides the fact that 2503 is a prime. These reasons
|
||||
|
||||
**`|`** may be searched for and discovered if you are ["Curios!" about 2503](https://t5k.org/curios/page.php/2503.html). :-)
|
||||
|
||||
**`|`** Moreover, 2053 was the number of the kernel disk pack of one of the
|
||||
|
||||
**`|`** judge's BESM-6, and 2503 is a decimal anagram of 2053.
|
||||
|
||||
Take note that this secondary limit imposed by the IOCCC size tool
|
||||
obviates some of the need to #define C reserved words in an effort
|
||||
obviates some of the need to `#define` C reserved words in an effort
|
||||
to get around the size limits of rule 2.
|
||||
|
||||
Yes Virginia, **that is a hint**!
|
||||
|
||||
We applaud programs that do not issue warnings when compiled.
|
||||
To avoid warnings, you might be tempted to add various -Wno-foobar
|
||||
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:
|
||||
|
||||
a) Write code that does not generate compiler warnings
|
||||
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
|
||||
uses appropriate disable compiler warnings flags for
|
||||
use the appropriate disable compiler warnings flags for
|
||||
both clang and gcc
|
||||
d) Do something creative
|
||||
|
||||
|
||||
# OUR LIKES AND DISLIKES:
|
||||
|
||||
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
|
||||
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
|
||||
as a program that is more well rounded in confusion.
|
||||
|
||||
Many C compilers dislike the following code, and so do we:
|
||||
|
||||
```
|
||||
``` <!---c-->
|
||||
#define d define
|
||||
#d foo /* <-- don't expect this to turn into #define foo */
|
||||
```
|
||||
|
||||
When declaring local or global variables, you should declare the type:
|
||||
|
||||
```
|
||||
``` <!---c-->
|
||||
int this_is_fine;
|
||||
this_is_not; /* <-- Try to avoid implicit type declarations */
|
||||
```
|
||||
@@ -273,8 +282,8 @@ to make your code compile warning free using:
|
||||
-Wall -Wextra -Weverything -pedantic
|
||||
```
|
||||
|
||||
.. though see [Why do Makefiles use -Weverything with
|
||||
clang?](../faq.html#faq3_11) in the [FAQ](../faq.html).
|
||||
.. 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:
|
||||
@@ -283,13 +292,13 @@ 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 AS WELL AS in
|
||||
be sure to clearly state so in your remarks **AS WELL AS** in
|
||||
your "how to build" / 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 AS WELL AS in
|
||||
Unless you clearly state otherwise in your remarks **AS WELL AS** in
|
||||
your "how to build" / Makefile we will compile using:
|
||||
|
||||
```
|
||||
@@ -318,12 +327,12 @@ flags that would make the program less portable.
|
||||
One side effect of the above is that you cannot assume the use
|
||||
of nested functions such as:
|
||||
|
||||
```
|
||||
``` <!---c-->
|
||||
main() {
|
||||
| void please_dont_submit_this() {
|
||||
| printf("The machine that goes BING!!\n");
|
||||
void please_dont_submit_this() {
|
||||
printf("The machine that goes BING!!\n");
|
||||
}
|
||||
| please_dont_submit_this();
|
||||
please_dont_submit_this();
|
||||
}
|
||||
```
|
||||
|
||||
@@ -357,7 +366,7 @@ Avoid using `varargs.h`. Use `stdarg.h` instead.
|
||||
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)`
|
||||
The `exit(3)` function returns `void`. Some broken systems have `exit(3)`
|
||||
return `int`, your entry should assume that `exit(3)` returns a `void`.
|
||||
|
||||
**`|`** This guideline has a change mark at the very start of this line.
|
||||
@@ -368,8 +377,10 @@ serve a useful purpose. They are often the only program that people
|
||||
attempt to completely understand. For this reason, we look for
|
||||
programs that are compact, and are instructional.
|
||||
|
||||
While those who are used to temperatures found on dwarf planet,
|
||||
(yes Virginia, dwarf planets are planets) such as Pluto might be able to
|
||||
While those who are used to temperatures found on [dwarf
|
||||
planet](https://science.nasa.gov/dwarf-planets/),
|
||||
(**yes Virginia, dwarf planets are planets**) such as
|
||||
[Pluto](https://science.nasa.gov/dwarf-planets/pluto/) might be able to
|
||||
explain to the Walrus why our seas are boiling hot, the question of
|
||||
whether pigs have wings is likely to remain a debatable point to most.
|
||||
|
||||
@@ -404,28 +415,31 @@ your entry. 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 POSIX-like environment.
|
||||
Therefore do not assume the system has a windows.h include file:
|
||||
Therefore do not assume the system has a
|
||||
[windows.h](https://en.wikipedia.org/wiki/Windows.h) include file:
|
||||
|
||||
```
|
||||
``` <!---c-->
|
||||
#include <windows.h> /* we dislike this include */
|
||||
```
|
||||
|
||||
Unless you are cramped for space, or unless you are entering the
|
||||
'best one liner' category, we suggest that you format your program
|
||||
'_Best one liner_' category, we suggest that you format your program
|
||||
in a more creative way than simply forming excessively long lines.
|
||||
|
||||
At least one judge prefers to maintain the use of the leap-second
|
||||
At least one judge prefers to maintain the use of the
|
||||
[leap-second](https://en.wikipedia.org/wiki/Leap_second)
|
||||
as part of the world's time standard. If your code prints time
|
||||
with seconds, we prefer that your code be capable of printing the
|
||||
time of day during a leap-second where the value in seconds
|
||||
after the minute mark is 60.
|
||||
|
||||
The "how to build" make process should not be used to try and get
|
||||
around the size limit. It is one thing to make use of a several -D's
|
||||
The "_how to build_" make process should not be used to try and get
|
||||
around the size limit. It is one thing to make use of a several `-D`s
|
||||
on the compile line to help out, but it is quite another to use many
|
||||
bytes of -D's in order to try and squeeze the source under the size limit.
|
||||
bytes of `-D`s in order to try and squeeze the source under the size limit.
|
||||
|
||||
Your source code, post-pre-processing, should not exceed the size of Windows. :-)
|
||||
Your source code, post-pre-processing, should not exceed the size of
|
||||
[Windows](https://en.wikipedia.org/wiki/Microsoft_Windows). :-)
|
||||
|
||||
The judges, as a group, have a history giving wide degree of latitude
|
||||
to reasonable entries. And recently they have had as much longitudinal
|
||||
@@ -471,7 +485,7 @@ and then include special notes in the program "remarks" for
|
||||
alternate / human intervention based building.
|
||||
|
||||
We want to get away from source that is simply a compact blob of
|
||||
octets. Really try to be more creative than blob coding. *HINT!*
|
||||
octets. Really try to be more creative than blob coding. **HINT!**
|
||||
|
||||
Please do not use things like `gzip(1)` to get around the size limit.
|
||||
Please try to be much more creative.
|
||||
@@ -507,13 +521,13 @@ they do not work as documented.
|
||||
Please note that the C source below, besides lacking in obfuscation,
|
||||
is NOT the smallest C source file that when compiled and run, dumps core:
|
||||
|
||||
```
|
||||
``` <!---c-->
|
||||
main;
|
||||
```
|
||||
|
||||
We do not like writable strings. That is, we don't want stuff like:
|
||||
|
||||
```
|
||||
``` <!---c-->
|
||||
char *T = "So many primes, so little time!";
|
||||
...
|
||||
T[14] = ';';
|
||||
@@ -522,7 +536,7 @@ We do not like writable strings. That is, we don't want stuff like:
|
||||
Please don't make use of this feature, even if your system allows it.
|
||||
However, initialized char arrays are OK to write over. This is OK:
|
||||
|
||||
```
|
||||
``` <!---c-->
|
||||
char b[] = "Is this OK";
|
||||
b[9] = 'K';
|
||||
```
|
||||
@@ -545,14 +559,14 @@ This is the only guideline that contains the word fizzbin.
|
||||
**`|`** However, do you know how to play [fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin)?
|
||||
You do?!? (Except on Tuesday)
|
||||
|
||||
We don't like entries that use proprietary toolkits such as the M*tif,
|
||||
Xv*ew, or OpenL*ok toolkits, since not everyone has them. Use of an
|
||||
We don't like entries that use proprietary toolkits such as the `M*tif`,
|
||||
`Xv*ew`, or `OpenL*ok` toolkits, since not everyone has them. Use an
|
||||
open source toolkit that is widely and freely available instead.
|
||||
|
||||
**NOTE**: The previous guideline in this spot has been replaced by this guideline:
|
||||
|
||||
X client entries should not to depend on particular items on
|
||||
.Xdefaults. If you must do so, be sure to note the required lines
|
||||
`.Xdefaults`. If you must do so, be sure to note the required lines
|
||||
in the program "remarks". They should also not depend on any
|
||||
particular window manager.
|
||||
|
||||
@@ -586,7 +600,7 @@ We like programs that:
|
||||
* do something at least quasi-interesting
|
||||
* are portable
|
||||
* are unique or novel in their obfuscation style
|
||||
* MAKE USE OF A NUMBER OF DIFFERENT TYPES OF OBFUSCATION <== HINT!!
|
||||
* MAKE USE OF A NUMBER OF DIFFERENT TYPES OF OBFUSCATION **<== HINT!!**
|
||||
* make us laugh and/or throw up :-) (humor really helps!)
|
||||
* make us want to eat good chocolate.
|
||||
|
||||
@@ -621,7 +635,8 @@ Rule 13 states any C source that fails to compile because of unescaped
|
||||
octets with the high bit set (octet value >= 128) will be rejected.
|
||||
Instead of unescaped octets, you should use \octal or \hex escapes:
|
||||
|
||||
```
|
||||
``` <!---c-->
|
||||
|
||||
/* 123456789 123456789 123456789 123456 */
|
||||
char *foo = "This string is 36 octets in length \263";
|
||||
/* This octet requires 4 octets of source ^^^^ */
|
||||
@@ -638,14 +653,14 @@ Anyone can format their code into a dense blob. A really clever
|
||||
author will try format their entry 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 mis-leading formatting, in some cases, may be a plus. On the
|
||||
and misleading formatting, in some cases, may be a plus. On the
|
||||
other hand, a misleading code style requires more source bytes.
|
||||
|
||||
If you do elect to use misleading formatting and comments, we
|
||||
suggest you remark on this point in your remarks where you talk
|
||||
about why you think your entry 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!
|
||||
into creating a dense blob. Such are the trade-offs that obfuscators face!
|
||||
|
||||
We prefer code that can run on either a 64-bit or 32-bit processor.
|
||||
However, it is unwise to assume it will run on an i386 or x86 architecture.
|
||||
@@ -661,7 +676,7 @@ is a good guideline for those writing code for the IOCCC.
|
||||
**`|`** The [IOCCC size tool source](https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c)
|
||||
is not an original work,
|
||||
unless you are Anthony C Howe, in which case it is original!
|
||||
Submitting source that uses the content iocccsize.c, unless you are
|
||||
Submitting source that uses the content of iocccsize.c, unless you are
|
||||
Anthony C Howe, might run the risk of violating rule 7.
|
||||
|
||||
Rule 7 does not prohibit you from writing your own obfuscated IOCCC size tool.
|
||||
@@ -753,52 +768,53 @@ and state:
|
||||
|
||||
# ABUSING THE RULES:
|
||||
|
||||
Legal abuse of the rules is somewhat encouraged. Legal rule abuse may
|
||||
involve, but is not limited to, doing things that are technically
|
||||
allowed by the rules and yet do not fit the spirit of what we intended
|
||||
to be submitted.
|
||||
Legal abuse of the [rules](rules.html) is somewhat encouraged. Legal rule abuse
|
||||
may involve, but is not limited to, doing things that are technically allowed by
|
||||
the [rules](rules.html) and yet do not fit the spirit of what we intended to be
|
||||
submitted.
|
||||
|
||||
Legal rule abuse is encouraged to help promote creativity. Rule abuse
|
||||
entries, regardless of if they receive an award, result in changes to
|
||||
the next year's rules and guidelines.
|
||||
the next year's [rules](rules.html) and [guidelines](guidelines.html).
|
||||
|
||||
Legal abuse of the rules is NOT an invitation to violate the rules.
|
||||
An entry that violates the rules in the opinion of the judges, WILL be
|
||||
disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK! If you
|
||||
Legal abuse of the [rules](rules.html) is NOT an invitation to violate the
|
||||
[rules](rules.html). An entry 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
|
||||
submit two versions; one that does not abuse the rules and one that
|
||||
submit two versions; one that does not abuse the [rules](rules.html) and one that
|
||||
does.
|
||||
|
||||
If you intend to abuse the rules, indicate so in the program
|
||||
"remarks". You must try to justify why you consider your rule abuse
|
||||
to be allowed under the rules. That is, you must plead your case as
|
||||
to why your entry is valid. Humor and/or creativity help plead a
|
||||
case.
|
||||
If you intend to abuse the [rules](rules.html), indicate so in the program
|
||||
"remarks". You must try to justify why you consider your rule abuse to be
|
||||
allowed under the [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.
|
||||
|
||||
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.
|
||||
|
||||
We are often asked why the contest rules and guidelines seem too
|
||||
We are often asked why the contest [rules](rules.html) and
|
||||
[guidelines](guidelines.html) seem too
|
||||
strange or contain mistakes, flaws or grammatical errors. One reason
|
||||
is that we sometimes make genuine mistakes. But in many cases such
|
||||
problems, flaws or areas of confusion are deliberate. Changes to
|
||||
rules and guidelines in response to rule abuses, are done in a minimal
|
||||
[rules](rules.html) and [guidelines](guidelines.html) in response to rule abuses, are done in a minimal
|
||||
fashion. Often we will deliberately leave behind holes (or introduce
|
||||
new ones) so that future rule abuse may continue. A cleaver author
|
||||
should be able to read them and "drive a truck through the holes" in
|
||||
the rules and guidelines.
|
||||
the [rules](rules.html) and [guidelines](guidelines.html).
|
||||
|
||||
At the risk of stating the obvious, this contest is a parody of the
|
||||
software development process. The rules and guidelines are only a
|
||||
small part of the overall contest. Even so, one may think the contest
|
||||
rules and guideline process as a parody of the sometimes tragic
|
||||
mismatch between what a customer (or marketing) wants and what
|
||||
engineering delivers. Real programmers must face obfuscated
|
||||
and sometimes conflicting specifications and requirements from marketing,
|
||||
sales, product management an even from customers themselves on a
|
||||
all too regular basis. This is one of the reasons why the rules and
|
||||
guidelines are written in obfuscated form.
|
||||
At the risk of stating the obvious, this contest is a parody of the software
|
||||
development process. The [rules](rules.html) and [guidelines](guidelines.html)
|
||||
are only a small part of the overall contest. Even so, one may think the
|
||||
contest [rules](rules.html) and [guideline](guidelines.html) process as a parody
|
||||
of the sometimes tragic mismatch between what a customer (or marketing) wants
|
||||
and what engineering delivers. Real programmers must face obfuscated and
|
||||
sometimes conflicting specifications and requirements from marketing, sales,
|
||||
product management an even from customers themselves on a all too regular basis.
|
||||
This is one of the reasons why the [rules](rules.html) and
|
||||
[guidelines](guidelines.html) are written in obfuscated form.
|
||||
|
||||
|
||||
# JUDGING PROCESS:
|
||||
@@ -817,7 +833,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.
|
||||
|
||||
The above process helps keep us biased for/against any one particular
|
||||
individual. Therefore you MUST refrain from putting any information
|
||||
individual. Therefore you **MUST** refrain from putting any information
|
||||
that reveals your identity in your entry.
|
||||
|
||||
Now some people point out that coding style might reveal the information
|
||||
@@ -825,15 +841,14 @@ about the others. However we consider this to be simply circumstantial
|
||||
and outside the scope of the above paragraph.
|
||||
|
||||
Some people, in the past, have attempted to obfuscate their identity by
|
||||
including comments of famous Internet personalities such as Peter Honeyman
|
||||
(<http://www.citi.umich.edu/u/honey/>). The 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 will likely believe
|
||||
it just another attempt at confusion. This guideline is known
|
||||
as the "Peter Honeyman is exempt" guideline.
|
||||
including comments of famous Internet personalities such as [Peter
|
||||
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
|
||||
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
|
||||
@@ -842,9 +857,9 @@ submitting anything to the IOCCC. Perhaps those entries were
|
||||
submitted by one of his students?
|
||||
|
||||
Hopefully we are **VERY CLEAR** on this point! The rules now strongly state:
|
||||
PLEASE DO NOT put a name of an author, in an obvious way, into your
|
||||
**PLEASE _DO NOT_ put a name of an author**, in an obvious way, into your
|
||||
source code, remarks, data files, etc. The above "Peter Honeyman is
|
||||
exempt" not withstanding.
|
||||
exempt" notwithstanding.
|
||||
|
||||
We seemed to have digressed again ... :-) Returning to the judging process:
|
||||
|
||||
@@ -859,7 +874,8 @@ files, and shred all related paper. By tradition, we do not even
|
||||
reveal the number of entries that we received.
|
||||
|
||||
During the judging process, a process that spans multiple sessions
|
||||
over a few weeks, post general updates from our @IOCCC twitter account.
|
||||
over a few weeks, post general updates from our [Mastodon
|
||||
account](https://fosstodon.org/@ioccc).
|
||||
|
||||
Once we have selected the winners, for each category we will tweet:
|
||||
|
||||
@@ -878,12 +894,9 @@ This is done prior to posting the winners to the wide world.
|
||||
|
||||
## An important update to how winners are announced
|
||||
|
||||
The IOCCC no longer uses twitter. IOCCC entries will be announced
|
||||
by a git commit to the [IOCCC entries
|
||||
repo](https://github.com/ioccc-src/winner).
|
||||
|
||||
that, in turn, updates the [official IOCCC
|
||||
website](https://www.ioccc.org/index.html).
|
||||
The IOCCC no longer uses twitter. IOCCC entries will be announced by a git
|
||||
commit to the [IOCCC entries repo](https://github.com/ioccc-src/winner) that, in
|
||||
turn, updates the [official IOCCC website](https://www.ioccc.org/index.html).
|
||||
|
||||
In addition a note is posted to the IOCCC Mastodon account
|
||||
(<https://fosstodon.org/@ioccc>).
|
||||
@@ -980,13 +993,11 @@ Winning source is called prog.c A compiled binary is called prog.
|
||||
|
||||
# ANNOUNCEMENT OF WINNERS:
|
||||
|
||||
The judges will tweet initial announcement of who won, the name
|
||||
The judges will toot initial announcement of who won, the name
|
||||
of their award, and a very brief description of the winning entry
|
||||
from the @IOCCC twitter handle. Non-twitter users should visit:
|
||||
|
||||
```
|
||||
https://twitter.com/ioccc
|
||||
```
|
||||
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.
|
||||
|
||||
|
||||
## How the new IOCCC winners will be announced
|
||||
@@ -1043,13 +1054,19 @@ Last, but not least, winners receive international fame and flames! :-)
|
||||
|
||||
**`|`** For questions or comments about the contest, see [Contacting the IOCCC](../contact.html).
|
||||
|
||||
**`|`** Be sure to review the [IOCCC Rules and Guidelines](index.html) as rules and the guidelines may (and often do) change from year to year.
|
||||
**`|`** Be sure to review the [IOCCC Rules and Guidelines](index.html) as
|
||||
[rules](rules.html) and the [guidelines](guidelines.html) may (and often do) change from year to year.
|
||||
|
||||
**`|`** You should be sure you have the current rules and guidelines prior to submitting entries.
|
||||
**`|`** You should be sure you have the current [rules](rules.html) and
|
||||
[guidelines](guidelines.html) prior to submitting entries.
|
||||
|
||||
**`|`** See the [Official IOCCC website news](../news.html) for additional information.
|
||||
|
||||
**`|`** For the updates and breaking IOCCC news, you are encouraged to follow the [IOCCC on Mastodon](https://fosstodon.org/@ioccc) account. See our [FAQ](../faq.html#try_mastodon) for more information.
|
||||
**`|`** For the updates and breaking IOCCC news, you are encouraged to follow
|
||||
the [IOCCC on Mastodon](https://fosstodon.org/@ioccc) account. See our
|
||||
[FAQ](../faq.html#try_mastodon) for more information. Please be aware that
|
||||
unless you are mentioned you most likely will **NOT** get a notification from
|
||||
the app so you should make sure to check the page.
|
||||
|
||||
**`|`** Check out the [Official IOCCC winner web site](https://www.ioccc.org/index.html) in general.
|
||||
|
||||
|
||||
+52
-43
@@ -384,20 +384,22 @@
|
||||
<!-- BEFORE: 1st line of markdown file: next/rules.md -->
|
||||
<!-- START: this line starts content from: inc/rules.closed.hdr -->
|
||||
<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
|
||||
that is <strong>VERY LIKELY</strong> to be updated before the next IOCCC.
|
||||
They are are provided as a <strong>very tentative</strong> hint at what
|
||||
might be used in a future IOCCC.</p>
|
||||
<p>Please regard these rules as a historic archive.</p>
|
||||
<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.</p>
|
||||
<p>The IOCCC is <strong>NOT</strong> accepting new submissions at this time. See the <a href="../years.html">IOCCC
|
||||
winning entries page</a> for the entries that have won the IOCCC in
|
||||
the past.</p>
|
||||
<p>Watch both <a href="../status.html">the IOCCC status page</a> and the
|
||||
<a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> mastodon feed</a> for information about future IOCCC openings.</p>
|
||||
<a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> mastodon feed</a> for information about
|
||||
future IOCCC openings.</p>
|
||||
<!-- END: the next line ends content from: inc/rules.closed.hdr -->
|
||||
<!-- This is the last line modified by the tool: bin/gen-status.sh -->
|
||||
<h1 id="th-international-obfuscated-c-code-contest-official-rules">28th International Obfuscated C Code Contest Official Rules</h1>
|
||||
<p><strong><code>|</code></strong> Copyright © 2024 Leonid A. Broukhis, Landon Curt Noll.</p>
|
||||
<p><strong><code>|</code></strong> Copyright © 2024 Leonid A. Broukhis and Landon Curt Noll.</p>
|
||||
<p>All Rights Reserved. Permission for personal, education or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in
|
||||
@@ -408,7 +410,7 @@ writing by <a href="../contact.html">contacting the judges</a>.</p>
|
||||
<h3 id="change-marks">Change marks</h3>
|
||||
<p><strong><code>|</code></strong> <strong>← Lines that start with this symbol indicate a change from the previous IOCCC</strong></p>
|
||||
<p>Most lines (we sometimes make mistakes) that were modified since the previous
|
||||
IOCCC start the <strong><code>|</code></strong> symbol.</p>
|
||||
IOCCC start with the <strong><code>|</code></strong> symbol.</p>
|
||||
<h1 id="obfuscate-defined">Obfuscate defined:</h1>
|
||||
<p>tr.v. -cated, -cating, -cates.
|
||||
<BR><BR>
|
||||
@@ -421,7 +423,7 @@ IOCCC start the <strong><code>|</code></strong> symbol.</p>
|
||||
<h1 id="goals-of-the-contest">Goals of the Contest</h1>
|
||||
<p>The goals of the IOCCC:</p>
|
||||
<ul>
|
||||
<li>To write the most Obscure/Obfuscated C program within the rules.</li>
|
||||
<li>To write the most Obscure/Obfuscated C program within the <a href="rules.html">rules</a>.</li>
|
||||
<li>To show the importance of programming style, in an ironic way.</li>
|
||||
<li>To stress C compilers with unusual code.</li>
|
||||
<li>To illustrate some of the subtleties of the C language.</li>
|
||||
@@ -429,23 +431,22 @@ IOCCC start the <strong><code>|</code></strong> symbol.</p>
|
||||
</ul>
|
||||
<h1 id="important-ioccc-dates">Important IOCCC dates</h1>
|
||||
<p><strong><code>|</code></strong> This IOCCC runs from <strong>2019-Dec-26 06:01:41 UTC</strong> to <strong>2020-Mar-15 06:26:49 UTC</strong>.</p>
|
||||
<p>Until the start of this IOCCC, these rules, guidelines and iocccsize.c
|
||||
(contained in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||||
<p>Until the start of this IOCCC, these <a href="rules.html">rules</a>,
|
||||
<a href="guidelines.html">guidelines</a> and iocccsize.c (contained in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||||
toolkit</a> and invoked by the
|
||||
<code>mkiocccentry</code> tool)
|
||||
should be considered provisional <strong>BETA</strong> versions and may be
|
||||
adjusted <strong>AT ANY TIME</strong>.</p>
|
||||
<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:
|
||||
<a href="https://submit.ioccc.org/">https://submit.ioccc.org/</a>, at all other
|
||||
times that link is likely to be unresponsive.</p>
|
||||
<p>Please check the <a href="../faq.html#submit">How to enter link</a> link
|
||||
<p>Please check the <a href="../faq.html#submit">How to enter FAQ</a>
|
||||
for <strong>important information</strong> on how to submit to the IOCCC.</p>
|
||||
<p><strong><code>|</code></strong> The submit URL should be active on or slightly before <strong>2020-Jan-15 12:21:37 UTC</strong>.
|
||||
Please wait to submit your entries until after that time.</p>
|
||||
<p>The official rules, guidelines will be available on the <a href="../index.html">official IOCCC
|
||||
website</a> on or slightly before 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>
|
||||
<p>The official <a href="rules.html">rules</a> and <a href="guidelines.html">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>
|
||||
<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>
|
||||
@@ -461,15 +462,15 @@ entry submission URL.</p>
|
||||
<p>The size of your program source <strong>MUST BE <= 4096 bytes</strong>in length.</p>
|
||||
<h2 id="rule-2b">Rule 2b</h2>
|
||||
<p><strong><code>|</code></strong> When your program source is fed as input to the current IOCCC size
|
||||
tool, and the IOCCC size tool -i command line option is used, the
|
||||
tool, and the IOCCC size tool <code>-i</code> command line option is used, the
|
||||
value printed <strong>shall not exceed 2503</strong>.</p>
|
||||
<p><strong><code>|</code></strong> The source to the current IOCCC size tool is found in the
|
||||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry tool repo</a>. If you use
|
||||
the <code>mkiocccentry</code> tool (which we <strong>STRONGLY recommend you do</strong>) will invoke
|
||||
the <code>mkiocccentry</code> tool (which we <strong>STRONGLY recommend you do</strong>) it will invoke
|
||||
this tool before packaging your entry for submission.</p>
|
||||
<h2 id="rule-3">Rule 3</h2>
|
||||
<p>Submissions should be performed using the instructions outlined at:
|
||||
the <a href="../faq.html#submit">How to enter link</a> link.</p>
|
||||
the <a href="../faq.html#submit">How to enter FAQ</a>.</p>
|
||||
<p>To submit to an open IOCCC, you must use the <a href="https://submit.ioccc.org/">IOCCC submit server</a>.</p>
|
||||
<p>When the IOCCC is not open, that link will likely be unresponsive.</p>
|
||||
<p><strong><code>|</code></strong> The submit URL should be active on or slightly before <strong>2020-Jan-15 12:21:37 UTC</strong>.
|
||||
@@ -487,8 +488,8 @@ files you submit.</p>
|
||||
<p>If you entry wishes to modify such content, it <strong>MUST</strong> first copy the
|
||||
file to a new filename and then modify that copy.</p>
|
||||
<h2 id="rule-6">Rule 6</h2>
|
||||
<p><strong><code>|</code></strong> I am not a rule, I am a <code>free(void \*human)</code>!</p>
|
||||
<pre><code>| while (!understand(ioccc(rule(that(you(are(number(6)))))))) { ha_ha_ha(); }</code></pre>
|
||||
<p><strong><code>|</code></strong> I am not a rule, I am a <code>free(void *human)</code>!</p>
|
||||
<pre><code> while (!understand(ioccc(rule(that(you(are(number(6)))))))) { ha_ha_ha(); }</code></pre>
|
||||
<h2 id="rule-7">Rule 7</h2>
|
||||
<p>The obfuscated C program must be an original work that you own.</p>
|
||||
<p>You (the author(s)) must own the contents of your submission OR
|
||||
@@ -497,16 +498,16 @@ 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 Rule 18.</p>
|
||||
<p>If you submit any content that is owned by others, you <strong>MUST</strong>
|
||||
detail that ownership (i.e., who owns what) and document the
|
||||
permission you obtained.</p>
|
||||
detail that ownership (i.e., who owns what) <strong>AND document the
|
||||
permission you obtained</strong>.</p>
|
||||
<p>Please note that the IOCCC size tool is <strong>NOT</strong> an original work.</p>
|
||||
<h2 id="rule-8">Rule 8</h2>
|
||||
<p><strong><code>|</code></strong> Entries must be received prior to the end of this IOCCC which is
|
||||
<strong>2024-MMM-DD HH:MM:SS UTC</strong>. ** XXX - This date and time is TDB - XXX **.</p>
|
||||
<strong>2024-MMM-DD HH:MM:SS UTC</strong>. <strong>XXX - This date and time is TDB - XXX </strong>.</p>
|
||||
<p>A confirmation of submission will be sent to the submitting email address
|
||||
before the close of the contest.</p>
|
||||
<h2 id="rule-9">Rule 9</h2>
|
||||
<p><strong><code>|</code></strong> Each person may submit up to and including 8.000000 entries per contest.</p>
|
||||
<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>
|
||||
<h2 id="rule-10">Rule 10</h2>
|
||||
<p>Entries requiring human interaction to be initially compiled are not permitted.</p>
|
||||
@@ -514,8 +515,8 @@ before the close of the contest.</p>
|
||||
<p>Programs that require special privileges (<code>setuid(2)</code>, <code>setgid(2)</code>, super-user,
|
||||
special owner, special group, etc.) are still highly discouraged. We
|
||||
do not guarantee these functions will behave as you expect on our test
|
||||
platforms. If your program needs special permissions <strong>please</strong> document
|
||||
them in the remarks file.</p>
|
||||
platforms. If your program needs special permissions <strong>please document
|
||||
them</strong> in the remarks file.</p>
|
||||
<h2 id="rule-12">Rule 12</h2>
|
||||
<p>Legal abuse of the rules is somewhat encouraged. An entry that, in
|
||||
the opinion of the judges, violates the rules will be disqualified.
|
||||
@@ -547,7 +548,7 @@ 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>
|
||||
<h2 id="rule-16">Rule 16</h2>
|
||||
<p>You are <strong>STRONGLY</strong> encouraged to submit a previously unpublished and
|
||||
<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
|
||||
discouraged. As we judge anonymously, submissions that have already
|
||||
been published may be disqualified.</p>
|
||||
@@ -557,12 +558,14 @@ hints, comments, build and info files <strong>MUST</strong> be less than or equa
|
||||
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 rule.</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 rule.</p>
|
||||
<h2 id="rule-18">Rule 18</h2>
|
||||
<p>The entirety of your entry 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</strong> have permission from the owner(s) to submit their content.</p>
|
||||
you <strong>MUST HAVE PERMISSION</strong> from the owner(s) to submit their content.</p>
|
||||
<p>You must not submit anything that cannot be submitted under that license.</p>
|
||||
<h2 id="rule-19">Rule 19</h2>
|
||||
<p>The remarks file must be written in markdown format. See
|
||||
@@ -570,9 +573,9 @@ the Daring Fireball <a href="http://daringfireball.net/projects/markdown/basics"
|
||||
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>
|
||||
<h2 id="rule-20">Rule 20</h2>
|
||||
<p>The how to build instructions must be in Makefile format. See <a href="../faq.html#make_compatibility">What kind of
|
||||
make(1) compatibility does the IOCCC support and will it support other
|
||||
kinds?</a> for more details on what we support.</p>
|
||||
<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>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>.
|
||||
@@ -593,7 +596,7 @@ detect if required rules exist in your Makefile.</p>
|
||||
<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
|
||||
<strong>MAY</strong> create subdirectories below the current directory, or in <code>/tmp</code>,
|
||||
or in <code>/var/tmp</code> provided that “<strong>.</strong>” is <strong>NOT</strong> the first octet in any
|
||||
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>
|
||||
<h2 id="rule-22">Rule 22</h2>
|
||||
<p>Catch 22:</p>
|
||||
@@ -605,7 +608,7 @@ NOT know who is submitting entries to the IOCCC.</p>
|
||||
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>
|
||||
<p>Yes, Virginia, <strong>we REALLY mean it</strong>!</p>
|
||||
<p>Yes, Virginia, <strong>WE REALLY MEAN IT!</strong></p>
|
||||
<h2 id="rule-23">Rule 23</h2>
|
||||
<p>This prime rule number is reserved for future use.</p>
|
||||
<h2 id="rule-24">Rule 24</h2>
|
||||
@@ -618,10 +621,16 @@ for disqualification of your entry.</p>
|
||||
<p><strong><code>|</code></strong> Rule 27 is reserved for something cubic. :-)</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 rules and the guidelines may (and often do) change from year to year.</p>
|
||||
<p><strong><code>|</code></strong> You should be sure you have the current rules and guidelines prior to submitting entries.</p>
|
||||
<p><strong><code>|</code></strong> Be sure to review the <a href="index.html">IOCCC Rules and Guidelines</a> as
|
||||
<a href="rules.html">rules</a> and the <a href="guidelines.html">guidelines</a> may (and often do) change from year to year.</p>
|
||||
<p><strong><code>|</code></strong> You should be sure you have the current <a href="rules.html">rules</a> and
|
||||
<a href="guidelines.html">guidelines</a> prior to submitting entries.</p>
|
||||
<p><strong><code>|</code></strong> See the <a href="../news.html">Official IOCCC website news</a> for additional information.</p>
|
||||
<p><strong><code>|</code></strong> For the updates and breaking IOCCC news, you are encouraged to follow the <a href="https://fosstodon.org/@ioccc">IOCCC on Mastodon</a> account. See our <a href="../faq.html#try_mastodon">FAQ</a> for more information.</p>
|
||||
<p><strong><code>|</code></strong> For the updates and breaking IOCCC news, you are encouraged to follow
|
||||
the <a href="https://fosstodon.org/@ioccc">IOCCC on Mastodon</a> account. See our
|
||||
<a href="../faq.html#try_mastodon">FAQ</a> for more information. Please do note that unless
|
||||
you are mentioned by us you will <strong>NOT</strong> get a notification from the app so you
|
||||
should refresh the page even if you do follow us.</p>
|
||||
<p><strong><code>|</code></strong> Check out the <a href="https://www.ioccc.org/index.html">Official IOCCC winner web site</a> in general.</p>
|
||||
<p>Leonid A. Broukhis<br>
|
||||
chongo (Landon Curt Noll) <code>/\cc/\</code></p>
|
||||
|
||||
+52
-44
@@ -2,27 +2,29 @@
|
||||
|
||||
# WARNING: These rules are OUT OF DATE
|
||||
|
||||
These rules are a **very tentative proposal** for the next IOCCC
|
||||
that is **VERY LIKELY** to be updated before the next IOCCC.
|
||||
They are are provided as a **very tentative** hint at what
|
||||
might be used in a future IOCCC.
|
||||
These rules are a **VERY TENTATIVE proposal** for the next IOCCC
|
||||
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 historic archive.
|
||||
Please regard these rules as a historical archive.
|
||||
|
||||
|
||||
# The IOCCC is closed
|
||||
|
||||
The IOCCC is **NOT** accepting new submissions at this time. See the
|
||||
[IOCCC winning entries page](../years.html) for the entries that have won the IOCCC.
|
||||
The IOCCC is **NOT** accepting new submissions at this time. See the [IOCCC
|
||||
winning entries page](../years.html) for the entries that have won the IOCCC in
|
||||
the past.
|
||||
|
||||
Watch both [the IOCCC status page](../status.html) and the
|
||||
[@IOCCC mastodon feed](https://fosstodon.org/@ioccc) for information about future IOCCC openings.
|
||||
[@IOCCC mastodon feed](https://fosstodon.org/@ioccc) for information about
|
||||
future IOCCC openings.
|
||||
|
||||
<!-- END: the next line ends content from: inc/rules.closed.hdr -->
|
||||
<!-- This is the last line modified by the tool: bin/gen-status.sh -->
|
||||
# 28th International Obfuscated C Code Contest Official Rules
|
||||
|
||||
**`|`** Copyright © 2024 Leonid A. Broukhis, Landon Curt Noll.
|
||||
**`|`** Copyright © 2024 Leonid A. Broukhis and Landon Curt Noll.
|
||||
|
||||
All Rights Reserved. Permission for personal, education or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
@@ -42,7 +44,7 @@ writing by [contacting the judges](../contact.html).
|
||||
**`|`** **← Lines that start with this symbol indicate a change from the previous IOCCC**
|
||||
|
||||
Most lines (we sometimes make mistakes) that were modified since the previous
|
||||
IOCCC start the **`|`** symbol.
|
||||
IOCCC start with the **`|`** symbol.
|
||||
|
||||
|
||||
# Obfuscate defined:
|
||||
@@ -61,7 +63,7 @@ tr.v. -cated, -cating, -cates.
|
||||
|
||||
The goals of the IOCCC:
|
||||
|
||||
* To write the most Obscure/Obfuscated C program within the rules.
|
||||
* To write the most Obscure/Obfuscated C program within the [rules](rules.html).
|
||||
* To show the importance of programming style, in an ironic way.
|
||||
* To stress C compilers with unusual code.
|
||||
* To illustrate some of the subtleties of the C language.
|
||||
@@ -72,27 +74,26 @@ The goals of the IOCCC:
|
||||
|
||||
**`|`** This IOCCC runs from **2019-Dec-26 06:01:41 UTC** to **2020-Mar-15 06:26:49 UTC**.
|
||||
|
||||
Until the start of this IOCCC, these rules, guidelines and iocccsize.c
|
||||
(contained in the [mkiocccentry
|
||||
Until the start of this IOCCC, these [rules](rules.html),
|
||||
[guidelines](guidelines.html) and iocccsize.c (contained in the [mkiocccentry
|
||||
toolkit](https://github.com/ioccc-src/mkiocccentry) and invoked by the
|
||||
`mkiocccentry` tool)
|
||||
should be considered provisional **BETA** versions and may be
|
||||
adjusted **AT ANY TIME**.
|
||||
`mkiocccentry(1)` tool) should be considered provisional **BETA** versions and
|
||||
**may be adjusted _AT ANY TIME_**.
|
||||
|
||||
When the IOCCC is open, the submission URL is:
|
||||
[https://submit.ioccc.org/](https://submit.ioccc.org/), at all other
|
||||
times that link is likely to be unresponsive.
|
||||
|
||||
Please check the [How to enter link](../faq.html#submit) link
|
||||
Please check the [How to enter FAQ](../faq.html#submit)
|
||||
for **important information** on how to submit to the IOCCC.
|
||||
|
||||
**`|`** The submit URL should be active on or slightly before **2020-Jan-15 12:21:37 UTC**.
|
||||
Please wait to submit your entries until after that time.
|
||||
|
||||
The official rules, guidelines will be available on the [official IOCCC
|
||||
website](../index.html) on or slightly before start of this IOCCC. The
|
||||
`mkiocccentry` toolkit may be obtained at any time at the
|
||||
[mkiocccentry toolkit repo](https://github.com/ioccc-src/mkiocccentry).
|
||||
The official [rules](rules.html) and [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).
|
||||
|
||||
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
|
||||
@@ -126,19 +127,19 @@ The size of your program source **MUST BE <= 4096 bytes**in length.
|
||||
## Rule 2b
|
||||
|
||||
**`|`** When your program source is fed as input to the current IOCCC size
|
||||
tool, and the IOCCC size tool -i command line option is used, the
|
||||
tool, and the IOCCC size tool `-i` command line option is used, the
|
||||
value printed **shall not exceed 2503**.
|
||||
|
||||
**`|`** The source to the current IOCCC size tool is found in the
|
||||
[mkiocccentry tool repo](https://github.com/ioccc-src/mkiocccentry). If you use
|
||||
the `mkiocccentry` tool (which we **STRONGLY recommend you do**) will invoke
|
||||
the `mkiocccentry` tool (which we **STRONGLY recommend you do**) it will invoke
|
||||
this tool before packaging your entry for submission.
|
||||
|
||||
|
||||
## Rule 3
|
||||
|
||||
Submissions should be performed using the instructions outlined at:
|
||||
the [How to enter link](../faq.html#submit) link.
|
||||
the [How to enter FAQ](../faq.html#submit).
|
||||
|
||||
To submit to an open IOCCC, you must use the [IOCCC submit server](https://submit.ioccc.org/).
|
||||
|
||||
@@ -171,10 +172,10 @@ file to a new filename and then modify that copy.
|
||||
|
||||
## Rule 6
|
||||
|
||||
**`|`** I am not a rule, I am a `free(void \*human)`!
|
||||
**`|`** I am not a rule, I am a `free(void *human)`!
|
||||
|
||||
``` <!---c-->
|
||||
| while (!understand(ioccc(rule(that(you(are(number(6)))))))) { ha_ha_ha(); }
|
||||
while (!understand(ioccc(rule(that(you(are(number(6)))))))) { ha_ha_ha(); }
|
||||
```
|
||||
|
||||
|
||||
@@ -191,8 +192,8 @@ under the following license:
|
||||
See also Rule 18.
|
||||
|
||||
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.
|
||||
detail that ownership (i.e., who owns what) **AND document the
|
||||
permission you obtained**.
|
||||
|
||||
Please note that the IOCCC size tool is **NOT** an original work.
|
||||
|
||||
@@ -200,7 +201,7 @@ Please note that the IOCCC size tool is **NOT** an original work.
|
||||
## Rule 8
|
||||
|
||||
**`|`** Entries must be received prior to the end of this IOCCC which is
|
||||
**2024-MMM-DD HH:MM:SS UTC**. ** XXX - This date and time is TDB - XXX **.
|
||||
**2024-MMM-DD HH:MM:SS UTC**. **XXX - This date and time is TDB - XXX **.
|
||||
|
||||
|
||||
A confirmation of submission will be sent to the submitting email address
|
||||
@@ -209,7 +210,7 @@ before the close of the contest.
|
||||
|
||||
## Rule 9
|
||||
|
||||
**`|`** Each person may submit up to and including 8.000000 entries per contest.
|
||||
**`|`** Each person may submit up to and including 10.000000 entries per contest.
|
||||
|
||||
Each entry must be submitted separately.
|
||||
|
||||
@@ -224,8 +225,8 @@ Entries requiring human interaction to be initially compiled are not permitted.
|
||||
Programs that require special privileges (`setuid(2)`, `setgid(2)`, super-user,
|
||||
special owner, special group, etc.) are still highly discouraged. We
|
||||
do not guarantee these functions will behave as you expect on our test
|
||||
platforms. If your program needs special permissions **please** document
|
||||
them in the remarks file.
|
||||
platforms. If your program needs special permissions **please document
|
||||
them** in the remarks file.
|
||||
|
||||
|
||||
## Rule 12
|
||||
@@ -277,7 +278,7 @@ See also [How may I submit to the IOCCC?](../faq.html#submit) in the
|
||||
|
||||
## Rule 16
|
||||
|
||||
You are **STRONGLY** encouraged to submit a previously unpublished and
|
||||
You are **STRONGLY** encouraged to submit a previously unpublished _AND_
|
||||
original entry. Submissions that are similar to previous entries are
|
||||
discouraged. As we judge anonymously, submissions that have already
|
||||
been published may be disqualified.
|
||||
@@ -292,8 +293,9 @@ 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.
|
||||
|
||||
**`|`** 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.
|
||||
|
||||
**`|`** 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.
|
||||
|
||||
## Rule 18
|
||||
|
||||
@@ -302,7 +304,7 @@ The entirety of your entry 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/)**
|
||||
|
||||
You (the author(s)) **MUST** own the contents of your submission **OR**
|
||||
you **MUST** have permission from the owner(s) to submit their content.
|
||||
you **MUST HAVE PERMISSION** from the owner(s) to submit their content.
|
||||
|
||||
You must not submit anything that cannot be submitted under that license.
|
||||
|
||||
@@ -318,9 +320,9 @@ for more information.
|
||||
|
||||
## Rule 20
|
||||
|
||||
The how to build instructions must be in Makefile format. See [What kind of
|
||||
make(1) compatibility does the IOCCC support and will it support other
|
||||
kinds?](../faq.html#make_compatibility) for more details on what we support.
|
||||
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.
|
||||
|
||||
The target of the Makefile must be called `prog`. The original
|
||||
C source file must be called `prog.c`.
|
||||
@@ -351,7 +353,7 @@ detect if required rules exist in your Makefile.
|
||||
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
|
||||
**MAY** create subdirectories below the current directory, or in `/tmp`,
|
||||
or in `/var/tmp` provided that "**.**" is **NOT** the first octet in any
|
||||
or in `/var/tmp` provided that `.` is **NOT** the first octet in any
|
||||
directory name or filename you submit.
|
||||
|
||||
|
||||
@@ -370,7 +372,7 @@ 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.
|
||||
|
||||
Yes, Virginia, **we REALLY mean it**!
|
||||
Yes, Virginia, **WE REALLY MEAN IT!**
|
||||
|
||||
|
||||
## Rule 23
|
||||
@@ -402,13 +404,19 @@ Rule 26 is also a rule.
|
||||
|
||||
**`|`** For questions or comments about the contest, see [Contacting the IOCCC](../contact.html).
|
||||
|
||||
**`|`** Be sure to review the [IOCCC Rules and Guidelines](index.html) as rules and the guidelines may (and often do) change from year to year.
|
||||
**`|`** Be sure to review the [IOCCC Rules and Guidelines](index.html) as
|
||||
[rules](rules.html) and the [guidelines](guidelines.html) may (and often do) change from year to year.
|
||||
|
||||
**`|`** You should be sure you have the current rules and guidelines prior to submitting entries.
|
||||
**`|`** You should be sure you have the current [rules](rules.html) and
|
||||
[guidelines](guidelines.html) prior to submitting entries.
|
||||
|
||||
**`|`** See the [Official IOCCC website news](../news.html) for additional information.
|
||||
|
||||
**`|`** For the updates and breaking IOCCC news, you are encouraged to follow the [IOCCC on Mastodon](https://fosstodon.org/@ioccc) account. See our [FAQ](../faq.html#try_mastodon) for more information.
|
||||
**`|`** For the updates and breaking IOCCC news, you are encouraged to follow
|
||||
the [IOCCC on Mastodon](https://fosstodon.org/@ioccc) account. See our
|
||||
[FAQ](../faq.html#try_mastodon) for more information. Please do note that unless
|
||||
you are mentioned by us you will **NOT** get a notification from the app so you
|
||||
should refresh the page even if you do follow us.
|
||||
|
||||
**`|`** Check out the [Official IOCCC winner web site](https://www.ioccc.org/index.html) in general.
|
||||
|
||||
|
||||
Reference in new issue
Block a user