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

add rules, guidelines, fix HTML code, move compressed tarball in inventory

Browse Source 
By changing the _inventory_order_ of the compressed tarball from
**100000** to **1415926535**, the compressed tarball will land at
the top of the secondary file list and remain still easy to find.

Updated the `manifest.numbers` spreadsheet and rebuilt
the `.entry.json` files.

Added `next/` directory to hold the next IOCCC rules and guidelines.
Added `next/README.md` that `bin/gen-top-html.sh` uses to form
the `next/index.html` file.

Added _Rules and Guidelines_ link to the sidenav bar to link to the
`next/index.html` file.

Added _IOCCC Rules_ as `next/rules.md` that `bin/gen-top-html.sh`
uses to form the `next/rules.html` file.

Added _IOCCC Guidelines_ as `next/guidelines.md` that `bin/gen-top-html.sh`
uses to form the `next/guidelines.html` file.

Changed `bin/gen-top-html.sh` VERSION from "1.2.4 2024-04-13"
to "1.3 2024-04-14".

Prevent `pandoc(1)` from interpreting the commented out language
of a markdown code block as a code class.  So a markdown such as:

````
``` <!---sh-->
...
```
````

that produced HTML of the form:

```html
<pre class="&lt;!---sh--&gt;"><code>...</code></pre>
```

will now produce HTML of the form:

```html
<pre><code>...</code></pre>
```

NOTE: Before when the language of a markdown code block
was not commented, the HTML produced by `pandoc(1)` was
oddly indented with extra whitespace on the first line
of the code block.  While commenting out the language
of the code block removed some of the odd intending,
it left a weird class in the HTML pre block that
surrounded the HTML code block.  This hack prevents
`pandoc(1)` from assigning a class to the HTML pre block.

Changed `in/md2html.sh` VERSION from "1.2.1 2024-04-13"
to "1.3 2024-04-14".

Added `make gen_sitemap` to end of both `make www` and `make
quick_www` in top level Makefile.

Ram `make www` to test under macOS and to perform the above.

**IMPORTANT NOTE**: The current `next/rules.md` and `next/guidelines.md`
are simply the 2020 IOCCC Rules and Guidelines converted into
markdown form.  There are **NOT** the Rules and Guidelines that
will be used the IOCCC MOCK, nor the next IOCCC.

TODO: Improve the `bin/gen-status.sh` tool to modify the top of the
      `next/rules.md` and `next/guidelines.md` files to keep them
      in sync with the _contest_status_ as found in `status.json`.

TODO: Improve the look and feel of the `next/rules.md` and
      `next/guidelines.md` markdown files.
This commit is contained in:
Landon Curt Noll committed 2024-04-14 16:54:24 -07:00
1 parent a672335d2d
commit 518a6336d0
734 files changed
+7919 -4119
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

