This HTML is now obsolete in HTML 5: ```html <a name="faq0"></a>Section 0: Submitting entries to a new IOCCC ``` Instead we need to use the div HTML elements: ```html <div id="faq0">Section 0: Submitting entries to a new IOCCC</div> ``` We are testing a fix for the top level HTML files. Run `make gen_top_html` to perform the above and test under macOS. TODO: Apply this type of fix across the entire web site if all is well.
975 lines
57 KiB
HTML
975 lines
57 KiB
HTML
<!DOCTYPE html>
|
||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||
<!-- START: two lines up starts content from: inc/top.default.html -->
|
||
|
||
<!-- END: this line ends content from: inc/top.default.html -->
|
||
<!-- START: this line starts content from: inc/head.default.html -->
|
||
|
||
<head>
|
||
<link rel="stylesheet" href="../ioccc.css">
|
||
<meta charset="utf-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
|
||
<title>The International Obfuscated C Code Contest</title>
|
||
<link rel="icon" type="image/x-icon" href="../favicon.ico">
|
||
<meta name="description" content="IOCCC Guidelines">
|
||
<meta name="keywords" content="IOCCC, guidelines, Guidelines">
|
||
</head>
|
||
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
|
||
<!-- END: this line ends content from: inc/head.default.html -->
|
||
|
||
<!-- -->
|
||
<!-- This web page was formed via the tool: bin/gen-top-html.sh -->
|
||
<!-- The content of main section of this web page came from: next/guidelines.md -->
|
||
<!-- -->
|
||
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: next/guidelines.md !!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: next/guidelines.md !!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: next/guidelines.md !!! -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
|
||
<!-- Markdown content was converted into HTML via the tool: bin/md2html.sh -->
|
||
|
||
<!-- START: this line starts content from: inc/body.default.html -->
|
||
|
||
<body>
|
||
|
||
<!-- END: this line ends content from: inc/body.default.html -->
|
||
<!-- START: this line starts content from: inc/header.default.html -->
|
||
|
||
<div class="header">
|
||
<img src="../png/ioccc.png" alt="IOCCC image by Matt Zucker" width=300 height=110>
|
||
<h1>The International Obfuscated C Code Contest</h1>
|
||
<h2>IOCCC Guidelines</h2>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/header.default.html -->
|
||
<!-- START: this line starts content from: inc/topnav.default.html -->
|
||
|
||
<div class="topnav">
|
||
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/topnav.default.html -->
|
||
<!-- START: this line starts content from: inc/begin-row.default.html -->
|
||
|
||
<div class="row">
|
||
|
||
<!-- END: this line ends content from: inc/begin-row.default.html -->
|
||
<!-- START: this line starts content from: inc/begin-leftcolumn.default.html -->
|
||
|
||
<div class="leftcolumn">
|
||
|
||
<!-- END: this line ends content from: inc/begin-leftcolumn.default.html -->
|
||
<!-- START: this line starts content from: inc/sidenav.default.html -->
|
||
|
||
<div class="sidenav">
|
||
<a href="#content">Jump to contents</a>
|
||
</div>
|
||
<hr>
|
||
<div class="sidenav">
|
||
<a href="../index.html">IOCCC Home</a>
|
||
<a href="../years.html">Winning Entries</a>
|
||
<a href="../authors.html">People who have won</a>
|
||
<a href="../location.html">Location of authors</a>
|
||
</div>
|
||
<hr>
|
||
<div class="sidenav">
|
||
<a href="../news.html">IOCCC News</a>
|
||
<a href="../status.html">Contest status</a>
|
||
<a href="../next/index.html">Rules and Guidelines</a>
|
||
<a href="../faq.html#submit">How to enter the IOCCC</a>
|
||
<a href="../faq.html">FAQ</a>
|
||
</div>
|
||
<hr>
|
||
<div class="sidenav">
|
||
<a href="../bugs.html">Bugs & (mis)features</a>
|
||
<a href="../faq.html#fix_an_entry">Fixing IOCCC entries</a>
|
||
<a href="../faq.html#fix_web_site">Fixing the web site</a>
|
||
<a href="../faq.html#fix_author">Fixing author info</a>
|
||
<a href="../thanks-for-help.html">Thanks for the help</a>
|
||
</div>
|
||
<hr>
|
||
<div class="sidenav">
|
||
<a href="../judges.html">The IOCCC Judges</a>
|
||
<a href="../contact.html">Contacting the IOCCC</a>
|
||
</div>
|
||
<hr>
|
||
<div class="sidenav">
|
||
<a href="#top">Jump to top</a>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/sidenav.default.html -->
|
||
<!-- START: this line starts content from: inc/end-leftcolumn.default.html -->
|
||
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/end-leftcolumn.default.html -->
|
||
<!-- START: this line starts content from: inc/begin-rightcolumn.default.html -->
|
||
|
||
<div class="rightcolumn">
|
||
|
||
<!-- END: this line ends content from: inc/begin-rightcolumn.default.html -->
|
||
<!-- START: this line starts content from: inc/before-content.default.html -->
|
||
|
||
<div id="content">
|
||
|
||
<!-- END: this line ends content from: inc/before-content.default.html -->
|
||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||
|
||
<!-- 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>They 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>
|
||
<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 entires that have won the IOCCC.</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>
|
||
<!-- 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">27th International Obfuscated C Code Contest Official Guidelines</h1>
|
||
<p>Copyright © 2024 Leonid A. Broukhis, 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
|
||
writing from the contest judges.</p>
|
||
<h2 id="guidelines-version">Guidelines version</h2>
|
||
<p><strong><code>|</code></strong> This guidelines file is version <strong>2023-04-04-v28</strong>.</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 start the <strong><code>|</code></strong> symbol.</p>
|
||
<h1 id="about-this-file">ABOUT THIS FILE:</h1>
|
||
<p>This file contains guidelines intended to help people who wish to
|
||
submit entries to the International Obfuscated C Code Contest (IOCCC).</p>
|
||
<p>This is 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.</p>
|
||
<p>You should read the current IOCCC rules, prior to submitting entries.
|
||
The rules are typically sent out with these guidelines.</p>
|
||
<h1 id="whats-new-in-20192020">WHAT’S NEW IN 2019/2020</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><strong><code>|</code></strong> The reason for the times of day are so that key IOCCC events occur during UTC
|
||
<strong><code>|</code></strong> “prime time”. Do you understand why we factored this into the rules and
|
||
<strong><code>|</code></strong> guidelines? :-)</p>
|
||
<p>Until the start of this IOCCC, these rules, guidelines and iocccsize.c tool
|
||
should be considered provisional BETA versions and may be adjusted
|
||
at any time.</p>
|
||
<p><strong><code>|</code></strong> Even though the contest will start in 2019, because the contest will close
|
||
<strong><code>|</code></strong> in 2020, URLs, subject lines, and contest related email addresses use 2019.</p>
|
||
<p>The IOCCC submission URL:</p>
|
||
<pre><code> https://submit.ioccc.org/</code></pre>
|
||
<p><strong><code>|</code></strong> The submit URL should be active on or slightly before <strong>2020-Jan-15 12:21:37 UTC</strong>.</p>
|
||
<p>Please wait to submit your entries until after that time.</p>
|
||
<p>The official rules, guidelines and iocccsize.c tool will be available
|
||
on the official IOCCC web site on or slightly before start of this IOCCC.
|
||
Please check the IOCCC web site “How to enter” link:</p>
|
||
<pre><code> https://www.ioccc.org/index.html#enter</code></pre>
|
||
<p>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>
|
||
<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>run it through a C beautifier</li>
|
||
<li>examine the algorithm</li>
|
||
<li>compile it (with flags to enable all warnings)</li>
|
||
<li>execute it</li>
|
||
</ul>
|
||
<p>You should consider how your entry looks in each of the above tests.
|
||
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
|
||
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
|
||
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>
|
||
<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. Even so, we will attempt to use
|
||
<strong><code>|</code></strong> 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
|
||
16 is a prime number. If you do have a bug, you are better off
|
||
documenting it. Noting “this entry sometimes prints the 4th power
|
||
of a prime by mistake” would save the above entry. And sometimes,
|
||
a strange bug/feature can even help the entry! Of course, a correctly
|
||
working entry is best. Clever people will note that 16 might be prime
|
||
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>
|
||
<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
|
||
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 an IOCCC size tool.
|
||
<strong><code>|</code></strong> The source for this tool is found at:</p>
|
||
<pre><code>| https://www.ioccc.org/2020/iocccsize.c</code></pre>
|
||
<p>To further clarify rule 2, we subdivided it into two parts, 2a and 2b.
|
||
<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>
|
||
<p>The IOCCC size tool should be compiled as:</p>
|
||
<pre><code> cc -pedantic -Wall -Wextra -std=c11 iocccsize.c -o iocccsize</code></pre>
|
||
<p>This tool imposes a 2nd limit on C code size (rule 2b). To check your
|
||
code against the 2nd limit of rule 2, use the -i command line option.
|
||
For example:</p>
|
||
<pre><code> ./iocccsize -i < prog.c</code></pre>
|
||
<p>The IOCCC size tool, when using the -i option, may be summarized as:</p>
|
||
<pre><code> The size tool counts most C reserved words (keyword, secondary,
|
||
and selected preprocessor keywords) as 1. The size tool counts all
|
||
other octets as 1 excluding ASCII whitespace, and excluding any
|
||
';', '{' or '}' followed by ASCII whitespace, and excluding any
|
||
';', '{' or '}' octet immediately before the end of file.</code></pre>
|
||
<p>ASCII whitespace includes ASCII tab, ASCII space, ASCII newline,
|
||
ASCII formfeed, and ASCII carriage return.</p>
|
||
<p><strong><code>|</code></strong> When ‘;’, ‘{’ or ‘}’ are within a C string, they may still not be
|
||
<strong><code>|</code></strong> counted by the IOCCC size tool. This is a feature, not a bug!</p>
|
||
<p>In cases where the above summary and the algorithm implemented by
|
||
the IOCCC size tool source code conflict, the algorithm implemented
|
||
by the IOCCC size tool source code is preferred by the judges.</p>
|
||
<p>There are at least 2 other reasons for selecting 2053 as the 2nd limit
|
||
besides the fact that 2053 is the next prime > 2048. These reasons
|
||
may be searched for and discovered if you are “Curios!” about 2053. :-)
|
||
Moreover, 2053 was the number of the kernel disk pack of one of the
|
||
judge’s BESM-6.</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
|
||
to get around the size limits of rule 2.</p>
|
||
<p>Yes Virginia, <strong>that is a hint</strong>!</p>
|
||
<p><strong><code>|</code></strong> We applaud programs that do not issue warnings when compiled.
|
||
<strong><code>|</code></strong> To avoid warnings, you might be tempted to add various -Wno-foobar
|
||
<strong><code>|</code></strong> flags. Unfortunately such flags are NOT portable. Moreover,
|
||
<strong><code>|</code></strong> such flags are not consistent between different C compilers.
|
||
<strong><code>|</code></strong> Therefore we recommend that you consider one of several approaches:</p>
|
||
<ol type="a">
|
||
<li><strong><code>|</code></strong> Write code that does not generate compiler warnings</li>
|
||
<li><strong><code>|</code></strong> Do not use flags that disable compiler warnings</li>
|
||
<li><strong><code>|</code></strong> Provide instructions (such as in your Makefile) that
|
||
<strong><code>|</code></strong> uses appropriate disable compiler warnings flags for
|
||
<strong><code>|</code></strong> both clang and gcc</li>
|
||
<li><strong><code>|</code></strong> 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
|
||
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
|
||
#d foo /* <-- don't expect this to turn into #define foo */</code></pre>
|
||
<p>When declaring local or global variables, you should declare the type:</p>
|
||
<pre><code> int this_is_fine;
|
||
this_is_not; /* <-- Try to avoid implicit type declarations */</code></pre>
|
||
<p>We suggest that you compile your entry with a commonly available
|
||
c11 (formerly C1X) C compiler (ISO/IEC 9899:2011).</p>
|
||
<p>Do not assume that optional c11 features are supported. If you
|
||
must use an optional c11 feature, use feature test macros so
|
||
that implementations without such optional c11 features will see
|
||
an entry that is both functional and interesting.</p>
|
||
<p>We like entries that have workarounds that allow someone with
|
||
an older c99 (ISO/IEC 9899:1999) compiler to be able to compile
|
||
and enjoy your entry.</p>
|
||
<p>We really like “lint free” code. However lint is a toll of the past.
|
||
So try to ensure that your entry compiles warning free. If possible,
|
||
to compile compile your code using:</p>
|
||
<pre><code> -Wall -Wextra -pedantic</code></pre>
|
||
<p>For compilers, such as clang, that have the -Weverything option, try
|
||
to make your code compile warning free using:</p>
|
||
<pre><code> -Wall -Wextra -Weverything -pedantic</code></pre>
|
||
<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
|
||
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
|
||
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
|
||
of the c11 reserved words in their intended C language contexts?
|
||
NOTE: As with the use of the word Belgium, the use of certain gratuitous
|
||
c11 reserved words may be completely banned in all parts of the Galaxy,
|
||
except in one small part (ISO/IEC 9899:2011) where they might not truly
|
||
understand the implications of such words.</p>
|
||
<pre><code> http://hitchhikers.wikia.com/wiki/Belgium
|
||
http://www.bezem.de/pdf/ReservedWordsInC.pdf</code></pre>
|
||
<p>DO NOT assume that we will use gcc to compile your program.
|
||
We will first try to compile your program using Clang.</p>
|
||
<p>It is much better to not use any obscure compiler flags if
|
||
you can help it. We want to discourage the use of obscure compiler
|
||
flags that would make the program less portable.</p>
|
||
<p>One side effect of the above is that you cannot assume the use
|
||
of nested functions such as:</p>
|
||
<pre><code> main() {
|
||
| void please_do_not_submit_this() {
|
||
| printf("The machine that goes BING!\n");
|
||
}
|
||
| please_do_not_submit_this();
|
||
}</code></pre>
|
||
<p>This is because such nested functions often requires one to compile with
|
||
a flag such as -fnested-functions that is not found on some compilers.</p>
|
||
<p>On 2012 July 20, the judges rescinded the encouragement of
|
||
nested functions. Such constructions, while interesting and sometimes
|
||
amusing, will have to wait until they required by a C standard that are
|
||
actually implemented in commonly used C compilers. Sorry!</p>
|
||
<p><strong><code>|</code></strong> We prefer programs that do not require a fish license: crayons and
|
||
<strong><code>|</code></strong> cat detector vans not withstanding.</p>
|
||
<p>If your entry uses functions that have a variable number of
|
||
arguments, be careful. Systems implement va_list as a wide variety
|
||
of ways. Because of this, a number of operations using va_list are
|
||
not portable and must not be used:</p>
|
||
<ul>
|
||
<li>assigning a non-va_list variable to/from a va_list variable</li>
|
||
<li>casting a non-va_list variable into/from a va_list variable</li>
|
||
<li>passing a va_list variable to a function expecting a non-va_list arg</li>
|
||
<li>passing a non-va_list variable to a function expecting a va_list arg</li>
|
||
<li>performing arithmetic on va_list variables</li>
|
||
<li>using va_list as a structure or union</li>
|
||
</ul>
|
||
<p>In particular, do not treat va_list variables as if they were a char **’s.</p>
|
||
<p>Avoid using <varargs.h>. Use <stdarg.h> instead.</p>
|
||
<p>On 28 January 2007, the Judges rescinded the requirement that the
|
||
’#” in a C preprocessor directive must be the 1st non-whitespace octet.</p>
|
||
<p>The exit() function returns void. Some broken systems have exit()
|
||
return int, your entry should assume that exit() returns a void.</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.
|
||
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
|
||
explain to the Walrus why our seas are boiling hot, the question of
|
||
whether pigs have wings is likely to remain a debatable point to most.</p>
|
||
<p>One line programs should be short one line programs: say around 80 to 120
|
||
octets long. Going well beyond 140 octets is a bit too long to be called
|
||
a one-liner in our vague opinion.</p>
|
||
<p>We tend to dislike programs that:</p>
|
||
<ul>
|
||
<li>are very hardware specific</li>
|
||
<li>are very OS version specific
|
||
(index/strchr differences are OK, but socket/streams specific
|
||
code is likely not to be)</li>
|
||
<li>dump core or have compiler warnings
|
||
(it is OK only if you warn us in the ‘remark’ header item)</li>
|
||
<li>won’t compile or run under a POSIX P1003.1/P1003.2 like systems</li>
|
||
<li>depend on a utility or application not normally found on most
|
||
most POSIX P1003.1/P1003.2 like systems</li>
|
||
<li>abuse the build file to get around the size limit</li>
|
||
<li>obfuscate by excessive use of ANSI trigraphs</li>
|
||
<li>are longer than they need to be</li>
|
||
<li>are “blob-ier” than they need to be</li>
|
||
<li>are rather similar to previous winners :-(</li>
|
||
<li>are too similar to previous losers :-)</li>
|
||
<li><strong><code>|</code></strong> that mandate the exclusive the use of an specific Integrated</li>
|
||
<li><strong><code>|</code></strong> Development Environment (IDE)</li>
|
||
</ul>
|
||
<p><strong><code>|</code></strong> In order to encourage entry portability, we dislike entries that
|
||
<strong><code>|</code></strong> fail to build unless one is using an IDE. For example, do not
|
||
<strong><code>|</code></strong> mandate that one must use Microsoft Visual Studio to compile
|
||
<strong><code>|</code></strong> your entry. Nevertheless some of the better IDEs have command-line
|
||
<strong><code>|</code></strong> interfaces to their compilers, once one learns how to invoke a shell.</p>
|
||
<p><strong><code>|</code></strong> The program must compile and link cleanly in a POSIX-like environment.
|
||
<strong><code>|</code></strong> Therefore do not assume the system has a windows.h 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
|
||
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
|
||
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
|
||
<strong><code>|</code></strong> 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><strong><code>|</code></strong> Your source code, post-pre-processing, should not exceed the size
|
||
<strong><code>|</code></strong> of Windows. :-)</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>
|
||
<p>You should try to restrict commands used on the build file to
|
||
POSIX-like or common Unix-like commands. You can also compile
|
||
and use your own programs. If you do, try to build and execute
|
||
from the current directory. This restriction is not a hard and
|
||
absolute one. The intent is to ensure that the building if your
|
||
program is reasonably portable.</p>
|
||
<p>We prefer programs that are portable across a wide variety of Unix-like
|
||
operating systems (i.e., Linux, GNU Hurd, BSD, Unix, etc.).</p>
|
||
<p>You are in a maze of twisty guidelines, all different.</p>
|
||
<p>There are at least zero judges who think that Fideism has little
|
||
or nothing to do with the IOCCC judging process.</p>
|
||
<p>Don’t forget that the building of your program should be done
|
||
<strong><em>without human intervention</em></strong>. So don’t do things such as:</p>
|
||
<pre><code> prog: prog.c
|
||
#echo this next line requires data from standard input
|
||
cat > prog.c
|
||
${CC} prog.c -o prog</code></pre>
|
||
<p>However, you can do something cute such as making your program
|
||
do something dumb (or cute) when it is built ‘automatically’. And
|
||
when it is run with a human involved, do something more clever.
|
||
For example, one could use the build instructions:</p>
|
||
<pre><code> prog: prog.c
|
||
${CC} prog.c -DNON_HUMAN_COMPILE -o prog
|
||
@echo "See remarks section about alternate ways to compile"</code></pre>
|
||
<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>
|
||
<p>Please do not use things like gzip 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
|
||
large data files to get around the source code size limit.</p>
|
||
<p>We do not recommend submitting systemd source code to the IOCCC,
|
||
if nothing else because that code is likely to exceed the source code
|
||
size limit. This isn’t to say that another highly compact and obfuscated
|
||
replacement of init would not be an interesting submission.</p>
|
||
<p>Did we remember to indicate that programs that blatantly use
|
||
some complex state machine to do something simple are boring?
|
||
We think we did. :-)</p>
|
||
<p>All generalizations are false, including this one. – Mark Twain</p>
|
||
<p>Given two versions of the same program, one that is a compact blob
|
||
of code, and the other that is formatted more like a typical C
|
||
program, we tend to favor the second version. Of course, a third
|
||
version of the same program that is formatted in an interesting
|
||
and/or obfuscated way, would definitely win over the first two!
|
||
Remember, you can submit more than one entry. See the rules for details.</p>
|
||
<p>We suggest that you avoid trying for the ‘smallest self-replicating’
|
||
source. The smallest, a zero byte entry, won in 1994.</p>
|
||
<p>Programs that claim to be the smallest C source that does something, really
|
||
better be the smallest such program or they risk being rejected because
|
||
they do not work as documented.</p>
|
||
<p>Please note that the C source below, besides lacking in obfuscation,
|
||
is NOT the smallest C source file that when compiled and run, dumps core:</p>
|
||
<pre><code> main;</code></pre>
|
||
<p>We do not like writable strings. That is, we don’t want stuff like:</p>
|
||
<pre><code> char *T = "So many primes, so little time!";
|
||
...
|
||
T[14] = ';';</code></pre>
|
||
<p>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:</p>
|
||
<pre><code> char b[] = "Is this OK";
|
||
b[9] = 'K';</code></pre>
|
||
<p><strong><code>|</code></strong> There are more than one typos in this very sentence.</p>
|
||
<p>X client entries should be as portable as possible. Entries that
|
||
adapt to a wide collection of environments will be favored. For
|
||
example, don’t depend on a particular type or size of display.
|
||
Don’t assume the use of a particular browser. Instead assume a
|
||
generic browser that forms to a widely used W3C standard.
|
||
Don’t assume a particular sound sub-system or video driver is installed
|
||
in the OS. Instead, make use of a well known and widely available open
|
||
source program (one that actually works) to display audio/visual data.</p>
|
||
<p>X client entries should avoid using X related libraries and
|
||
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 fizzbin? 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
|
||
open source toolkit that is widely and freely available instead.</p>
|
||
<p><strong>NOTE</strong>: <strong><code>|</code></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
|
||
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
|
||
Happy Birthday song; music that some people believe is copyrighted
|
||
(even if such copyrights appear to be bogus and/or blatant abuses of
|
||
the copyright system).</p>
|
||
<p>While we recognize that UNIX is not a universal operating system, the
|
||
contest does have a bias towards such systems. In an effort to expand
|
||
the scope of the contest, we phrase our bias in terms of POSIX P1003.1
|
||
and P1003.2 standards. This will allow certain non-UNIX OS users to
|
||
submit entries. On the other hand, this is a guideline and not a rule.
|
||
We will not reject an entry based on some POSIX technicality.</p>
|
||
<p>When dealing with OS and application environments, we suggest that you
|
||
be reasonable with a nod towards vanilla UNIX-like systems. POSIX will
|
||
evolve but not as much as the contest.</p>
|
||
<p>You very well might not be completely prohibited from failing to not
|
||
partly misunderstand this particular guideline, but of course we could
|
||
<strong><code>|</code></strong> not possibly comment. Nevertheless, you are neither prohibited, nor are
|
||
<strong><code>|</code></strong> you required to determine that this or the previous sentence is either false
|
||
<strong><code>|</code></strong> and/or misleading. Therefore, it might be wise for you to not fail to consider
|
||
<strong><code>|</code></strong> to do so, accordingly. Thank you.</p>
|
||
<p>Any complaints about the above guideline could be addressed to the
|
||
Speaker of the House of Commons, or to the speaker of your national
|
||
<strong><code>|</code></strong> parliament should you have one.</p>
|
||
<p>We like programs that:</p>
|
||
<ul>
|
||
<li>are as concise and small as they need to be</li>
|
||
<li>do something at least quasi-interesting</li>
|
||
<li>are portable</li>
|
||
<li>are unique or novel in their obfuscation style</li>
|
||
<li>MAKE USE OF A NUMBER OF DIFFERENT TYPES OF OBFUSCATION <== HINT!!</li>
|
||
<li>make us laugh and/or throw up :-) (humor really helps!)</li>
|
||
<li>make us want to eat good chocolate.</li>
|
||
</ul>
|
||
<p>Some types of programs can’t excel (anti-tm) in some areas. Your
|
||
program doesn’t have to excel in all areas, but doing well in several
|
||
areas really does help.</p>
|
||
<p>You are better off explaining what your entry does in the program
|
||
“remarks” section rather than leaving it obscure for the judges
|
||
as we might miss something and/or be too tired to notice.</p>
|
||
<p><strong><code>|</code></strong> Please avoid this specific individual guideline, if at all possible.</p>
|
||
<p>We freely admit that interesting, creative or humorous comments in
|
||
the program “remarks” help your chances of winning. If you had to
|
||
read so many twisted entries, you too would enjoy a good laugh or two.
|
||
We think the readers of the contest winners do as well. We do read
|
||
the program “remarks” during the judging process, so it is worth your
|
||
while to write remarkable program “remarks”.</p>
|
||
<p>We dislike C code with trailing control-M’s (r \015) that results
|
||
in compilation failures. Some non-Unix/non-Linux tools such as
|
||
MS Visual C and MS Visual C++ leave trailing control-M’s on lines.
|
||
Users of such tools should strip off such control-M’s before submitting
|
||
their entries. In some cases tools have a “Save As” option that will
|
||
prevent such trailing control-M’s being added.</p>
|
||
<p>One should restrict libcurses to portable features found on BSD
|
||
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 */
|
||
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");
|
||
else printf("This code should not print this message\n");</code></pre>
|
||
<p>It is a very good idea to, in your remarks file, tell us why you
|
||
think your entry is obfuscated. This is particularly true if
|
||
your entry is has some very subtle obfuscations that we might
|
||
otherwise overlook. <<– Hint!</p>
|
||
<p>Anyone can format their code into a dense blob. A really clever
|
||
author will try format their entry using a “normal” formatting style
|
||
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
|
||
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>
|
||
<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>
|
||
<pre><code> Get your facts first, then you can distort them as you please.</code></pre>
|
||
<p>is a good guideline for those writing code for the IOCCC.</p>
|
||
<p>The IOCCC size tool source, iocccsize.c, is not an original work,
|
||
<strong><code>|</code></strong> unless you are Anthony C Howe, in which case it is original!
|
||
<strong><code>|</code></strong> Submitting source that uses the content iocccsize.c, unless you are
|
||
<strong><code>|</code></strong> 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
|
||
interesting than simply implementing the IOCCC size tool algorithm.</p>
|
||
<p>While programs that only run in a specific word size are OK. If you have
|
||
to pick, choose a 64-bit word size.</p>
|
||
<p>If we are feeling ornery we might choose to compile your program
|
||
for running on an Arduino or a PDP-11. Heck, should we ever find
|
||
an emulator of 60-bit CDC Cyber CPU running a POSIX-like OS, we
|
||
might just try your entry on that emulator as well :-)</p>
|
||
<p>If your entry MUST run only in 32-bit mode on an Intel processor, add the
|
||
following compiler flag:</p>
|
||
<pre><code> -arch i386</code></pre>
|
||
<p>to your “how to build” make compile line. For example:</p>
|
||
<pre><code> prog: prog.c
|
||
${CC} prog.c -arch i386 -o prog</code></pre>
|
||
<p>Be even more creative!</p>
|
||
<p>If there are limitations in your entry, you are highly encouraged
|
||
to note such limitations in your remarks file. For example if your
|
||
entry factors values up to a certain size, you might want to state:</p>
|
||
<pre><code> This entry factors values up 2305567963945518424753102147331756070.
|
||
Attempting to factor larger values will produce unpredictable results.</code></pre>
|
||
<p>The judges might try to factor the value -5, so you want to might state:</p>
|
||
<pre><code> This entry factors positive values up 2305567963945518424753102147331756070.
|
||
Attempting to factor large values will produce unpredictable results.</code></pre>
|
||
<p>However the judges might try to also factor 0, so you want to might state:</p>
|
||
<pre><code> This entry factors values between 1 and 2305567963945518424753102147331756070.
|
||
Attempting to factor values outside that range will produce unpredictable results.</code></pre>
|
||
<p>Moreover the try to also factor 3.5 or 0x7, or Fred, so you want to might state:</p>
|
||
<pre><code> This entry factors integers between 1 and 2305567963945518424753102147331756070.
|
||
Attempting to factor anything else will produce unpredictable results.</code></pre>
|
||
<p>You entry might be better off catching the attempt to factor bogus values
|
||
and doing something interesting. So you might want to code accordingly and state:</p>
|
||
<pre><code> This entry factors integers between 1 and 2305567963945518424753102147331756070.
|
||
Attempting to factor anything else will cause the program to insult your
|
||
pet fish Eric.</code></pre>
|
||
<p>The judges might not have a pet fish named Eric, so might want to state:</p>
|
||
<pre><code> This entry factors integers between 1 and 2305567963945518424753102147331756070.
|
||
Attempting to factor anything else will cause the program to insult your
|
||
pet fish Eric, or in the case that you lack such a pet, will insult the
|
||
pet that you do not have.</code></pre>
|
||
<p>When all other things are equal, an entry with fewer limitation will be judged
|
||
better than an entry with lots of limitations. So you might want to code accordingly
|
||
and state:</p>
|
||
<pre><code> This entry attempts to a factor value of any size provided that the program
|
||
is 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 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
|
||
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
|
||
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>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
|
||
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
|
||
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>
|
||
<h1 id="judging-process">JUDGING PROCESS:</h1>
|
||
<p>Entries are judged by Leonid A. Broukhis, Simon Cooper, Landon Curt Noll.</p>
|
||
<p>Each entry submitted is given a random id number and subdirectory. The
|
||
entry files including, but not limited to prog.c, Makefile (that we
|
||
form from around your “how to build” information), as well as any
|
||
data files that you submit are all placed under their own directory.
|
||
stored and judged from this directory.</p>
|
||
<p>Any information about the authors is not read by the judges until
|
||
the judging process is complete, and then only from entries that have
|
||
won an award. Because we do not read this information for entries that
|
||
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
|
||
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
|
||
(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.</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 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
|
||
source code, remarks, data files, etc. The above “Peter Honeyman is
|
||
exempt” not withstanding.</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,
|
||
who won and where they were from.</p>
|
||
<p>We attempt to keep all entries anonymous, unless they win an award.
|
||
Because the main ‘prize’ of winning is being announced, we make all
|
||
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>
|
||
<p>Once we have selected the winners, for each category we will tweet:</p>
|
||
<ul>
|
||
<li>category name</li>
|
||
<li>name(s) of the authors (or anonymous if requested)</li>
|
||
<li>twitter handle(s) (if provided and if anonymity was not requested)</li>
|
||
<li>country code(s) of the author(s)</li>
|
||
</ul>
|
||
<p>After the initial announcement, we attempt to send email to the
|
||
authors of the winning entries. One reason we do this is to give
|
||
the authors a chance to comment on the way we have presented their
|
||
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-2023-update-to-how-winners-are-announced">An important 2023 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 IOCCC entries repo:</p>
|
||
<pre><code> https://github.com/ioccc-src/winner</code></pre>
|
||
<p>that, in turn, updates the offivial IOCCC web site:</p>
|
||
<pre><code> https://www.ioccc.org/index.html</code></pre>
|
||
<p>In addition a note is posted to the IOCCC Mastodon account:</p>
|
||
<pre><code> https://fosstodon.org/@ioccc</code></pre>
|
||
<h2 id="back-to-the-judging-process">Back to the Judging process</h2>
|
||
<p>Judging consists of a number of elimination rounds. During a round,
|
||
the collection of entries are divided into two roughly equal piles;
|
||
the pile that advances on to the next round, and the pile that does
|
||
not. We also re-examine the entries that were eliminated in the
|
||
previous round. Thus, an entry gets at least two readings.</p>
|
||
<p>A reading consists of a number of actions:</p>
|
||
<ul>
|
||
<li>reading the “how to build” information and forming a Makefile</li>
|
||
<li>reading prog.c, the C source</li>
|
||
<li>reviewing the “remarks” information</li>
|
||
<li>briefly looking any any supplied data files</li>
|
||
<li>passing the source thru the C pre-processor
|
||
skipping over any #include files</li>
|
||
<li>performing a number of C beautify/cleanup edits on the source</li>
|
||
<li>passing the beautified source thru the C pre-processor
|
||
skipping over any #include files</li>
|
||
<li>compiling/building the source</li>
|
||
<li>running the program</li>
|
||
<li>Doing other things that only IOCCC judges know about :-)</li>
|
||
</ul>
|
||
<p>In later rounds, other actions are performed including performing
|
||
miscellaneous tests on the source and binary.</p>
|
||
<p><strong><code>|</code></strong> This is the very guideline that goes, BING!</p>
|
||
<p>Until we reduce the stack of entries down to about 25 entries, entries
|
||
are judged on an individual basis. An entry is set aside because it
|
||
does not, in our opinion, meet the standard established by the round.
|
||
When the number of entries thins to about 25 entries, we begin to form
|
||
award categories. Entries begin to compete with each other for awards.
|
||
An entry will often compete in several categories.</p>
|
||
<p>The actual award category list will vary depending on the types of entries
|
||
we receive. A typical category list might be:</p>
|
||
<ul>
|
||
<li>best small one line program (see above about one line programs)</li>
|
||
<li>best small program</li>
|
||
<li>strangest/most creative source layout</li>
|
||
<li>most useful obfuscated program</li>
|
||
<li>best game that is obfuscated</li>
|
||
<li>most creatively obfuscated program</li>
|
||
<li>most deceptive C code (code with deceptive comments and source code)</li>
|
||
<li>best X client (see OUR LIKES AND DISLIKES)</li>
|
||
<li>best abuse of ISO C or ANSI C standard (see above about compilers)</li>
|
||
<li>best abuse of the C preprocessor</li>
|
||
<li>worst abuse of the rules</li>
|
||
<li>(anything else so strange that it deserves an award)</li>
|
||
</ul>
|
||
<p>We do not limit ourselves to this list. For example, a few entries are so
|
||
good/bad that they are declared winners at the start of the final round.
|
||
We will invent awards categories for them, if necessary.</p>
|
||
<p>In the final round process, we perform the difficult tasks of
|
||
reducing the remaining entries (typically about 25) down to to about
|
||
half that number: declaring those remaining to be winners.</p>
|
||
<p>Often we are confident that the entries that make it into
|
||
the final round are definitely better than the ones that do not
|
||
make it. The selection of the winners out of the final round, is
|
||
less clear cut.</p>
|
||
<p>Sometimes a final round entry is good enough to win, but is beat out
|
||
by a similar, but slightly better entry. For this reason, it is
|
||
sometimes worthwhile to re-enter an improved version of an entry
|
||
that failed to win in a previous year. This assumes, of course,
|
||
that the entry is worth improving in the first place!</p>
|
||
<p>More than one IOCCC judge has been known to bribe another IOCCC judge
|
||
into voting for a winning entry by offering a bit high quality chocolate.
|
||
This technique is highly discouraged for use by non-IOCCC judges.</p>
|
||
<p>More often than not, we select a small entry (usually one line), a
|
||
strange/creative layout entry. We sometimes also select an
|
||
entry that abuses the contest guidelines in an interesting way,
|
||
or that stretches the content rules that while legal, is
|
||
nevertheless goes against the intent of the rules.</p>
|
||
<p>In the end, we traditionally pick one entry as ‘best’. Sometimes such
|
||
an entry simply far exceeds any of the other entries. More often, the
|
||
‘best’ is picked because it does well in a number of categories.</p>
|
||
<p>In years past, we renamed the winning entry from prog.c to a
|
||
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
|
||
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>
|
||
<h2 id="an-important-update-to-this-historic-note">An important update to this historic note</h2>
|
||
<p><strong>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-</strong></p>
|
||
<p><strong><code>|</code></strong> <strong>The IOCCC no longer uses twitter</strong>.</p>
|
||
<p><strong><code>|</code></strong> Today the <a href="../contact.html#mastodon">IOCCC uses Mastodon</a>.</p>
|
||
<p><strong><code>|</code></strong> For more information and to see our IOCCC Mastodon posts, see:</p>
|
||
<pre><code> https://fosstodon.org/@ioccc</code></pre>
|
||
<p><strong>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-</strong></p>
|
||
<p>Non-twitter users should force their browsers to reload the above URL
|
||
to be sure they are seeing the most recent tweets.</p>
|
||
<p>The judges will then post an initial announcement of who won, the name
|
||
of their award, and a very brief description of the winning entry
|
||
on the IOCCC web site:</p>
|
||
<pre><code> https://www.ioccc.org/whowon.html</code></pre>
|
||
<p>We will also attempt to submit a brief announcement story to /.:</p>
|
||
<pre><code> https://slashdot.org</code></pre>
|
||
<p>that, depending on the willingness of the /. editors, may be posted
|
||
to their site at the same time.</p>
|
||
<p>Note that initial announcement will NOT contain source. This is because
|
||
the winning authors are given a chance to review the judges comments,
|
||
and test our Makefile. This review process typically takes a few weeks.</p>
|
||
<p>Sometime after the initial announcement, and once the review
|
||
by the winners has been completed, the winning source will be
|
||
posted to the IOCCC web site:</p>
|
||
<pre><code> https://www.ioccc.org/years.html
|
||
|
||
NOTE: previous winners are available at that URL</code></pre>
|
||
<p>We will also tweet, via <span class="citation" data-cites="IOCCC">@IOCCC</span>, when the winning source is available.</p>
|
||
<h2 id="an-important-2023-update-to-how-winners-are-announced-1">An important 2023 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 IOCCC entries repo:</p>
|
||
<pre><code> https://github.com/ioccc-src/winner</code></pre>
|
||
<p>that, in turn, updates the official IOCCC web site:</p>
|
||
<pre><code> https://www.ioccc.org/index.html</code></pre>
|
||
<p>In addition a note is posted to the IOCCC Mastodon account:</p>
|
||
<pre><code> https://fosstodon.org/@ioccc</code></pre>
|
||
<h2 id="back-to-annoucement-of-winners">Back to annoucement of winners</h2>
|
||
<p>It is pointless to ask the IOCCC judges how many entries we receive.
|
||
Other government TLA or FLA snooping organizations are prohibited from
|
||
either confirming, denying or revealing any knowledge of this data point.</p>
|
||
<p>Often, winning entries are published in selected magazines from around
|
||
the world. Winners have appeared in books (“The New Hackers Dictionary”)
|
||
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>You may contact the judges by sending email to the following address:</p>
|
||
<pre><code>| q.2020@ioccc.org (do not submit entries to this address)</code></pre>
|
||
<p><strong><code>|</code></strong> You must include the words ‘ioccc 2020 question’ in the subject of your
|
||
email message when sending email to the judges.</p>
|
||
<p>Questions and comments about the contest are welcome. Comments about
|
||
confusing rules and guidelines are also welcome.</p>
|
||
<p>The rules and the guidelines may (and often do) change from year to
|
||
year. You should be sure you have the current rules and guidelines
|
||
prior to submitting entries.</p>
|
||
<p>Check out the IOCCC Web page:</p>
|
||
<pre><code> https://www.ioccc.org</code></pre>
|
||
<p>It has rules, guidelines and winners of previous contests (1984 to date).</p>
|
||
<p>For the updates and breaking IOCCC news, you are encouraged to follow
|
||
the twitter handle:</p>
|
||
<pre><code> @IOCCC</code></pre>
|
||
<p>You do not have to be a twitter user to follow <span class="citation" data-cites="IOCCC">@IOCCC</span>. Non-twitter
|
||
users should access:</p>
|
||
<pre><code> https://twitter.com/ioccc</code></pre>
|
||
<p>Non-twitter users should force their browsers to reload the above URL
|
||
to be sure they are seeing the most recent tweets.</p>
|
||
<h2 id="an-important-update-to-this-historic-note-1">An important update to this historic note</h2>
|
||
<p><strong>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-</strong></p>
|
||
<p><strong><code>|</code></strong> <strong>The IOCCC no longer uses twitter</strong>.</p>
|
||
<p><strong><code>|</code></strong> Today the <a href="../contact.html#mastodon">IOCCC uses Mastodon</a>.</p>
|
||
<p><strong><code>|</code></strong> For more information and to see our IOCCC Mastodon posts, see:</p>
|
||
<pre><code> https://fosstodon.org/@ioccc</code></pre>
|
||
<p><strong>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-</strong></p>
|
||
<p>Leonid A. Broukhis
|
||
chongo (Landon Curt Noll) //<br />
|
||
</p>
|
||
|
||
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||
<!-- START: this line starts content from: inc/after-content.default.html -->
|
||
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/after-content.default.html -->
|
||
<!-- START: this line starts content from: inc/end-rightcolumn.default.html -->
|
||
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/end-rightcolumn.default.html -->
|
||
<!-- START: this line starts content from: inc/end-row.default.html -->
|
||
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/end-row.default.html -->
|
||
<!-- START: this line starts content from: inc/footer.default.html -->
|
||
|
||
<!--
|
||
|
||
Copyright © 1984-2024 by Landon Curt Noll. All Rights Reserved.
|
||
|
||
You are free to share and adapt this file under the terms of this license:
|
||
|
||
Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
|
||
|
||
For more information, see:
|
||
|
||
https://creativecommons.org/licenses/by-sa/4.0/
|
||
|
||
-->
|
||
|
||
<div class="footer">
|
||
<h2><div id="copyright">Copyright and CC BY-SA 4.0 License</div></h2>
|
||
<p>All IOCCC content including this file and web page are:</p>
|
||
<b> Copyright © 1984-2024 by Landon Curt Noll. <a href="https://creativecommons.org/faq/#what-does-some-rights-reserved-mean">Some Rights Reserved</a>.</b>
|
||
<p>This work is licensed by Landon Curt Noll under:</p>
|
||
<p><b><a href="https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1"
|
||
target="_blank" rel="license noopener noreferrer" style="display:inline-block;"> CC BY-SA 4.0
|
||
<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;"
|
||
src="../png/cc.png"
|
||
alt="cc inside circle symbol">
|
||
<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;"
|
||
src="../png/by.png"
|
||
alt="person inside circle symbol">
|
||
<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;"
|
||
src="../png/sa.png"
|
||
alt="arrow looping back on itself inside circle symbol">
|
||
</a></b></p>
|
||
<p>The <b>CC BY-SA 4.0 LEGAL CODE</b> for this license is found under:</p>
|
||
<p> <b><a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.en">
|
||
https://creativecommons.org/licenses/by-sa/4.0/legalcode.en</a></b></p>
|
||
<p>You should <b>carefully review</b> all of the terms and conditions of the
|
||
<a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.en">actual license</a>
|
||
before using the licensed material.</p>
|
||
<p>You may wish to review the <b><a href="../license.html">highlights of some of the key
|
||
features and terms</a></b> of the <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.en">actual license</a>.</p>
|
||
<h2>Coda</h2>
|
||
<p><a href="https://validator.w3.org/nu/?doc=https%3A%2F%2Fioccc-src.github.io%2Ftemp-test-ioccc%2Fnext%2Fguidelines.html">Nu HTML check this web page</a></p>
|
||
<p><a href="#top">Jump to top</a> <a href="#content">Jump to Content</a> <a href="#inventory">Jump to Inventory</a></p>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/footer.default.html -->
|
||
<!-- START: this line starts content from: inc/bottom.default.html -->
|
||
|
||
</body>
|
||
</html>
|
||
|
||
<!-- END: this line ends content from: inc/bottom.default.html -->
|