The '{', '}' and other chars that are referred to are now in code blocks
(surrounded by single quotes) to help make them stand out better. The
single quotes are there as depending on the person's perception (or if
they're tired or ...) the colour difference might not be enough (in fact
it's barely enough for me at this point and others are more colour blind
than I am). The block quote colour is being experimented with still,
too, so that is another reason to have the 's.
Added make gen_next rule to Makefile which builds next/index.html from
next/README.md, next/rules.html from next/rules.md and
next/guidelines.html from next/guidelines.md. The make help rule was
updated for this.
1199 lines
65 KiB
HTML
1199 lines
65 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="ioccc-guidelines-version">IOCCC Guidelines version</h2>
|
||
<p><strong><code>|</code></strong> These <a href="guidelines.html">IOCCC guidelines</a> are version <strong>2024-06-25-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 <a href="guidelines.html">IOCCC guidelines</a> should be viewed as <em>hints</em> and <em>suggestions</em>.
|
||
Entries that violate the <em>guidelines</em> but remain within the rules <em>are
|
||
allowed</em>. Even so, you are safer if you remain within the <a href="guidelines.html">IOCCC guidelines</a>.</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 the <a href="guidelines.html">IOCCC guidelines</a>.</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, the <a href="rules.html">IOCCC rules</a>, <a href="guidelines.html">IOCCC guidelines</a> and <code>iocccsize.c</code>
|
||
(contained in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||
toolkit</a>)
|
||
tool should be considered provisional <strong>BETA</strong> versions and <strong>may be
|
||
adjusted <em>AT ANY TIME</em></strong>.</p>
|
||
<p>The IOCCC submission URL is <a href="https://submit.ioccc.org/" class="uri">https://submit.ioccc.org/</a>.</p>
|
||
<p><strong><code>|</code></strong> The submit URL should be active on or slightly before <strong>2024-MMM-DD HH:MM:SS UTC</strong>.<br>
|
||
<strong><code>|</code></strong> <strong>XXX - date/time is TBD - XXX</strong></p>
|
||
<p>Please wait to submit your entries until after that time.</p>
|
||
<p>The <a href="rules.html">IOCCC rules</a>, <a href="guidelines.html">IOCCC guidelines</a> and iocccsize.c (invoked by the mkiocccentry)
|
||
tool will be available on the official IOCCC website on or slightly before start
|
||
of this IOCCC. Please check the IOCCC <a href="../faq.html#submit">FAQ about how to submit</a>
|
||
to see how to submit entries, on or after the start of this IOCCC, to be sure
|
||
you are using the correct versions of these items before using the IOCCC entry
|
||
submission URL.</p>
|
||
<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 <a href="guidelines.html">IOCCC guidelines</a> seem obfuscated.</p>
|
||
<p>Check out your program and be sure that it works. We sometimes make
|
||
the effort to debug an entry that has a slight problem, particularly
|
||
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> <a href="rules.html#rule2">Rule 2</a> (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 the <code>iocccsize</code> tool.</p>
|
||
<p><strong><code>|</code></strong> To further clarify <a href="rules.html#rule2">Rule 2</a>, we subdivided it into two parts, 2a and 2b.</p>
|
||
<p><strong><code>|</code></strong> The overall size limit (see <a href="rules.html#rule2a">Rule 2a</a>) on <code>prog.c</code> is now 4993 bytes</p>
|
||
<p><strong><code>|</code></strong> Your entry must satisfy BOTH the maximum size <a href="rules.html#rule2a">Rule 2a</a> AND your entry
|
||
must satisfy the IOCCC size tool <a href="rules.html#rule2b">Rule 2b</a>.</p>
|
||
<p>This tool imposes a 2nd limit on C code size (see <a href="rules.html#rule2a">Rule 2a</a>. To check your
|
||
code against the 2nd limit of <a href="rules.html#rule2">Rule 2</a>, use the -i command line option.
|
||
For example:</p>
|
||
<pre><code> ./iocccsize -i < prog.c</code></pre>
|
||
<p>The IOCCC size tool, when using the -i option, may be summarized as:</p>
|
||
<blockquote>
|
||
<p>The size tool counts most C reserved words (keyword, secondary,<br>
|
||
and selected preprocessor keywords) as 1. The size tool counts all<br>
|
||
other octets as 1 excluding ASCII whitespace, and excluding any<br>
|
||
‘<code>;</code>’, ‘<code>{</code>’ or ‘<code>}</code>’ followed by ASCII whitespace, and excluding any<br>
|
||
‘<code>;</code>’, ‘<code>{</code>’ or ‘<code>}</code>’ octet immediately before the end of file.</p>
|
||
</blockquote>
|
||
<p>ASCII whitespace includes ASCII tab, ASCII space, ASCII newline,
|
||
ASCII formfeed, and ASCII carriage return.</p>
|
||
<p><strong><code>|</code></strong> When ‘<code>;</code>’, ‘<code>{</code>’ or ‘<code>}</code>’ 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 <a href="rules.html#rule2">Rule 2</a>.</p>
|
||
<p>Yes Virginia, <strong>that is a hint</strong>!</p>
|
||
<p><strong><code>|</code></strong> The <a href="rules.html#rule2a">Rule 2a</a> size was changed from 4096 to 4993: a change that keeps the “2b to 2a” size ratio to a value similar to the <a href="../faq.html#size_rule">2001-2020 IOCCC era</a>.</p>
|
||
<p>We applaud programs that do not issue warnings when compiled.
|
||
To avoid warnings, you might be tempted to add various <code>-Wno-foobar</code>
|
||
flags. Unfortunately such flags are NOT portable. Moreover,
|
||
such flags are not consistent between different C compilers.
|
||
Therefore we recommend that you consider one of several approaches:</p>
|
||
<ol type="a">
|
||
<li>Write code that does not generate compiler warnings (but see <a href="../faq.html#faq3_11">the FAQ about
|
||
clang -Weverything</a>)</li>
|
||
<li>Do not use flags that disable compiler warnings</li>
|
||
<li>Provide instructions (such as in your Makefile) that
|
||
use the appropriate disable compiler warnings flags for
|
||
both clang and gcc</li>
|
||
<li>Do something creative</li>
|
||
</ol>
|
||
<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 <em>guideline</em> has a change mark at the very start of this line.</p>
|
||
<p>Small programs are best when they are short, obscure and concise.
|
||
While such programs are not as complex as other winners, they do
|
||
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 <em>guidelines</em>, 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 <a href="rules.html">IOCCC rules</a> for details.</p>
|
||
<p>We suggest that you avoid trying for the ‘smallest self-replicating’
|
||
source. The smallest, a zero byte entry, <a href="../1994/smr/index.html">won in 1994</a>.</p>
|
||
<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 <em>guideline</em> that contains the word fizzbin.</p>
|
||
<p><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><strong><code>|</code></strong> OK, there are actually 3 <em>guidelines</em> that contain the word fizzbin.</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 <em>guideline</em> in this spot has been replaced by this <em>guideline</em>:</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 <em>guideline</em>, 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 <em>guideline</em> 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 <em>guideline</em>, 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><a href="rules.html#rule13">Rule 13</a> 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 motto 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 <a href="rules.html#rule7">Rule 7</a>.</p>
|
||
<p><a href="rules.html#rule7">Rule 7</a> 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">IOCCC 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">IOCCC 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">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</a>.</p>
|
||
<p>Legal abuse of the <a href="rules.html">IOCCC rules</a> is NOT an invitation to violate the
|
||
<a href="rules.html">IOCCC rules</a>. An entry that violates the <a href="rules.html">rules</a> in the
|
||
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">IOCCC rules</a> and one that
|
||
does.</p>
|
||
<p>If you intend to abuse the <a href="rules.html">IOCCC 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">IOCCC rules</a>. That is, you must plead your case as to
|
||
why your entry is valid. Humor and/or creativity help plead a case.</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">IOCCC rules</a> and
|
||
<a href="guidelines.html">IOCCC 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">IOCCC rules</a> and <a href="guidelines.html">IOCCC 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">IOCCC rules</a> and <a href="guidelines.html">IOCCC 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">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</a>
|
||
are only a small part of the overall contest. Even so, one may think the
|
||
contest <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</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">IOCCC rules</a> and
|
||
<a href="guidelines.html">IOCCC guidelines</a> are written in obfuscated form.</p>
|
||
<h1 id="judging-process">JUDGING PROCESS:</h1>
|
||
<p>Entries are judged by Leonid A. Broukhis and Landon Curt Noll.</p>
|
||
<p>Each entry submitted is given a random id number and subdirectory. The
|
||
entry files including, but not limited to prog.c, Makefile (that we
|
||
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 <em>guideline</em> is
|
||
known as the “Peter Honeyman is exempt” <em>guideline</em>.</p>
|
||
<p>BTW: None of the entries claiming to be from Peter Honeyman have ever
|
||
won an award. So it is theoretically possible that Peter Honeyman
|
||
did submit an entry in the past. In the past, Peter had denied
|
||
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 <em>guideline</em> that goes, BING!</p>
|
||
<p>Until we reduce the stack of entries down to about 25 entries, entries
|
||
are judged on an individual basis. An entry is set aside because it
|
||
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 <a href="guidelines.html">IOCCC guidelines</a> in an interesting way,
|
||
or that stretches the content rules that while legal, is
|
||
nevertheless goes against the intent of the rules.</p>
|
||
<p>In the end, we traditionally pick one entry as ‘best’. Sometimes such
|
||
an entry simply far exceeds any of the other entries. More often, the
|
||
‘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 the
|
||
<a href="rules.html">IOCCC rules</a> and the <a href="guidelines.html">IOCCC 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">IOCCC rules</a> and
|
||
<a href="guidelines.html">IOCCC 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 -->
|