next/README.md
+86
View File
@@ -0,0 +1,86 @@
# IOCCC Rules and Guidelines
**IMPORTANT**: Did you read the **Important disclaimers about scope**
and did you check the current **[IOCCC status](../status.html)**?
* [IOCCC rules](rules.html)
* [IOCCC guidelines](guidelines.html)
You may also wish to review the
[mkiocccentry tool repo](https://github.com/ioccc-src/mkiocccentry),
especially when the [rules](rules.html) and [guidelines](guidelines.html)
are official, to be sure you are **using an up to date official mkiocccentry tool set**.
# Important disclaimers about scope
### When the IOCCC status is closed
When the IOCCC status is closed, the [rules](rules.html) and [guidelines](guidelines.html)
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 **tentative** hint at what
might be used for the next IOCCC.
**IMPORTANT**: All **tentative** [rules](rules.html) and [guidelines](guidelines.html)
are subject to change by the [IOCCC judges](../judges.html) at any time.
See both the [IOCCC news](../news.html) and the [IOCCC
Mastodon](https://fosstodon.org/@ioccc) feed as _sometimes_ the
[IOCCC judges](../judges.html) _mention_ changes there.
### When the IOCCC status is pending
When the IOCCC status is pending, the [rules](rules.html) and [guidelines](guidelines.html) are
**tentative**.
One might think of them as a **beta** release for the IOCCC
that is about to open.
**IMPORTANT**: All **tentative** [rules](rules.html) and [guidelines](guidelines.html)
are subject to change by the [IOCCC judges](../judges.html) at any time.
See both the [IOCCC news](../news.html) and the [IOCCC
Mastodon](https://fosstodon.org/@ioccc) feed as _sometimes_ the
[IOCCC judges](../judges.html) _mention_ changes there.
### When the IOCCC status is open
When the IOCCC status is open, the [rules](rules.html) and [guidelines](guidelines.html) are **OFFICIAL**.
Unless some significant problem turns up (such as a need to delay
in when the IOCCC will close, or some major bug is discovered) they
will remain **OFFICIAL** for this IOCCC.
**SUGGESTION**: Watch both the [IOCCC news](../news.html) and the [IOCCC
Mastodon](https://fosstodon.org/@ioccc) feed for the latest news
about any _mentions_ changes.
### When the IOCCC status is judging
When the IOCCC status is judging, the [rules](rules.html) and [guidelines](guidelines.html) are
for the current IOCCC that is no **longer open for new submissions**.
See the [IOCCC news](../news.html) and well as the [IOCCC
Mastodon](https://fosstodon.org/@ioccc) feed for updates
on the IOCCC judging process as well as for the announcement
for [who won the IOCCC](../years.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/
-->
next/guidelines.html
+972
View File
@@ -0,0 +1,972 @@
<!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">
&nbsp;
</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 &amp; (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 -->
<a name="content"></a>
<!-- 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 &lt; 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
&#39;;&#39;, &#39;{&#39; or &#39;}&#39; followed by ASCII whitespace, and excluding any
&#39;;&#39;, &#39;{&#39; or &#39;}&#39; 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 &gt; 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 /* &lt;-- don&#39;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; /* &lt;-- 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(&quot;The machine that goes BING!\n&quot;);
}
| 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 &lt;varargs.h&gt;. Use &lt;stdarg.h&gt; 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 &lt;windows.h&gt; /* 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 &gt; 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 &quot;See remarks section about alternate ways to compile&quot;</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 = &quot;So many primes, so little time!&quot;;
...
T[14] = &#39;;&#39;;</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[] = &quot;Is this OK&quot;;
b[9] = &#39;K&#39;;</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 &lt;== 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 &gt;= 128) will be rejected.
Instead of unescaped octets, you should use or escapes:</p>
<pre><code> /* 123456789 123456789 123456789 123456 */
char *foo = &quot;This string is 36 octets in length \263&quot;;
/* This octet requires 4 octets of source ^^^^ */
if (strlen(foo) == 36) printf(&quot;foo is 36 octets plus a final NUL\n&quot;);
else printf(&quot;This code should not print this message\n&quot;);</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. &lt;&lt;– 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 -->
<!-- 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><a name="copyright"></a>Copyright and CC BY-SA 4.0 License</h2>
<p>All IOCCC content including this file and web page are:</p>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Copyright &copy; 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 xmlns:cc="http://creativecommons.org/ns#" ><b><a href="https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1"
target="_blank" rel="license noopener noreferrer" style="display:inline-block;">&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;<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%2Flocation.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 -->
next/guidelines.md
+1160
View File
File diff suppressed because it is too large. Load diff
next/index.html
+255
View File
@@ -0,0 +1,255 @@
<!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 Rules and Guidelines">
<meta name="keywords" content="IOCCC, rules, Rules, 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/README.md -->
<!-- -->
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
<!-- !!! Do not modify this web page, instead modify the file: next/README.md !!! -->
<!-- !!! Do not modify this web page, instead modify the file: next/README.md !!! -->
<!-- !!! Do not modify this web page, instead modify the file: next/README.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 Rules and 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">
&nbsp;
</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 &amp; (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 -->
<a name="content"></a>
<!-- 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 -->
<h1 id="ioccc-rules-and-guidelines">IOCCC Rules and Guidelines</h1>
<p><strong>IMPORTANT</strong>: Did you read the <strong>Important disclaimers about scope</strong>
and did you check the current <strong><a href="../status.html">IOCCC status</a></strong>?</p>
<ul>
<li><a href="rules.html">IOCCC rules</a></li>
<li><a href="guidelines.html">IOCCC guidelines</a></li>
</ul>
<p>You may also wish to review the
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry tool repo</a>,
especially when the <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a>
are official, to be sure you are <strong>using an up to date official mkiocccentry tool set</strong>.</p>
<h1 id="important-disclaimers-about-scope">Important disclaimers about scope</h1>
<h3 id="when-the-ioccc-status-is-closed">When the IOCCC status is closed</h3>
<p>When the IOCCC status is closed, the <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a>
are <strong>OUT OF DATE</strong>.</p>
<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>tentative</strong> hint at what
might be used for the next IOCCC.</p>
<p><strong>IMPORTANT</strong>: All <strong>tentative</strong> <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a>
are subject to change by the <a href="../judges.html">IOCCC judges</a> at any time.
See both the <a href="../news.html">IOCCC news</a> and the <a href="https://fosstodon.org/@ioccc">IOCCC
Mastodon</a> feed as <em>sometimes</em> the
<a href="../judges.html">IOCCC judges</a> <em>mention</em> changes there.</p>
<h3 id="when-the-ioccc-status-is-pending">When the IOCCC status is pending</h3>
<p>When the IOCCC status is pending, the <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a> are
<strong>tentative</strong>.</p>
<p>One might think of them as a <strong>beta</strong> release for the IOCCC
that is about to open.</p>
<p><strong>IMPORTANT</strong>: All <strong>tentative</strong> <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a>
are subject to change by the <a href="../judges.html">IOCCC judges</a> at any time.
See both the <a href="../news.html">IOCCC news</a> and the <a href="https://fosstodon.org/@ioccc">IOCCC
Mastodon</a> feed as <em>sometimes</em> the
<a href="../judges.html">IOCCC judges</a> <em>mention</em> changes there.</p>
<h3 id="when-the-ioccc-status-is-open">When the IOCCC status is open</h3>
<p>When the IOCCC status is open, the <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a> are <strong>OFFICIAL</strong>.</p>
<p>Unless some significant problem turns up (such as a need to delay
in when the IOCCC will close, or some major bug is discovered) they
will remain <strong>OFFICIAL</strong> for this IOCCC.</p>
<p><strong>SUGGESTION</strong>: Watch both the <a href="../news.html">IOCCC news</a> and the <a href="https://fosstodon.org/@ioccc">IOCCC
Mastodon</a> feed for the latest news
about any <em>mentions</em> changes.</p>
<h3 id="when-the-ioccc-status-is-judging">When the IOCCC status is judging</h3>
<p>When the IOCCC status is judging, the <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a> are
for the current IOCCC that is no <strong>longer open for new submissions</strong>.</p>
<p>See the <a href="../news.html">IOCCC news</a> and well as the <a href="https://fosstodon.org/@ioccc">IOCCC
Mastodon</a> feed for updates
on the IOCCC judging process as well as for the announcement
for <a href="../years.html">who won the IOCCC</a>.</p>
<!--
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/
-->
<!-- 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 -->
<!-- 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><a name="copyright"></a>Copyright and CC BY-SA 4.0 License</h2>
<p>All IOCCC content including this file and web page are:</p>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Copyright &copy; 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 xmlns:cc="http://creativecommons.org/ns#" ><b><a href="https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1"
target="_blank" rel="license noopener noreferrer" style="display:inline-block;">&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;<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%2Flocation.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 -->
next/rules.html
+430
View File
@@ -0,0 +1,430 @@
<!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 rules and guidelines">
<meta name="keywords" content="IOCCC, rules, Rules">
</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/rules.md -->
<!-- -->
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
<!-- !!! Do not modify this web page, instead modify the file: next/rules.md !!! -->
<!-- !!! Do not modify this web page, instead modify the file: next/rules.md !!! -->
<!-- !!! Do not modify this web page, instead modify the file: next/rules.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 Rules</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">
&nbsp;
</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 &amp; (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 -->
<a name="content"></a>
<!-- 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/rules.closed.hdr -->
<h1 id="warning-these-rules-are-out-of-date">WARNING: These rules 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 rules 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/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">27th International Obfuscated C Code Contest Official Rules</h1>
<p><strong><code>|</code></strong> 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 <a href="../contact.html">contest judges</a>.</p>
<h2 id="rules-version">Rules version</h2>
<p><strong><code>|</code></strong> These rules are version <strong>2024-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="obfuscate-defined">Obfuscate defined:</h1>
<p>tr.v. -cated, -cating, -cates.
<BR><BR>
<strong>1a.</strong> To render obscure.<BR>
<strong>1b.</strong> To darken.
<BR><BR>
<strong>2.</strong> To confuse: his emotions obfuscated his judgment.<BR>
    [LLat. obfuscare, to darken : ob(intensive) + Lat. fuscare,<BR>
    to darken &lt; fuscus, dark.] -obfuscation n. obfuscatory adj.</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 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>
<li>To provide a safe forum for poor C code. :-)</li>
</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
tool should be considered provisional BETA versions and may be
adjusted at any time.</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
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 and iocccsize.c tool will be available
on the official IOCCC web site on or slightly before start of this IOCCC.</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>
<h1 id="rules">RULES</h1>
<p>To help us with the volume of entries, we ask that you follow these rules:</p>
<h2 id="rule-0">Rule 0</h2>
<p>We need a rule 0. :-)</p>
<h2 id="rule-1">Rule 1</h2>
<p>Your entry must be a complete program.</p>
<h2 id="rule-2">Rule 2</h2>
<p><strong><code>|</code></strong> The size rule requires your entry to satisfy BOTH rule 2a and rule 2b:</p>
<h2 id="rule-2a">Rule 2a</h2>
<p>The size of your program source <strong>must be &lt;= 4096 bytes</strong>in length.</p>
<h2 id="rule-2b">Rule 2b</h2>
<p>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
value printed <strong>shall not exceed 2053</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>.</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>
<p>To submit to an open IOCCC, you must 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>.
Please wait to submit your entries until after that time.</p>
<h2 id="rule-4">Rule 4</h2>
<p>If your entry is selected as a winner, it will be modified as follows:</p>
<p>Your ‘build’ instructions will be incorporated into a Makefile.</p>
<p>Your source code will be the file <strong>prog.c</strong>. The compiled binary
will be called <strong>prog</strong>.</p>
<h2 id="rule-5">Rule 5</h2>
<p>Your entry must not modify the content or filename of any part of your
original entry including, but not limited to prog.c, the Makefile
(we create from your how to build instructions), as well as any data
files you submit.</p>
<p>If you entry wishes to modify such content, it must 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 free(void *man)!</p>
<pre><code> while (!understand(ioccc(rule(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 authors) must own the contents of your submission OR
you must have permission from the owners to submit their content
under the following license:</p>
<p><strong><code>|</code></strong> <strong><a href="https://creativecommons.org/licenses/by-sa/4.0/">CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International</a></strong></p>
<p>See also Rule 18.</p>
<p>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.</p>
<p>Please note that the IOCCC size tool is not 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:</p>
<pre><code> 2020-Mar-15 06:26:49 UTC</code></pre>
<p>A confirmation of submission will be sent to the submitter 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>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>
<h2 id="rule-11">Rule 11</h2>
<p>Programs that require special privileges (setuid, setgid, 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.</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.
Entries that attempt to abuse the rules must try to justify why
their rule abuse is legal in the remarks file.</p>
<h2 id="rule-13">Rule 13</h2>
<p>Any C source that fails to compile because of unescaped octets with
the high bit set (octet value &gt;= 128) will be rejected.</p>
<h2 id="rule-14">Rule 14</h2>
<p>Any C source that fails to compile because of lines with trailing
control-M’s (i.e., lines with a tailing octet 015) will be rejected.</p>
<p>Please do not put trailing control-M’s on remarks file lines.
Please check to be sure, before submitting, that you have removed
any control-M at the end of remark file lines.</p>
<h2 id="rule-15">Rule 15</h2>
<p>When you submit your entry you must have a valid email address
that can both send and receive email. The online submission
method is a two phase process that requires the use of an
approval code. This code will be emailed to you as part of
phase 1.</p>
<p>Entries submitted without a working or valid email address will
be disqualified.</p>
<p>The judges are not responsible for delays in email, please plan
enough time for one automated exchange of email as part of your
submission.</p>
<p>After your email address has been confirmed, the submission code will
be valid for submitting and editing the entry for the lifetime of the
competition.</p>
<h2 id="rule-16">Rule 16</h2>
<p>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.</p>
<h2 id="rule-17">Rule 17</h2>
<p>The total size of your submission: the sum of the size of the program,
hints, comments, build and info files MUST be less than or equal
to 1048576 octets in size.</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 authors) must own the contents of your submission OR
you must have permission from the owners 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
the Daring Fireball {Markdown: Basics](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 make form.</p>
<p>The target of the make file must be called prog. The original
C source file must be called prog.c.</p>
<p>To invoke the C compiler, use <code>${CC}</code>.
To invoke the C preprocessor use <code>${CPP}</code>.</p>
<p>Do not assume that . (the current directory) is in the <code>$PATH</code>.</p>
<p>Use a shell command syntax that is compatible with bash.</p>
<p>Assume that commands commonly found in POSIX-like / Linux-like systems
are available in the search path.</p>
<p>Do not assume any particular given value of <code>${CFLAGS}</code> or other
commonly used make variables.</p>
<h2 id="rule-21">Rule 21</h2>
<p>Your entry must not create nor modify files above the current directory
with the exception of the <code>/tmp</code> and the <code>/var/tmp</code> directories. Your entry
may create subdirectories below the current directory, or in /tmp,
or in <code>/var/tmp</code> provided that “<strong>.</strong>” is <strong>not</strong> the first octet in any
directory name.</p>
<h2 id="rule-22">Rule 22</h2>
<p>Catch 22:</p>
<p>Your source code, data files, remarks and program output must <strong>NOT</strong>
identify the authors of your code. The judges <strong>STRONGLY prefer</strong> to
not know who is submitting entries to the IOCCC.</p>
<p>Even if you are a previous IOCCC winner, catch 22 still applies.</p>
<p>Identifying the authors of your entry in an obvious way anywhere
within in 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>
<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>
<p>Even though 24 is not prime, you should still see rule #23.</p>
<h2 id="rule-25">Rule 25</h2>
<p><strong><code>|</code></strong> The IOCCC rule set consists of at least 26 rules.</p>
<h2 id="rule-26">Rule 26</h2>
<p><strong><code>|</code></strong> Rule 26 is also a rule.</p>
<h1 id="for-more-information">FOR MORE INFORMATION:</h1>
<p>The judging will be done by Leonid A. Broukhis, Simon Cooper,
Landon Curt Noll.</p>
<p><strong><code>|</code></strong> Please send questions or comments about the contest, to:</p>
<pre><code> q.2020@ioccc.org</code></pre>
<p><strong><code>|</code></strong> <strong>IMPORANT</strong>: You must include the words <strong>ioccc 2020 question</strong>
in the subject of your email message when sending email to the judges.</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><strong><code>|</code></strong> See the <a href="../index.html">Official IOCCC web site</a> for additional information.</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">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<br>
Simon Cooper<br>
chongo (Landon Curt Noll) <code>/\cc/\</code></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 -->
<!-- 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><a name="copyright"></a>Copyright and CC BY-SA 4.0 License</h2>
<p>All IOCCC content including this file and web page are:</p>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Copyright &copy; 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 xmlns:cc="http://creativecommons.org/ns#" ><b><a href="https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1"
target="_blank" rel="license noopener noreferrer" style="display:inline-block;">&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;<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%2Flocation.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 -->
next/rules.md
+426
View File
@@ -0,0 +1,426 @@
<!-- START: this line starts content from: inc/rules.closed.hdr -->
# 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.
Please regard these rules as a historic 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 entires that have won the IOCCC.
Watch both [the IOCCC status page](status.html) and the
[@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 -->
# 27th International Obfuscated C Code Contest Official Rules
**`|`** Copyright &copy; 2024 Leonid A. Broukhis, 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
and remains unaltered. All other uses must receive prior permission in
writing from the [contest judges](../contact.html).
## Rules version
**`|`** These rules are version **2024-04-04-v28**.
### Change marks
**`|`** **&larr; Lines that start with this symbol indicate a change from the previous IOCCC**
Most lines (we sometimes make mistakes) that were modified start the **`|`** symbol.
# Obfuscate defined:
tr.v. -cated, -cating, -cates.
<BR><BR>
**1a.** To render obscure.<BR>
**1b.** To darken.
<BR><BR>
**2.** To confuse: his emotions obfuscated his judgment.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;[LLat. obfuscare, to darken : ob(intensive) + Lat. fuscare,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;to darken &lt; fuscus, dark.] -obfuscation n. obfuscatory adj.
# Goals of the Contest
The goals of the IOCCC:
* To write the most Obscure/Obfuscated C program within the rules.
* 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.
* To provide a safe forum for poor C code. :-)
# Important IOCCC dates
**`|`** 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
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
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 and iocccsize.c tool will be available
on the official IOCCC web site on or slightly before start of this IOCCC.
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.
# RULES
To help us with the volume of entries, we ask that you follow these rules:
## Rule 0
We need a rule 0. :-)
## Rule 1
Your entry must be a complete program.
## Rule 2
**`|`** The size rule requires your entry to satisfy BOTH rule 2a and rule 2b:
## Rule 2a
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
value printed **shall not exceed 2053**.
**`|`** The source to the current IOCCC size tool is found in the
[mkiocccentry tool repo](https://github.com/ioccc-src/mkiocccentry).
## Rule 3
Submissions should be performed using the instructions outlined at:
the [How to enter link](../faq.html#submit) link.
To submit to an open IOCCC, you must the [IOCCC submit server](https://submit.ioccc.org/).
When the IOCCC is not open, that link will likely be unresponsive.
**`|`** 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.
## Rule 4
If your entry is selected as a winner, it will be modified as follows:
Your 'build' instructions will be incorporated into a Makefile.
Your source code will be the file **prog.c**. The compiled binary
will be called **prog**.
## Rule 5
Your entry must not modify the content or filename of any part of your
original entry including, but not limited to prog.c, the Makefile
(we create from your how to build instructions), as well as any data
files you submit.
If you entry wishes to modify such content, it must first copy the
file to a new filename and then modify that copy.
## Rule 6
**`|`** I am not a rule, I am a free(void \*man)!
``` <!---c-->
while (!understand(ioccc(rule(you(are(number(6))))))) { ha_ha_ha(); }
```
## Rule 7
The obfuscated C program must be an original work that you own.
You (the authors) must own the contents of your submission OR
you must have permission from the owners to submit their content
under the following license:
**`|`** **[CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/)**
See also Rule 18.
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.
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:
```
2020-Mar-15 06:26:49 UTC
```
A confirmation of submission will be sent to the submitter email address before the close of the contest.
## Rule 9
**`|`** Each person may submit up to and including 8.000000 entries per contest.
Each entry must be submitted separately.
## Rule 10
Entries requiring human interaction to be initially compiled are not permitted.
## Rule 11
Programs that require special privileges (setuid, setgid, 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.
## Rule 12
Legal abuse of the rules is somewhat encouraged. An entry that, in
the opinion of the judges, violates the rules will be disqualified.
Entries that attempt to abuse the rules must try to justify why
their rule abuse is legal in the remarks file.
## Rule 13
Any C source that fails to compile because of unescaped octets with
the high bit set (octet value >= 128) will be rejected.
## Rule 14
Any C source that fails to compile because of lines with trailing
control-M's (i.e., lines with a tailing octet 015) will be rejected.
Please do not put trailing control-M's on remarks file lines.
Please check to be sure, before submitting, that you have removed
any control-M at the end of remark file lines.
## Rule 15
When you submit your entry you must have a valid email address
that can both send and receive email. The online submission
method is a two phase process that requires the use of an
approval code. This code will be emailed to you as part of
phase 1.
Entries submitted without a working or valid email address will
be disqualified.
The judges are not responsible for delays in email, please plan
enough time for one automated exchange of email as part of your
submission.
After your email address has been confirmed, the submission code will
be valid for submitting and editing the entry for the lifetime of the
competition.
## Rule 16
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.
## Rule 17
The total size of your submission: the sum of the size of the program,
hints, comments, build and info files MUST be less than or equal
to 1048576 octets in size.
## Rule 18
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 authors) must own the contents of your submission OR
you must have permission from the owners to submit their content
You must not submit anything that cannot be submitted under that license.
## Rule 19
The remarks file must be written in markdown format. See
the Daring Fireball {Markdown: Basics](http://daringfireball.net/projects/markdown/basics)
for more information.
**`|`** We currently use [pandoc](https://pandoc.org) to convert markdown to HTML.
## Rule 20
The how to build instructions must be in make form.
The target of the make file must be called prog. The original
C source file must be called prog.c.
To invoke the C compiler, use `${CC}`.
To invoke the C preprocessor use `${CPP}`.
Do not assume that . (the current directory) is in the `$PATH`.
Use a shell command syntax that is compatible with bash.
Assume that commands commonly found in POSIX-like / Linux-like systems
are available in the search path.
Do not assume any particular given value of `${CFLAGS}` or other
commonly used make variables.
## Rule 21
Your entry must not create nor 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
directory name.
## Rule 22
Catch 22:
Your source code, data files, remarks and program output must **NOT**
identify the authors of your code. The judges **STRONGLY prefer** to
not know who is submitting entries to the IOCCC.
Even if you are a previous IOCCC winner, catch 22 still applies.
Identifying the authors of your entry in an obvious way anywhere
within in 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**!
## Rule 23
This prime rule number is reserved for future use.
## Rule 24
Even though 24 is not prime, you should still see rule #23.
## Rule 25
**`|`** The IOCCC rule set consists of at least 26 rules.
## Rule 26
**`|`** Rule 26 is also a rule.
# FOR MORE INFORMATION:
The judging will be done by Leonid A. Broukhis, Simon Cooper,
Landon Curt Noll.
**`|`** Please send questions or comments about the contest, to:
```
q.2020@ioccc.org
```
**`|`** **IMPORANT**: You must include the words **ioccc 2020 question**
in the subject of your email message when sending email to the judges.
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.
**`|`** See the [Official IOCCC web site](../index.html) for additional information.
For the updates and breaking IOCCC news, you are encouraged to follow
the twitter handle:
```
@IOCCC
```
You do not have to be a twitter user to follow @IOCCC. Non-twitter users should access:
```
https://twitter.com/ioccc
```
Non-twitter users should force their browsers to reload the above URL
to be sure they are seeing the most recent tweets.
## An important update to this historic note
**-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-**
**`|`** **The IOCCC no longer uses twitter**.
**`|`** Today the [IOCCC uses Mastodon](../contact.html#mastodon).
**`|`** For more information and to see our IOCCC Mastodon posts, see:
```
https://fosstodon.org/@ioccc
```
**-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-**
Leonid A. Broukhis<br>
Simon Cooper<br>
chongo (Landon Curt Noll) `/\cc/\`