It should be 'Location of winning authors' (as it is now) but by mistake
there was an extra space ('Location of winning authors'). Obviously
this is a huge commit as every html file with a menu (almost all) had to
be updated.
1194 lines
63 KiB
HTML
1194 lines
63 KiB
HTML
<!DOCTYPE html>
|
||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||
<!-- START: two lines up starts content from: inc/top.default.html -->
|
||
|
||
<!-- END: this line ends content from: inc/top.default.html -->
|
||
<!-- START: this line starts content from: inc/head.default.html -->
|
||
|
||
<head>
|
||
<link rel="stylesheet" href="../ioccc.css">
|
||
<link href="https://fonts.googleapis.com/css2?family=Outfit:wght@100..900&display=swap" rel="stylesheet">
|
||
<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/topbar.default.html -->
|
||
|
||
<div class="theader">
|
||
<nav class="topbar">
|
||
<div class="container">
|
||
<div class="logo">
|
||
<a href="../index.html" class="logo-link">
|
||
IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="topbar-items">
|
||
<div class="item">
|
||
<span class="item-header">
|
||
Entries
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
<div class="outfit-font">
|
||
<a href="../years.html" class="sub-item-link">
|
||
Winning Entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../authors.html" class="sub-item-link">
|
||
Winning Authors
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../location.html" class="sub-item-link">
|
||
Location of winning authors
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../bugs.html" class="sub-item-link">
|
||
Bugs and (mis)features
|
||
</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
Status
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
<div class="outfit-font">
|
||
<a href="../news.html" class="sub-item-link">
|
||
IOCCC News
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../status.html" class="sub-item-link">
|
||
Contest status
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../next/index.html" class="sub-item-link">
|
||
Rules and Guidelines
|
||
</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
FAQ
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
<div class="outfit-font">
|
||
<a href="../faq.html" class="sub-item-link">
|
||
FAQ
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html#submit" class="sub-item-link">
|
||
How to enter the IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html#fix_an_entry" class="sub-item-link">
|
||
Fixing IOCCC entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html#fix_web_site" class="sub-item-link">
|
||
Fixing the website
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html#fix_author" class="sub-item-link">
|
||
Updating author info
|
||
</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
About
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
<div class="outfit-font">
|
||
<a href="../index.html" class="sub-item-link">
|
||
IOCCC Home
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../judges.html" class="sub-item-link">
|
||
The IOCCC Judges
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../contact.html" class="sub-item-link">
|
||
Contacting the IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../thanks-for-help.html" class="sub-item-link">
|
||
Thanks for the help
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../markdown.html" class="sub-item-link">
|
||
IOCCC markdown guidelines
|
||
</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</nav>
|
||
|
||
<div class="header-mobile-menu">
|
||
<noscript>
|
||
<a href="../nojs-menu.html" class="topbar-js-label">
|
||
Please Enable JavaScript
|
||
</a>
|
||
</noscript>
|
||
|
||
<button id="header-open-menu-button" class="topbar-mobile-menu">
|
||
<img
|
||
src="../png/hamburger-icon-open.png"
|
||
alt="hamburger style menu icon - open state"
|
||
width=48
|
||
height=48>
|
||
</button>
|
||
|
||
<button id="header-close-menu-button" class="hide-content">
|
||
<img
|
||
src="../png/hamburger-icon-closed.png"
|
||
alt="hamburger style menu icon - closed state"
|
||
width=48
|
||
height=48>
|
||
</button>
|
||
|
||
<div id="mobile-menu-panel" class="hide-content">
|
||
<div class="mobile-menu-container">
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
Entries
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../years.html">
|
||
Winning Entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../authors.html">
|
||
Authors of winning IOCCC entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../location.html">
|
||
Location of authors
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../bugs.html">
|
||
Bugs and (mis)features
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
|
||
<div class="mobile-menu-item">
|
||
Status
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../status.html">
|
||
Contest status
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../next/index.html">
|
||
Rules and Guidelines
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../news.html">
|
||
IOCCC News
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
FAQ
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html">
|
||
Frequently Asked Questions
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html#submit">
|
||
How to enter the IOCCC
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html#fix_an_entry">
|
||
Fixing IOCCC entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html#fix_web_site">
|
||
Fixing the website
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html#fix_author">
|
||
Fixing author info
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
About
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../index.html">
|
||
IOCCC Home
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../judges.html">
|
||
The IOCCC Judges
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../contact.html">
|
||
Contacting the IOCCC
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../thanks-for-help.html">
|
||
Thanks for the help
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
</div>
|
||
|
||
<script>
|
||
var headerOpenMenuButton = document.getElementById("header-open-menu-button");
|
||
var headerCloseMenuButton = document.getElementById("header-close-menu-button");
|
||
var mobileMenuPanel = document.getElementById("mobile-menu-panel");
|
||
|
||
headerOpenMenuButton.addEventListener("click", () => {
|
||
headerOpenMenuButton.classList.remove("topbar-mobile-menu");
|
||
headerOpenMenuButton.classList.add("hide-content");
|
||
|
||
headerCloseMenuButton.classList.remove("hide-content");
|
||
headerCloseMenuButton.classList.add("topbar-mobile-menu");
|
||
|
||
mobileMenuPanel.classList.remove("hide-content");
|
||
mobileMenuPanel.classList.add("topbar-mobile-panel");
|
||
});
|
||
|
||
headerCloseMenuButton.addEventListener("click", () => {
|
||
headerCloseMenuButton.classList.remove("topbar-mobile-menu");
|
||
headerCloseMenuButton.classList.add("hide-content");
|
||
|
||
mobileMenuPanel.classList.add("hide-content");
|
||
mobileMenuPanel.classList.remove("topbar-mobile-panel");
|
||
|
||
headerOpenMenuButton.classList.add("topbar-mobile-menu");
|
||
headerOpenMenuButton.classList.remove("hide-content");
|
||
});
|
||
</script>
|
||
|
||
<!-- END: this line ends content from: inc/topbar.default.html -->
|
||
<!-- START: this line starts content from: inc/header.default.html -->
|
||
|
||
<div class="header">
|
||
<a href="../2011/zucker/index.html">
|
||
<img src="../png/ioccc.png"
|
||
alt="IOCCC image by Matt Zucker"
|
||
width=300
|
||
height=110>
|
||
</a>
|
||
<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/navbar.empty.html -->
|
||
|
||
<div class="navbar">
|
||
<a class="Right" href="https://validator.w3.org/nu/?doc=https%3A%2F%2Fioccc-src.github.io%2Ftemp-test-ioccc%2Fnext%2Fguidelines.html">✓</a>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/navbar.empty.html -->
|
||
<!-- START: this line starts content from: inc/before-content.default.html -->
|
||
|
||
<div class="content" id="content">
|
||
|
||
<!-- END: this line ends content from: inc/before-content.default.html -->
|
||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||
|
||
<!-- BEFORE: 1st line of markdown file: next/guidelines.md -->
|
||
<h1 id="warning-these-guidelines-are-out-of-date">WARNING: These guidelines are OUT OF DATE</h1>
|
||
<p>These guidelines are a <strong>VERY TENTATIVE proposal</strong> for the next IOCCC
|
||
and are <strong>VERY LIKELY</strong> to be updated before the next IOCCC.
|
||
They are are provided as a <strong>VERY TENTATIVE</strong> hint at <strong>what
|
||
MIGHT</strong> be used in the next IOCCC.</p>
|
||
<p>Please regard these guidelines as a historical archive.</p>
|
||
<h1 id="the-ioccc-is-closed">The IOCCC is closed</h1>
|
||
<p>The IOCCC is <strong>NOT</strong> accepting new submissions at this time. See the
|
||
<a href="../years.html">IOCCC winning entries page</a> for the entries that have won the
|
||
IOCCC in the past.</p>
|
||
<p>Watch both <a href="../status.html">the IOCCC status page</a> and the
|
||
<a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> mastodon feed</a> for information about
|
||
future IOCCC openings.</p>
|
||
<!-- END: the next line ends content from: inc/guidelines.closed.hdr -->
|
||
<!-- This is the last line modified by the tool: bin/gen-status.sh -->
|
||
<h1 id="th-international-obfuscated-c-code-contest-official-guidelines">28th International Obfuscated C Code Contest Official Guidelines</h1>
|
||
<p>Copyright © 2024 Leonid A. Broukhis and Landon Curt Noll.</p>
|
||
<p>All Rights Reserved. Permission for personal, education or non-profit use is
|
||
granted provided this this copyright and notice are included in its entirety
|
||
and remains unaltered. All other uses must receive prior permission in
|
||
writing by <a href="../contact.html">contacting the judges</a>.</p>
|
||
<h2 id="guidelines-version">Guidelines version</h2>
|
||
<p><strong><code>|</code></strong> This guidelines file is version <strong>2024-06-15-v28</strong>.</p>
|
||
<p><strong>IMPORTANT</strong>: Be <strong>SURE</strong> to read the <a href="rules.html">IOCCC rules</a>.</p>
|
||
<h3 id="change-marks">Change marks</h3>
|
||
<p><strong><code>|</code></strong> <strong>← Lines that start with this symbol indicate a change from the previous IOCCC</strong></p>
|
||
<p>Most lines (we sometimes make mistakes) that were modified since the previous
|
||
IOCCC start with the <strong><code>|</code></strong> symbol.</p>
|
||
<h1 id="about-this-file">ABOUT THIS FILE:</h1>
|
||
<p>This file contains <em>guidelines</em> intended to help people who wish to
|
||
submit entries to the <a href="https://www.ioccc.org">International Obfuscated C Code Contest
|
||
(IOCCC)</a>.</p>
|
||
<p>These are not the IOCCC rules, though it does contain comments about
|
||
them. The guidelines should be viewed as <em>hints</em> and <em>suggestions</em>.
|
||
Entries that violate the guidelines but remain within the rules <em>are
|
||
allowed</em>. Even so, you are safer if you remain within the guidelines.</p>
|
||
<p>You should read the current <a href="rules.html">IOCCC rules</a>, prior to submitting entries.
|
||
The rules are typically published along with these guidelines.</p>
|
||
<h1 id="whats-new-this-ioccc">WHAT’S NEW THIS IOCCC</h1>
|
||
<p><strong><code>|</code></strong> This IOCCC runs from <strong>2024-MMM-DD HH:MM:SS UTC</strong> to <strong>YYYY-MMM-DD HH:MM:SS UTC</strong>.<br>
|
||
<strong><code>|</code></strong> <strong>XXX - date/time is TBD - XXX</strong></p>
|
||
<p><strong><code>|</code></strong> The reason for the times of day are so that key IOCCC events are <strong>calculated</strong>
|
||
for be a <strong>fun</strong>ctional UTC time. :-)</p>
|
||
<p>Until the start of this IOCCC, these rules, guidelines and iocccsize.c
|
||
(contained in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||
toolkit</a>)
|
||
tool should be considered provisional <strong>BETA</strong> versions and <strong>may be
|
||
adjusted <em>AT ANY TIME</em></strong>.</p>
|
||
<p>The IOCCC submission URL is <a href="https://submit.ioccc.org/" class="uri">https://submit.ioccc.org/</a>.</p>
|
||
<p><strong><code>|</code></strong> The submit URL should be active on or slightly before <strong>2024-MMM-DD HH:MM:SS UTC</strong>.<br>
|
||
<strong><code>|</code></strong> <strong>XXX - date/time is TBD - XXX</strong></p>
|
||
<p>Please wait to submit your entries until after that time.</p>
|
||
<p>The official rules, guidelines and iocccsize.c (invoked by the mkiocccentry)
|
||
tool will be available on the official IOCCC website on or slightly before start
|
||
of this IOCCC. Please check the IOCCC <a href="../faq.html#submit">FAQ about how to submit</a>
|
||
to see how to submit entries, on or after the start of this IOCCC, to be sure
|
||
you are using the correct versions of these items before using the IOCCC entry
|
||
submission URL.</p>
|
||
<h1 id="hints-and-suggestions">HINTS AND SUGGESTIONS:</h1>
|
||
<p>You are encouraged to examine the winners of previous contests. See
|
||
<strong>FOR MORE INFORMATION</strong> for details on how to get previous winners.</p>
|
||
<p>Keep in mind that rules change from year to year, so some winning entries
|
||
might not be valid entries this year. What <em>was</em> unique and novel one year
|
||
<em>might be ‘old’ the next year</em>.</p>
|
||
<p>An entry is usually examined in a number of ways. We typically apply
|
||
a number of tests to an entry:</p>
|
||
<ul>
|
||
<li>look at the original source</li>
|
||
<li>convert ANSI trigraphs to ASCII</li>
|
||
<li>C pre-process the source ignoring <code>#include</code> lines</li>
|
||
<li>C pre-process the source ignoring <code>#define</code> <em>and</em> <code>#include</code> lines</li>
|
||
<li>run it through a C beautifier</li>
|
||
<li>examine the algorithm</li>
|
||
<li>compile it (with flags to enable all warnings)</li>
|
||
<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
|
||
‘<em>strangest/most creative source layout</em>’ need not do as well as
|
||
others in terms of their algorithm. On the other hand, given
|
||
two such entries, we are more inclined to pick the entry that
|
||
does something interesting when you run it.</p>
|
||
<p>We try to avoid limiting creativity in our rules. As such, we leave
|
||
the contest open for creative rule interpretation. As in <a href="https://en.wikipedia.org/wiki/Real_life">real
|
||
life</a>
|
||
programming, interpreting a requirements document or a customer request
|
||
is important. For this reason, we often award ‘<em>Best abuse of the
|
||
rules</em>’ or ‘<em>Worst abuse of the rules</em>’ to an entry that illustrates this point
|
||
in an ironic way.</p>
|
||
<p>We do realize that there are holes in the rules, and invite entries
|
||
to attempt to exploit them. We will award ‘<em>Worst abuse of the rules</em>’ or
|
||
‘<em>Best abuse of the rules</em>’ and then plug the hole next year.</p>
|
||
<p><strong><code>|</code></strong> Even so, we will attempt to use the smallest plug needed, if not smaller. Or, maybe not. :-)</p>
|
||
<p><strong><code>|</code></strong> There may be less than 2^7+1 reasons why these guidelines seem obfuscated.</p>
|
||
<p>Check out your program and be sure that it works. We sometimes make
|
||
the effort to debug an entry that has a slight problem, particularly
|
||
in or near the final round. On the other hand, we have seen some
|
||
of the best entries fall down because they didn’t work.</p>
|
||
<p>We tend to look down on a <a href="https://en.wikipedia.org/wiki/Prime_number">prime
|
||
number</a> printer that claims that
|
||
16 is a prime number. If you do have a bug, you are better off
|
||
documenting it. Noting “<em>this entry sometimes prints the 4th power
|
||
of a prime by mistake</em>” would save the above entry. And sometimes,
|
||
a strange bug/feature can even help the entry! Of course, a correctly
|
||
working entry is best. Clever people will note that 16 might be prime
|
||
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 “<em>hello,
|
||
world!</em>” really really, and we do mean really, do need to be more creative.</p>
|
||
<p>Ultra-obfuscated programs are, in some cases, easier to
|
||
deobfuscate than subtly-obfuscated programs. Consider using
|
||
misleading or subtle tricks layered on top of or under an
|
||
appropriate level of obfuscation. A clean looking program with
|
||
misleading comments and variable names might be a good start.</p>
|
||
<p>When programs use VTxxx/ANSI sequences, they should NOT be limited to a
|
||
specific terminal brand. Those programs that work in a standard xterm
|
||
are considered more portable.</p>
|
||
<p><strong><code>|</code></strong> Rule 2 (the size rule) refers to the use of the IOCCC size tool called <code>iocccsize</code>.</p>
|
||
<p><strong><code>|</code></strong> See the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a> for how to compile <code>iocccsize.c</code>.</p>
|
||
<p><strong><code>|</code></strong> To further clarify rule 2, we subdivided it into two parts, 2a and 2b.</p>
|
||
<p><strong><code>|</code></strong> Your entry must satisfy BOTH the maximum size rule 2a AND your entry
|
||
must satisfy the IOCCC size tool rule 2b.</p>
|
||
<p>This tool imposes a 2nd limit on C code size (rule 2b). To check your
|
||
code against the 2nd limit of rule 2, use the -i command line option.
|
||
For example:</p>
|
||
<pre><code> ./iocccsize -i < prog.c</code></pre>
|
||
<p>The IOCCC size tool, when using the -i option, may be summarized as:</p>
|
||
<pre><code> The size tool counts most C reserved words (keyword, secondary,
|
||
and selected preprocessor keywords) as 1. The size tool counts all
|
||
other octets as 1 excluding ASCII whitespace, and excluding any
|
||
';', '{' or '}' followed by ASCII whitespace, and excluding any
|
||
';', '{' or '}' octet immediately before the end of file.</code></pre>
|
||
<p>ASCII whitespace includes ASCII tab, ASCII space, ASCII newline,
|
||
ASCII formfeed, and ASCII carriage return.</p>
|
||
<p><strong><code>|</code></strong> When ‘;’, ‘{’ or ‘}’ are within a C string, they may still not be
|
||
<strong><code>|</code></strong> counted by the IOCCC size tool. This is a feature, not a bug!</p>
|
||
<p>In cases where the above summary and the algorithm implemented by
|
||
the IOCCC size tool source code conflict, the algorithm implemented
|
||
by the IOCCC size tool source code is preferred by the judges.</p>
|
||
<p><strong><code>|</code></strong> There are at least 2 other reasons for selecting 2503 as the 2nd limit</p>
|
||
<p><strong><code>|</code></strong> besides the fact that 2503 is a prime. These reasons</p>
|
||
<p><strong><code>|</code></strong> may be searched for and discovered if you are <a href="https://t5k.org/curios/page.php/2503.html">“Curios!” about 2503</a>. :-)</p>
|
||
<p><strong><code>|</code></strong> Moreover, 2053 was the number of the kernel disk pack of one of the</p>
|
||
<p><strong><code>|</code></strong> judge’s BESM-6, and 2503 is a decimal anagram of 2053.</p>
|
||
<p>Take note that this secondary limit imposed by the IOCCC size tool
|
||
obviates some of the need to <code>#define</code> C reserved words in an effort
|
||
to get around the size limits of rule 2.</p>
|
||
<p>Yes Virginia, <strong>that is a hint</strong>!</p>
|
||
<p>We applaud programs that do not issue warnings when compiled.
|
||
To avoid warnings, you might be tempted to add various <code>-Wno-foobar</code>
|
||
flags. Unfortunately such flags are NOT portable. Moreover,
|
||
such flags are not consistent between different C compilers.
|
||
Therefore we recommend that you consider one of several approaches:</p>
|
||
<ol type="a">
|
||
<li>Write code that does not generate compiler warnings (but see <a href="../faq.html#faq3_11">the FAQ about
|
||
clang -Weverything</a>)</li>
|
||
<li>Do not use flags that disable compiler warnings</li>
|
||
<li>Provide instructions (such as in your Makefile) that
|
||
use the appropriate disable compiler warnings flags for
|
||
both clang and gcc</li>
|
||
<li>Do something creative</li>
|
||
</ol>
|
||
<h1 id="our-likes-and-dislikes">OUR LIKES AND DISLIKES:</h1>
|
||
<p>Doing masses of <code>#defines</code> to obscure the source has become ‘old’. We
|
||
tend to ‘see thru’ masses of <code>#defines</code> due to our pre-processor tests
|
||
that we apply. Simply abusing <code>#defines</code> or <code>-Dfoo=bar</code> won’t go as far
|
||
as a program that is more well rounded in confusion.</p>
|
||
<p>Many C compilers dislike the following code, and so do we:</p>
|
||
<pre><code> #define d define
|
||
#d foo /* <-- don't expect this to turn into #define foo */</code></pre>
|
||
<p>When declaring local or global variables, you should declare the type:</p>
|
||
<pre><code> int this_is_fine;
|
||
this_is_not; /* <-- Try to avoid implicit type declarations */</code></pre>
|
||
<p>We suggest that you compile your entry with a commonly available
|
||
c11 (formerly C1X) C compiler (ISO/IEC 9899:2011).</p>
|
||
<p>Do not assume that optional c11 features are supported. If you
|
||
must use an optional c11 feature, use feature test macros so
|
||
that implementations without such optional c11 features will see
|
||
an entry that is both functional and interesting.</p>
|
||
<p>We like entries that have workarounds that allow someone with
|
||
an older c99 (ISO/IEC 9899:1999) compiler to be able to compile
|
||
and enjoy your entry.</p>
|
||
<p>We really like “lint free” code. However lint is a toll of the past.
|
||
So try to ensure that your entry compiles warning free. If possible,
|
||
to compile compile your code using:</p>
|
||
<pre><code> -Wall -Wextra -pedantic</code></pre>
|
||
<p>For compilers, such as clang, that have the <code>-Weverything</code> option, try
|
||
to make your code compile warning free using:</p>
|
||
<pre><code> -Wall -Wextra -Weverything -pedantic</code></pre>
|
||
<p>.. though, again, see <a href="../faq.html#faq3_11">the FAQ about clang -Weverything</a> in
|
||
the <a href="../faq.html">FAQ</a>.</p>
|
||
<p>If you must turn off various warnings on the compile line such as:</p>
|
||
<pre><code> ... -Wno-empty-body -Wno-return-type ...</code></pre>
|
||
<p>be sure to clearly state so in your remarks <strong>AS WELL AS</strong> in
|
||
your “how to build” / Makefile.</p>
|
||
<p>All other things being equal, a program that must turn off fewer
|
||
warnings will be considered better, for certain values of better.</p>
|
||
<p>Unless you clearly state otherwise in your remarks <strong>AS WELL AS</strong> in
|
||
your “how to build” / Makefile we will compile using:</p>
|
||
<pre><code> -O3 -std=c11</code></pre>
|
||
<p>Anyone care to submit an entry that makes gratuitous use of all
|
||
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><strong>DO NOT</strong> 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_dont_submit_this() {
|
||
| printf("The machine that goes BING!!\n");
|
||
}
|
||
| please_dont_submit_this();
|
||
}</code></pre>
|
||
<p>This is because such nested functions often requires one to compile with
|
||
a flag such as <code>-fnested-functions</code> that is not found on some compilers.</p>
|
||
<p>On 2012 July 20, the judges rescinded the encouragement of
|
||
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>We prefer programs that do not require a fish license: crayons and
|
||
cat detector vans not withstanding.</p>
|
||
<p>If your entry uses functions that have a variable number of
|
||
arguments, be careful. Systems implement <code>va_list</code> as a wide variety
|
||
of ways. Because of this, a number of operations using <code>va_list</code> are
|
||
not portable and must not be used:</p>
|
||
<ul>
|
||
<li>assigning a non-<code>va_list</code> variable to/from a <code>va_list</code> variable</li>
|
||
<li>casting a non-<code>va_list</code> variable into/from a <code>va_list</code> variable</li>
|
||
<li>passing a <code>va_list</code> variable to a function expecting a non-<code>va_list</code> arg</li>
|
||
<li>passing a non-<code>va_list</code> variable to a function expecting a <code>va_list</code> arg</li>
|
||
<li>performing arithmetic on <code>va_list</code> variables</li>
|
||
<li>using <code>va_list</code> as a structure or union</li>
|
||
</ul>
|
||
<p>In particular, do not treat <code>va_list</code> variables as if they were a <code>char **</code>s.</p>
|
||
<p>Avoid using <code>varargs.h</code>. Use <code>stdarg.h</code> instead.</p>
|
||
<p>On 28 January 2007, the Judges rescinded the requirement that the
|
||
<code>#</code> in a C preprocessor directive must be the 1st non-whitespace octet.</p>
|
||
<p>The <code>exit(3)</code> function returns <code>void</code>. Some broken systems have <code>exit(3)</code>
|
||
return <code>int</code>, your entry should assume that <code>exit(3)</code> returns a <code>void</code>.</p>
|
||
<p><strong><code>|</code></strong> This guideline has a change mark at the very start of this line.</p>
|
||
<p>Small programs are best when they are short, obscure and concise.
|
||
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 <a href="https://science.nasa.gov/dwarf-planets/">dwarf
|
||
planet</a>,
|
||
(<strong>yes Virginia, dwarf planets are planets</strong>) such as
|
||
<a href="https://science.nasa.gov/dwarf-planets/pluto/">Pluto</a> might be able to
|
||
explain to the Walrus why our seas are boiling hot, the question of
|
||
whether pigs have wings is likely to remain a debatable point to most.</p>
|
||
<p>One line programs should be short one line programs: say around 80 to 120
|
||
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>that mandate the exclusive the use of an specific Integrated</li>
|
||
<li>Development Environment (IDE)</li>
|
||
</ul>
|
||
<p>In order to encourage entry portability, we dislike entries that
|
||
fail to build unless one is using an IDE. For example, do not
|
||
mandate that one must use Microsoft Visual Studio to compile
|
||
your entry. Nevertheless some of the better IDEs have command-line
|
||
interfaces to their compilers, once one learns how to invoke a shell.</p>
|
||
<p>The program must compile and link cleanly in a POSIX-like environment.
|
||
Therefore do not assume the system has a
|
||
<a href="https://en.wikipedia.org/wiki/Windows.h">windows.h</a> include file:</p>
|
||
<pre><code> #include <windows.h> /* we dislike this include */</code></pre>
|
||
<p>Unless you are cramped for space, or unless you are entering the
|
||
‘<em>Best one liner</em>’ category, we suggest that you format your program
|
||
in a more creative way than simply forming excessively long lines.</p>
|
||
<p>At least one judge prefers to maintain the use of the
|
||
<a href="https://en.wikipedia.org/wiki/Leap_second">leap-second</a>
|
||
as part of the world’s time standard. If your code prints time
|
||
with seconds, we prefer that your code be capable of printing the
|
||
time of day during a leap-second where the value in seconds
|
||
after the minute mark is 60.</p>
|
||
<p>The “<em>how to build</em>” make process should not be used to try and get
|
||
around the size limit. It is one thing to make use of a several <code>-D</code>s
|
||
on the compile line to help out, but it is quite another to use many
|
||
bytes of <code>-D</code>s in order to try and squeeze the source under the size limit.</p>
|
||
<p>Your source code, post-pre-processing, should not exceed the size of
|
||
<a href="https://en.wikipedia.org/wiki/Microsoft_Windows">Windows</a>. :-)</p>
|
||
<p>The judges, as a group, have a history giving wide degree of latitude
|
||
to reasonable entries. And recently they have had as much longitudinal
|
||
variation as it is possible to have on Earth. :-)</p>
|
||
<p>You should try to restrict commands used on the build file to
|
||
POSIX-like or common Unix-like commands. You can also compile
|
||
and use your own programs. If you do, try to build and execute
|
||
from the current directory. This restriction is not a hard and
|
||
absolute one. The intent is to ensure that the building if your
|
||
program is reasonably portable.</p>
|
||
<p>We prefer programs that are portable across a wide variety of Unix-like
|
||
operating systems (i.e., Linux, GNU Hurd, BSD, Unix, etc.).</p>
|
||
<p>You are in a maze of twisty guidelines, all different.</p>
|
||
<p>There are at least zero judges who think that Fideism has little
|
||
or nothing to do with the IOCCC judging process.</p>
|
||
<p>Don’t forget that the building of your program should be done
|
||
<strong><em>WITHOUT human intervention</em></strong>. So don’t do things such as:</p>
|
||
<pre><code> prog: prog.c
|
||
#echo this next line requires data from standard input
|
||
cat > prog.c
|
||
${CC} prog.c -o prog</code></pre>
|
||
<p>However, you can do something cute such as making your program
|
||
do something dumb (or cute) when it is built ‘automatically’, and
|
||
when it is run with a human involved, do something more clever.
|
||
For example, one could use the build instructions:</p>
|
||
<pre><code> prog: prog.c
|
||
${CC} prog.c -DNON_HUMAN_COMPILE -o prog
|
||
@echo "See remarks section about alternate ways to compile"</code></pre>
|
||
<p>and then include special notes in the program “remarks” for
|
||
alternate / human intervention based building.</p>
|
||
<p>We want to get away from source that is simply a compact blob of
|
||
octets. Really try to be more creative than blob coding. <strong>HINT!</strong></p>
|
||
<p>Please do not use things like <code>gzip(1)</code> to get around the size limit.
|
||
Please try to be much more creative.</p>
|
||
<p>We really dislike entries that make blatant use of including
|
||
large data files to get around the source code size limit.</p>
|
||
<p>We do not recommend submitting <a href="https://systemd.io">systemd</a> 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 <code>init</code> 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, <a href="../1994/smr/index.html">won in 1994</a>.</p>
|
||
<p>Programs that claim to be the smallest C source that does something, really
|
||
better be the smallest such program or they risk being rejected because
|
||
they do not work as documented.</p>
|
||
<p>Please note that the C source below, besides lacking in obfuscation,
|
||
is NOT the smallest C source file that when compiled and run, dumps core:</p>
|
||
<pre><code> main;</code></pre>
|
||
<p>We do not like writable strings. That is, we don’t want stuff like:</p>
|
||
<pre><code> char *T = "So many primes, so little time!";
|
||
...
|
||
T[14] = ';';</code></pre>
|
||
<p>Please don’t make use of this feature, even if your system allows it.
|
||
However, initialized char arrays are OK to write over. This is OK:</p>
|
||
<pre><code> char b[] = "Is this OK";
|
||
b[9] = 'K';</code></pre>
|
||
<p><strong><code>|</code></strong> There are more than 1 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 <a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>?
|
||
You do?!? (Except on Tuesday)</p>
|
||
<p>We don’t like entries that use proprietary toolkits such as the <code>M*tif</code>,
|
||
<code>Xv*ew</code>, or <code>OpenL*ok</code> toolkits, since not everyone has them. Use an
|
||
open source toolkit that is widely and freely available instead.</p>
|
||
<p><strong>NOTE</strong>: The previous guideline in this spot has been replaced by this guideline:</p>
|
||
<p>X client entries should not to depend on particular items on
|
||
<code>.Xdefaults</code>. If you must do so, be sure to note the required lines
|
||
in the program “remarks”. They should also not depend on any
|
||
particular window manager.</p>
|
||
<p>Try to avoid entries that play silent sound segments or play the
|
||
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 to favor:</p>
|
||
<p><strong><code>|</code></strong> <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a>.</p>
|
||
<p><strong><code>|</code></strong> You are <strong>well advised</strong> to submit entries that conform to the <a href="https://unix.org/version4/overview.html">Single UNIX Specification Version 4</a>.</p>
|
||
<p><strong><code>|</code></strong> You very well might not be completely be prohibited from failing to not
|
||
<strong><code>|</code></strong> 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 fully required to determine that this or the previous sentence is either false
|
||
<strong><code>|</code></strong> and/or perhaps misleading. Therefore, it might be wise for you to not fail to consider
|
||
<strong><code>|</code></strong> to do so, accordingly. Thank you very much.</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
|
||
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 <strong><== HINT!!</strong></li>
|
||
<li>make us laugh and/or throw up :-) (humor really helps!)</li>
|
||
<li>make us want to eat good chocolate.</li>
|
||
</ul>
|
||
<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 it 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 (<code>\r</code> or <code>\015</code>) that results
|
||
in compilation failures. Some non-Unix/non-Linux tools such as
|
||
MS Visual C and MS Visual C++ leave trailing control-M’s on lines.
|
||
Users of such tools should strip off such control-M’s before submitting
|
||
their entries. In some cases tools have a “Save As” option that will
|
||
prevent such trailing control-M’s being added.</p>
|
||
<p>One should restrict libcurses to portable features found on BSD
|
||
or Linux curses.</p>
|
||
<p>Rule 13 states any C source that fails to compile because of unescaped
|
||
octets with the high bit set (octet value >= 128) will be rejected.
|
||
Instead of unescaped octets, you should use or escapes:</p>
|
||
<pre><code>
|
||
/* 123456789 123456789 123456789 123456 */
|
||
char *foo = "This string is 36 octets in length \263";
|
||
/* This octet requires 4 octets of source ^^^^ */
|
||
if (strlen(foo) == 36) printf("foo is 36 octets plus a final NUL\n");
|
||
else printf("This code should not print this message\n");</code></pre>
|
||
<p>It is a very good idea to, in your remarks file, tell us why you
|
||
think your entry is obfuscated. This is particularly true if
|
||
your entry is has some very subtle obfuscations that we might
|
||
otherwise overlook. <strong><<– Hint!</strong></p>
|
||
<p>Anyone can format their code into a dense blob. A really clever
|
||
author will try format their entry using a “normal” formatting style
|
||
such that at first glance (if you squint and don’t look at the details)
|
||
the code might pass for non-obfuscated C. Deceptive comments,
|
||
and misleading formatting, in some cases, may be a plus. On the
|
||
other hand, a misleading code style requires more source bytes.</p>
|
||
<p>If you do elect to use misleading formatting and comments, we
|
||
suggest you remark on this point in your remarks where you talk
|
||
about why you think your entry is obfuscated. On the other hand,
|
||
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><strong><code>|</code></strong> The <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">IOCCC size tool source</a>
|
||
is not an original work,
|
||
unless you are Anthony C Howe, in which case it is original!
|
||
Submitting source that uses the content of iocccsize.c, unless you are
|
||
Anthony C Howe, might run the risk of violating rule 7.</p>
|
||
<p>Rule 7 does not prohibit you from writing your own obfuscated IOCCC size tool.
|
||
However if you do, you might wish to make your tool do something more
|
||
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 <a href="rules.html">rules</a> is somewhat encouraged. Legal rule abuse
|
||
may involve, but is not limited to, doing things that are technically allowed by
|
||
the <a href="rules.html">rules</a> and yet do not fit the spirit of what we intended to be
|
||
submitted.</p>
|
||
<p>Legal rule abuse is encouraged to help promote creativity. Rule abuse
|
||
entries, regardless of if they receive an award, result in changes to
|
||
the next year’s <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a>.</p>
|
||
<p>Legal abuse of the <a href="rules.html">rules</a> is NOT an invitation to violate the
|
||
<a href="rules.html">rules</a>. An entry that violates the <a href="rules.html">rules</a> in the
|
||
opinion of the judges, <strong>WILL</strong> be
|
||
disqualified. <strong><em>RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!</em></strong> If you
|
||
have an entry that might otherwise be interesting, you might want to
|
||
submit two versions; one that does not abuse the <a href="rules.html">rules</a> and one that
|
||
does.</p>
|
||
<p>If you intend to abuse the <a href="rules.html">rules</a>, indicate so in the program
|
||
“remarks”. You must try to justify why you consider your rule abuse to be
|
||
allowed under the <a href="rules.html">rules</a>. That is, you must plead your case as to
|
||
why your entry is valid. Humor and/or creativity help plead a case.</p>
|
||
<p>Abusing the web submission procedure tends to annoy us more
|
||
than amuse us. Spend your creative energy on content of your
|
||
entry rather than on the submission process itself.</p>
|
||
<p>We are often asked why the contest <a href="rules.html">rules</a> and
|
||
<a href="guidelines.html">guidelines</a> seem too
|
||
strange or contain mistakes, flaws or grammatical errors. One reason
|
||
is that we sometimes make genuine mistakes. But in many cases such
|
||
problems, flaws or areas of confusion are deliberate. Changes to
|
||
<a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a> in response to rule abuses, are done in a minimal
|
||
fashion. Often we will deliberately leave behind holes (or introduce
|
||
new ones) so that future rule abuse may continue. A cleaver author
|
||
should be able to read them and “drive a truck through the holes” in
|
||
the <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a>.</p>
|
||
<p>At the risk of stating the obvious, this contest is a parody of the software
|
||
development process. The <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a>
|
||
are only a small part of the overall contest. Even so, one may think the
|
||
contest <a href="rules.html">rules</a> and <a href="guidelines.html">guideline</a> process as a parody
|
||
of the sometimes tragic mismatch between what a customer (or marketing) wants
|
||
and what engineering delivers. Real programmers must face obfuscated and
|
||
sometimes conflicting specifications and requirements from marketing, sales,
|
||
product management an even from customers themselves on a all too regular basis.
|
||
This is one of the reasons why the <a href="rules.html">rules</a> and
|
||
<a href="guidelines.html">guidelines</a> are written in obfuscated form.</p>
|
||
<h1 id="judging-process">JUDGING PROCESS:</h1>
|
||
<p>Entries are judged by Leonid A. Broukhis and Landon Curt Noll.</p>
|
||
<p>Each entry submitted is given a random id number and subdirectory. The
|
||
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 <strong>MUST</strong> refrain from putting any information
|
||
that reveals your identity in your entry.</p>
|
||
<p>Now some people point out that coding style might reveal the information
|
||
about the others. However we consider this to be simply circumstantial
|
||
and outside the scope of the above paragraph.</p>
|
||
<p>Some people, in the past, have attempted to obfuscate their identity by
|
||
including comments of famous Internet personalities such as <a href="http://www.citi.umich.edu/u/honey">Peter
|
||
Honeyman</a>. The judges are on to this trick
|
||
and therefore consider any obfuscated source or data file claiming to be from
|
||
Honeyman to not be form Honeyman. This of course creates an interesting paradox
|
||
known as the “obfuscated Peter Honeyman paradox”. Should Peter Honeyman
|
||
actually submit an obfuscated entry, he alone is excluded from the above, as we
|
||
will likely believe it just another attempt at confusion. This guideline is
|
||
known as the “Peter Honeyman is exempt” guideline.</p>
|
||
<p>BTW: None of the entries claiming to be from Peter Honeyman have ever
|
||
won an award. So it is theoretically possible that Peter Honeyman
|
||
did submit an entry in the past. In the past, Peter had denied
|
||
submitting anything to the IOCCC. Perhaps those entries were
|
||
submitted by one of his students?</p>
|
||
<p>Hopefully we are <strong>VERY CLEAR</strong> on this point! The rules now strongly state:
|
||
<strong>PLEASE <em>DO NOT</em> put a name of an author</strong>, in an obvious way, into your
|
||
source code, remarks, data files, etc. The above “Peter Honeyman is
|
||
exempt” notwithstanding.</p>
|
||
<p>We seemed to have digressed again … :-) Returning to the judging process:</p>
|
||
<p>We prefer to be kept in the dark as much as you are until the final
|
||
awards are given. We enjoy the surprise of finding out in the end,
|
||
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 <a href="https://fosstodon.org/@ioccc">Mastodon
|
||
account</a>.</p>
|
||
<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 toot initial announcement of who won, the name
|
||
of their award, and a very brief description of the winning entry
|
||
from the <a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> Mastodon account</a>. You should
|
||
follow us on Mastodon and refresh the page (even if you do follow us) as unless
|
||
you are mentioned you will not get a notification.</p>
|
||
<h2 id="how-the-new-ioccc-winners-will-be-announced">How the new IOCCC winners will be announced</h2>
|
||
<p><strong><code>|</code></strong> The <a href="../status.html">Current status of the IOCCC</a> will change from <strong>judging</strong> to <strong>closed</strong> .</p>
|
||
<p><strong><code>|</code></strong> The <strong>contest_status</strong> in the <a href="../status.json">status.json</a> file will change from <strong>judging</strong> to <strong>closed</strong> as well.</p>
|
||
<p><strong><code>|</code></strong> When the above happens, the winning entries have been selected by the <a href="../judges.html">IOCCC judges</a>.</p>
|
||
<p><strong><code>|</code></strong> The <a href="../judges.html">IOCCC judges</a> will begin to prepare to release the source code of the new IOCCC winners.</p>
|
||
<p><strong><code>|</code></strong> The <a href="../judges.html">IOCCC judges</a> will post the winning source to the <a href="https://github.com/ioccc-src/winner">IOCCC winner repo</a> as well as to the <a href="https://www.ioccc.org/index.html">Official IOCCC winner website</a>.</p>
|
||
<p><strong><code>|</code></strong> The <a href="../news.html">IOCCC news</a> will also contain an announcement of the winners.</p>
|
||
<h2 id="an-important-update-to-how-winners-are-announced">An important update to how winners are announced</h2>
|
||
<p>The IOCCC no longer uses twitter. IOCCC entries will be announced
|
||
by a git commit to the IOCCC entries repo:</p>
|
||
<pre><code> https://github.com/ioccc-src/winner</code></pre>
|
||
<p>that, in turn, updates the official IOCCC website:</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-announcement-of-winners">Back to announcement 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><strong><code>|</code></strong> For questions or comments about the contest, see <a href="../contact.html">Contacting the IOCCC</a>.</p>
|
||
<p><strong><code>|</code></strong> Be sure to review the <a href="index.html">IOCCC Rules and Guidelines</a> as
|
||
<a href="rules.html">rules</a> and the <a href="guidelines.html">guidelines</a> may (and often do) change from year to year.</p>
|
||
<p><strong><code>|</code></strong> You should be sure you have the current <a href="rules.html">rules</a> and
|
||
<a href="guidelines.html">guidelines</a> prior to submitting entries.</p>
|
||
<p><strong><code>|</code></strong> See the <a href="../news.html">Official IOCCC website news</a> for additional information.</p>
|
||
<p><strong><code>|</code></strong> For the updates and breaking IOCCC news, you are encouraged to follow
|
||
the <a href="https://fosstodon.org/@ioccc">IOCCC on Mastodon</a> account. See our
|
||
<a href="../faq.html#try_mastodon">FAQ</a> for more information. Please be aware that
|
||
unless you are mentioned you most likely will <strong>NOT</strong> get a notification from
|
||
the app so you should make sure to check the page.</p>
|
||
<p><strong><code>|</code></strong> Check out the <a href="https://www.ioccc.org/index.html">Official IOCCC winner website</a> in general.</p>
|
||
<p>Leonid A. Broukhis<br>
|
||
chongo (Landon Curt Noll) /\cc/\</p>
|
||
<hr style="width:10%;text-align:left;margin-left:0">
|
||
<p>Jump to: <a href="#">top</a>
|
||
<!-- AFTER: last line of markdown file: next/guidelines.md --></p>
|
||
|
||
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||
<!-- START: this line starts content from: inc/after-content.default.html -->
|
||
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/after-content.default.html -->
|
||
<!-- START: this line starts content from: inc/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">
|
||
|
||
<div id="copyright"><h3>Copyright © 1984-2024 by Landon Curt Noll:
|
||
<a href="https://creativecommons.org/faq/#what-does-some-rights-reserved-mean"
|
||
target="_blank"
|
||
rel="license noopener noreferrer">Some Rights Reserved</a></h3>
|
||
<p>
|
||
This work is <b>licensed by Landon Curt Noll</b> under
|
||
<b><a href="https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1"
|
||
target="_blank"
|
||
rel="license noopener noreferrer"
|
||
style="display:inline-block;">CC BY-SA 4.0</a></b>.
|
||
<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"><br>
|
||
You should <b>carefully review</b> the
|
||
<b><a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.en"
|
||
target="_blank"
|
||
rel="license noopener noreferrer">CC BY-SA 4.0 LEGAL CODE</a></b>
|
||
before using the licensed material.<br>
|
||
You may wish to review the
|
||
<b><a href="../license.html"
|
||
target="_blank"
|
||
rel="license noopener noreferrer">highlights of some of the key features and terms</a></b>
|
||
of <b>CC BY-SA 4.0</b>.<br>
|
||
</p>
|
||
</div>
|
||
|
||
<div id="coda"><h3>Coda</h3>
|
||
<p>
|
||
<a href="https://validator.w3.org/nu/?doc=https%3A%2F%2Fioccc-src.github.io%2Ftemp-test-ioccc%2Fnext%2Fguidelines.html" rel="nofollow">Nu HTML check this web page</a><br>
|
||
<a href="#top">Jump to top</a> <a href="#content">Jump to Content</a>
|
||
</p>
|
||
</div>
|
||
|
||
</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 -->
|