Files
ioccc/next/guidelines.html
T

2392 lines
115 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<!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 authors
</a>
</div>
<div class="outfit-font">
<a href="../bugs.html" class="sub-item-link">
Bugs and (mis)features
</a>
</div>
<div class="outfit-font">
<a href="../faq.html#fix_an_entry" class="sub-item-link">
Fixing entries
</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">
Status
</span>
<div class="sub-item">
<div class="outfit-font">
<a href="../news.html" class="sub-item-link">
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 class="outfit-font">
<a href="../markdown.html" class="sub-item-link">
Markdown guidelines
</a>
</div>
<div class="outfit-font">
<a href="../SECURITY.html" class="sub-item-link">
Security policy
</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">
Frequently Asked Questions
</a>
</div>
<div class="outfit-font">
<a href="../quick-start.html#enter" class="sub-item-link">
Enter the IOCCC
</a>
</div>
<div class="outfit-font">
<a href="../faq.html#compiling" class="sub-item-link">
Compiling entries
</a>
</div>
<div class="outfit-font">
<a href="../faq.html#running_entries" class="sub-item-link">
Running entries
</a>
</div>
<div class="outfit-font">
<a href="../faq.html#help" class="sub-item-link">
How to help
</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">
Home page
</a>
</div>
<div class="outfit-font">
<a href="../about.html" class="sub-item-link">
About the IOCCC
</a>
</div>
<div class="outfit-font">
<a href="../judges.html" class="sub-item-link">
The Judges
</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="../contact.html" class="sub-item-link">
Contact us
</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">
Winning authors
</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>
<a class="mobile-submenu-item" href="../faq.html#fix_an_entry">
Fixing entries
</a>
<a class="mobile-submenu-item" href="../faq.html#fix_author">
Updating author info
</a>
<a class="mobile-submenu-item" href="../thanks-for-help.html">
Thanks for the help
</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="../news.html">
News
</a>
<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="../markdown.html">
Markdown guidelines
</a>
<a class="mobile-submenu-item" href="../SECURITY.html">
Security policy
</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="../quick-start.html#enter">
Enter the IOCCC
</a>
<a class="mobile-submenu-item" href="../faq.html#compiling">
Compiling entries
</a>
<a class="mobile-submenu-item" href="../faq.html#running_entries">
Running entries
</a>
<a class="mobile-submenu-item" href="../faq.html#help">
How to help
</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">
Home page
</a>
<a class="mobile-submenu-item" href="../about.html">
About the IOCCC
</a>
<a class="mobile-submenu-item" href="../judges.html">
The Judges
</a>
<a class="mobile-submenu-item" href="../contact.html">
Contact us
</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%2Fwww.ioccc.org%2Fnext%2Fguidelines.html">&#x2713;</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 -->
<!-- START: this line starts content from: inc/guidelines.pending.hdr -->
<h1 id="warning-these-guidelines-are-tentative">WARNING: These guidelines are TENTATIVE</h1>
<p>One might think of them as a <strong>beta</strong> release for the IOCCC
that is about to open.</p>
<p><strong>IMPORTANT</strong>: All <strong>tentative</strong> <a href="rules.html">rules</a> and <a href="guidelines.html">guidelines</a>
are subject to change by the <a href="../judges.html">IOCCC judges</a> at any time.
See both the <a href="../news.html">IOCCC news</a> and the <a href="https://fosstodon.org/@ioccc">IOCCC
Mastodon</a> feed as <em>sometimes</em> the
<a href="../judges.html">IOCCC judges</a> <em>mention</em> changes there.</p>
<p>See our
FAQ on “<a href="../faq.html#feedback">rules, guidelines, tools feedback</a>”
as well as our
FAQ on “<a href="../faq.html#question">about asking questions</a>”
about these guidelines. You might also find the FAQ in general useful, especially the
FAQ on “<a href="../quick-start.html#enter">how to enter the IOCCC</a>”.</p>
<h1 id="the-ioccc-is-pending">The IOCCC is pending</h1>
<p>While the IOCCC is not open yet, there is a tentative opening date for the next IOCCC.</p>
<p>Comments and suggestions on these preliminary guidelines are welcome. See the
<a href="../faq.html#feedback">FAQ</a> for how to suggest, correct or provide feedback
about these guidelines.</p>
<!-- END: the next line ends content from: inc/guidelines.pending.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 class="leftbar">
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>
<p>Jump to: <a href="#">top</a></p>
<div id="guidelines_version">
<div id="version">
<h1 id="ioccc-guidelines-version">IOCCC Guidelines version</h1>
</div>
</div>
<p class="leftbar">
These <a href="guidelines.html">IOCCC guidelines</a> are version <strong>28.33 2025-01-23</strong>.
</p>
<p class="leftbar">
The <a href="guidelines.md" download="guidelines.md">markdown form of these guidelines</a>
is available for download.
</p>
<p><strong>IMPORTANT</strong>: Be <strong>SURE</strong> to read the <a href="rules.html">IOCCC rules</a>.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="change_marks">
<h1 id="change-marks">Change marks</h1>
</div>
<p class="leftbar">
<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 a solid 4 pixel black left border (or, in the case of a code
block or blockquote, just a vertical bar).</p>
<p>Jump to: <a href="#">top</a></p>
<div id="about_guidelines">
<h1 id="about-this-file">ABOUT THIS FILE:</h1>
</div>
<p>This file contains <em>guidelines</em> intended to help people who wish to
participate in the <a href="https://www.ioccc.org">International Obfuscated C Code Contest
(IOCCC)</a>.</p>
<p>These are <strong>NOT the <a href="rules.html">IOCCC rules</a></strong>, though it does contain comments
about them. The <a href="guidelines.html">IOCCC guidelines</a> should be viewed as
<strong>hints</strong> and <strong>suggestions</strong>. <strong>Entries that violate the
<a href="guidelines.html">guidelines</a> <em>but remain within the <a href="rules.html">rules</a></em></strong> <em>are
allowed</em>. Even so, you are safer if you remain within the <a href="guidelines.html">IOCCC
guidelines</a>.</p>
<p><strong>You should read the current <a href="rules.html">IOCCC rules</a>, prior to submitting
entries</strong>. The <a href="rules.html">rules</a> are typically published along with the <a href="guidelines.html">IOCCC
guidelines</a>..</p>
<p>Jump to: <a href="#">top</a></p>
<div id="new">
<h1 id="whats-new-this-ioccc">WHAT’S NEW THIS IOCCC</h1>
</div>
<p class="leftbar">
This IOCCC runs from <strong>2024-12-29 23:58:13.213455 UTC</strong> to <strong>2025-04-01 23:29:31.374143 UTC</strong>.
</p>
<p class="leftbar">
This contest will enter the <strong><a href="../status.html#pending">pending</a></strong> state on or about
<strong>2024-12-29 23:58:13.213455 UTC</strong>.
</p>
<p class="leftbar">
This contest will enter the <strong><a href="../status.html#open">open</a></strong> state on <strong>2025-01-31 23:19:17.130705 UTC</strong>.
</p>
<p class="leftbar">
This contest will enter the <strong><a href="../status.html#judging">judging</a></strong> state on <strong>2025-04-01 23:29:31.374143 UTC</strong>.
</p>
<p class="leftbar">
<strong>IMPORTANT NOTE</strong>: Until the content enters the <strong><a href="../status.html#open">open</a></strong> state, any or all
of the above <strong>dates and times may change</strong>!
</p>
<p class="leftbar">
The reason for the times of day are so that key IOCCC events are <strong>calculated</strong>
to be a <strong>fun</strong>ctional UTC time. :-)
</p>
<p class="leftbar">
Until the contest status becomes <strong><a href="../status.html#open">open</a></strong>,
the <a href="rules.html">IOCCC rules</a>,
<a href="guidelines.html">IOCCC guidelines</a> and the tools in the
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>, should be
considered provisional <strong>BETA</strong> versions and <strong>may be adjusted <em>AT ANY TIME</em></strong>
before the contest status becomes <strong><a href="../status.html#open">open</a></strong>.
</p>
<p class="leftbar">
You <strong>MUST</strong> <a href="register.html">register</a> in order to submit your entry to the IOCCC.
You may <a href="register.html">register</a> while the contest is either
<strong><a href="../status.html#pending">pending</a></strong> or <strong><a href="../status.html#open">open</a></strong>.
</p>
<p class="leftbar">
See the
FAQ on “<a href="../quick-start.html#enter">how to register and submit to the IOCCC</a>”
for instructions on registering and participating in the IOCCC, as the process has changed from previous years!
</p>
<p class="leftbar">
When the contest is <strong><a href="../status.html#open">open</a></strong>, an
<a href="../judges.html">IOCCC judge</a> will email you your <a href="https://submit.ioccc.org">submit server</a>
<strong>Username</strong> and <strong>Initial password</strong>. This takes some time (maybe even a few days) for an
<a href="../judges.html">IOCCC judge</a> to process your registration and email you your
initial login and password.
</p>
<p class="leftbar">
Those who <a href="register.html">register</a> while the contest status is <strong><a href="../status.html#pending">pending</a></strong>
will receive email with their <a href="https://submit.ioccc.org">submit server</a> <strong>Username</strong> and <strong>Initial password</strong>
from an <a href="../judges.html">IOCCC judge</a> shortly after the contest status becomes <strong><a href="../status.html#open">open</a></strong>.
</p>
<p class="leftbar">
Once an <a href="../judges.html">IOCCC judge</a> emails you your <strong>Username</strong> and <strong>Initial password</strong>, you
will have 72 hours to <a href="pw-change.html">change your submit server initial password</a>.
If you do not change your <strong>Initial password</strong> in time, you will have to <a href="register.html">re-register</a>.
</p>
<p class="leftbar">
Because it takes time (maybe even a few days) for an <a href="../judges.html">IOCCC judge</a>
to process your registration and email you your initial login and password,
you should <strong>MAKE SURE</strong> you give yourself enough time before the contest closes.
In other words, <strong>DO NOT WAIT TO REGISTER UNTIL THE FINAL DAYS</strong>!
The <a href="../judges.html">IOCCC judges</a> are <strong>NOT</strong> responsible for delayed or lost email,
or for those who wait until the last minute to try to register!
</p>
<p class="leftbar">
For those who have <a href="register.html">registered</a> and received by email, their
<a href="https://submit.ioccc.org">submit server</a> <strong>Username</strong> and <strong>Initial password</strong>
from an <a href="../judges.html">IOCCC judge</a>, you may upload your submission to
the <a href="https://submit.ioccc.org">submit server</a> only while the
contest <strong><a href="../status.html#open">open</a></strong>.
</p>
<p class="leftbar">
The <a href="https://submit.ioccc.org">submit server</a>, in accordance with <a href="rules.html#rule17">Rule 17</a>,
places a limit of <strong>3999971</strong> octets on the size of your upload.
</p>
<p class="leftbar">
You are <strong>STRONGLY</strong> advised to use the <code>mkiocccentry(1)</code> tool
as found in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>
to form the file to upload to the <a href="https://submit.ioccc.org">submit server</a>.
</p>
<p class="leftbar">
See the
FAQ on “<a href="../faq.html#mkiocccentry">obtaining and compiling the mkiocccentry tools</a>”
for more information about the <code>mkiocccentry(1)</code> tool.
</p>
<p class="leftbar">
While the contest is <strong><a href="../status.html#open">open</a></strong>, you may modify your previously
uploaded submission by rebuilding your submission with the <code>mkiocccentry(1)</code> tool
and then re-uploading it to the same slot number on the <a href="https://submit.ioccc.org">submit server</a>.
</p>
<p class="leftbar">
To help you with this, so that you do not have to repeatedly answer all the
questions, the <code>mkiocccentry(1)</code> tool has the options <code>-a answers</code>, <code>-A answers</code>
and <code>-i answers</code>, where <code>-a</code> will write to an answers file if it does not
already exist, <code>-A</code> will overwrite the file and <code>-i</code> will read the answers from
the file.
</p>
<p class="leftbar">
Once the contest enters the <strong><a href="../status.html#judging">judging</a></strong> state, you will
<strong>NOT</strong> be allowed to upload your submission files.
</p>
<p class="leftbar">
The <a href="https://submit.ioccc.org">submit server</a> will become active when the contest is <strong><a href="../status.html#open">open</a></strong>.
Until the contest status becomes <strong><a href="../status.html#open">open</a></strong>,
the <a href="https://submit.ioccc.org">submit server</a> may be offline and/or unresponsive.
</p>
<p class="leftbar">
The <a href="rules.html#rule2a">Rule 2a</a> size has <strong>increased from 4096 to 4993</strong> bytes.
</p>
<p class="leftbar">
The <a href="rules.html#rule2b">Rule 2b</a> size has <strong>increased from 2053 to 2503</strong>
bytes.
</p>
<p class="leftbar">
The new default way to compile submissions: <code>-std=gnu17 -O3 -g3 -Wall -Wextra -pedantic</code>.
You <strong>are encouraged</strong> to use the example Makefile here. For more details and help,
see below in the <a href="#makefile">Makefile section</a>.
</p>
<p class="leftbar">
Submissions are uploaded as a single xz compressed tarball.
</p>
<p class="leftbar">
To assist in the formation of the xz compressed tarball for submission, use the
<code>mkiocccentry(1)</code> tool as found in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>.
</p>
<p class="leftbar">
<a href="rules.html#rule17">Rule 17</a> has been <strong>significantly modified</strong>
to account for the new <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a> tools.
</p>
<p class="leftbar">
If you wish to test that your submission passes the <code>mkiocccentry(1)</code> tests
without having to put in answers each time, you can use the <code>-d</code> or <code>-s seed</code>
option to <code>mkiocccentry</code> for the tool to pseudo-randomly create answers for you.
The <code>-d</code> option is an alias for <code>-s 21701</code>. An example use:
</p>
<pre><code> mkiocccentry -d test_work prog.c Makefile remarks.md</code></pre>
<p class="leftbar">
where <code>test_work</code> is the directory which the tarball will be formed. Be aware
that if the directory exists already, you will have to remove it or move it
before this option will work a second time, just like in normal mode.
</p>
<p class="leftbar">
See the
FAQ on “<a href="../faq.html#mkiocccentry">obtaining and compiling the mkiocccentry tools</a>”
and the
FAQ on “<a href="../quick-start.html#enter">how to enter the IOCCC</a>”
as that FAQ has import details on
<a href="register.html">how to register</a>
as well as
<a href="submit.html">how to upload your submission</a> to the IOCCC.
</p>
<p>Jump to: <a href="#">top</a></p>
<div id="hints">
<div id="suggestions">
<h1 id="hints-and-suggestions">HINTS AND SUGGESTIONS:</h1>
</div>
</div>
<p>You are encouraged to examine the <a href="../years.html">winners of previous contests</a>.</p>
<p>Keep in mind that <a href="rules.html">rules</a> change from year to year, so some <a href="../years.html">winning
entries</a> might not be valid submissions this year; what <em>was</em> unique
and novel one year <em>might be ‘old’ the next year</em>.</p>
<p>A submission is usually examined in a number of ways. We typically apply
a number of tests to a submission:</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 submission looks in each of the above tests.
You should ask yourself if your submission remains obscure after it has been
‘<em>cleaned up</em>’ by the C pre-processor and a C beautifier.</p>
<p>Your submission need not pass all of the above tests. In certain
cases, a test is not important. Entries that compete for the
‘<strong>strangest/most creative source layout</strong>’ 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 submission that
does something interesting when you run it.</p>
<p>We try to avoid limiting creativity in our <a href="rules.html">rules</a>. 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 ‘<strong>Best abuse of the <a href="rules.html">rules</a></strong>’ or ‘<strong>Worst abuse of the
<a href="rules.html">rules</a></strong>’ or some variation to a submission that illustrates this
point in an ironic way.</p>
<p>We do realize that there are holes in the <a href="rules.html">rules</a>, and invite
entries to attempt to exploit them. We will award ‘<strong>Worst abuse of the
<a href="rules.html">rules</a></strong>’ or ‘<strong>Best abuse of the <a href="rules.html">rules</a></strong>’ or some
variation and then plug the hole next year.</p>
<p class="leftbar">
When we do need to plug a hole in the <a href="rules.html">IOCCC rules</a> or <a href="guidelines.html">IOCCC
guidelines</a>, we will attempt to use a very small plug, if not
smaller. Or, maybe not. :-)
</p>
<p class="leftbar">
There may be fewer 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 a submission 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 class="leftbar">
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 submission sometimes prints the 4th power
of a prime by mistake</em>” would save the above submission. And sometimes,
a strange bug/feature can even help the submission! Of course, a correctly
working submission 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 submission’s <code>remarks.md</code> 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>” <strong>really really, <em>and we do mean REALLY</em>, do need to be more creative</strong>.</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 class="leftbar">
<a href="rules.html#rule2">Rule 2</a> (the size rule) refers to the use of the IOCCC size
tool called <code>iocccsize(1)</code>.
</p>
<p class="leftbar">
See the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
repo</a> for the <code>iocccsize(1)</code> tool.
</p>
<p class="leftbar">
To further clarify <a href="rules.html#rule2">Rule 2</a>, we subdivided it into two parts,
<strong>2a</strong> and <strong>2b</strong>.
</p>
<p class="leftbar">
The overall size limit (see <a href="rules.html#rule2a">Rule 2a</a>) on <code>prog.c</code> is now <strong>4993 bytes</strong>.
</p>
<p class="leftbar">
Your submission must satisfy BOTH the maximum size <a href="rules.html#rule2a">Rule
2a</a> <strong>AND</strong> the IOCCC size tool <a href="rules.html#rule2b">Rule 2b</a>.
</p>
<p class="leftbar">
This IOCCC size tool imposes a 2nd limit on C code size (see <a href="rules.html#rule2a">Rule
2a</a>). To check your code against <a href="rules.html#rule2">Rule 2</a>:
</p>
<pre><code> iocccsize prog.c</code></pre>
<p>The IOCCC size tool algorithm may be summarized as follows:</p>
<blockquote>
<p>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 ‘<code>;</code>’, ‘<code>{</code>’ or ‘<code>}</code>’ followed by
ASCII whitespace, and excluding any ‘<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 class="leftbar">
When ‘<code>;</code>’, ‘<code>{</code>’ or ‘<code>}</code>’ are within a C string, they may still not be
counted by the IOCCC size tool. This is a <em>feature</em>, 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 <a href="../judges.html">judges</a>.</p>
<p class="leftbar">
There are at least 2 other reasons for selecting 2503 as the 2nd limit besides
the fact that 2503 is a prime. These reasons may be searched for and discovered
if you are <a href="https://t5k.org/curios/page.php/2503.html">“Curios!” about 2503</a>.
:-) Moreover, 2053 was the number of the kernel disk pack of one of the judge’s
BESM-6, and 2503 is a decimal anagram of 2053.
</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 class="leftbar">
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_rule2001-2012">2001-2012</a> and
<a href="../faq.html#size_rule2013-2020">2013-2020</a> IOCCC eras.
</p>
<p>Jump to: <a href="#">top</a></p>
<div id="extra-files">
<h1 id="including-extra-files">Including extra files</h1>
</div>
<p class="leftbar">
The maximum total number of files that may be submitted has changed to 39 files.
However, of those files, 5 are mandatory (<code>prog.c</code>, <code>Makefile</code>, <code>remarks.md</code> and
the two JSON files generated by <code>mkiocccentry(1)</code>, <code>.info.json</code> and
<code>.auth.json</code>). Additionally, three of the files in the limit <strong>MUST</strong> be
specific file(name)s: the <strong>OPTIONAL</strong> submission files, which are <code>prog.alt.c</code>,
<code>try.sh</code> and <code>try.alt.sh</code>, or else they <strong>WILL</strong> count as an extra file.
</p>
<p class="leftbar">
In other words, the actual amount of <strong>EXTRA</strong> files is 31.
</p>
<p class="leftbar">
If you do need to include more files, you may do so by including as an extra
file, a tarball. This does <strong>NOT</strong> have to pass <code>txzchk(1)</code> tests; only the
submission tarball must pass the <code>txzchk(1)</code> tests.
<p class="leftbar">
<p class="leftbar">
<p>See <a href="rules.html#rule17">Rule 17</a> and in particular the part about the <a href="rules.html#max-files">maximum
number of files</a>. If you do not follow these points, you
are at a great risk of violating <a href="rules.html#rule17">Rule 17</a>!</p>
<p class="leftbar">
<p>For more details, see the
FAQ on the “<a href="../faq.html#try">try.sh script system</a>”,
the
FAQ on “<a href="../faq.html#auth_json">.auth.json</a>”,
the
FAQ on “<a href="../faq.html#info_json">.info.json</a>”,</p>
<h1 id="mkiocccentry"><code>mkiocccentry</code></h1>
<p class="leftbar">
<a href="rules.html#rule17">Rule 17</a> (the <code>mkiocccentry(1)</code> rule) states that
you <strong>MUST</strong> use the <code>mkiocccentry(1)</code> tool to package your submission tarball.
</p>
<p class="leftbar">
See the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>
for the <code>mkiocccentry(1)</code> tool and below for more details.
</p>
<p class="leftbar">
<p><strong>IMPORTANT NOTE</strong>: make <strong>CERTAIN</strong> you have the most recent version of the
<code>mkiocccentry</code> toolkit! See the
FAQ on “<a href="../faq.html#obtaining_mkiocccentry">obtaining the mkiocccentry toolkit</a>”.</p>
<p class="leftbar">
<code>mkiocccentry</code> runs a number of checks, by the tool itself and by executing
other tools, <em>before</em> packaging your xz compressed tarball. Once the tarball is
packaged it will run <code>txzchk(1)</code>, which will also run <code>fnamchk(1)</code>, as part of
its algorithm.
</p>
<p class="leftbar">
If <code>mkiocccentry</code> encounters an <strong>error</strong> the program will exit and the xz
compressed tarball <strong>will not be formed</strong>. For instance, if <code>chkentry(1)</code> (see
below) fails to validate the <code>.auth.json</code> or <code>.info.json</code>
<a href="https://www.json.org/json-en.html">JSON</a> files that <code>mkiocccentry(1)</code> creates,
it is an error and <strong>possibly</strong> a bug that you should <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report as a bug at the
mkiocccentry bug report
page</a>.
<strong>PLEASE run the <code>bug_report.sh</code> script to help us out here!</strong> See the
FAQ on “<a href="../faq.html#mkiocccentry_bugs">reporting mkiocccentry bugs</a>”.
</p>
<p class="leftbar">
However, even if <code>mkiocccentry</code> or one of the tools it invokes reports an error,
it <strong>does not</strong> necessarily mean it is a bug in the code. It might be an issue with
your submission. Thus if you report an error as a bug it might not be something
that will be fixed as there might not be anything wrong with the tools.
</p>
<p class="leftbar">
On the other hand, some conditions are <strong>warnings</strong> and it allows you to
override these, if you wish. If you’re brave enough you can use the <code>-W</code> option
to ignore all warnings but this is a big risk; the <code>-y</code> option will assume
‘<em>yes</em>’ to most questions but this is also a big risk. Needless to say, we do
NOT recommend these options.
</p>
<p class="leftbar">
In many places it will prompt you to verify what you input, allowing you to
correct details as you go along.
</p>
<p>Jump to: <a href="#">top</a></p>
<div id="mkiocccentry-synopsis">
<h2 id="mkiocccentry1-synopsis"><code>mkiocccentry(1)</code> synopsis</h2>
</div>
<p class="leftbar">
The synopsis of the <code>mkiocccentry(1)</code> tool is:
</p>
<pre><code> mkiocccentry [options] work_dir prog.c \
Makefile remarks.md [file ...]</code></pre>
<p class="leftbar">
To help you with editing a submission, the <code>mkiocccentry(1)</code> tool has
some options to write <em>OR</em> read from an answers file so you do not have to input
the information about the author(s) and the submission more than once (unless of
course you need to make some changes, in which case you can use the option that
overwrites the file).
</p>
<p class="leftbar">
See the
FAQ on “<a href="../faq.html#mkiocccentry">mkiocccentry</a>”
for how to use this tool, in more detail.
</p>
<div id="tools">
<h1 id="mkiocccentry-tools">mkiocccentry tools</h1>
</div>
<p class="leftbar">
The <code>mkiocccentry(1)</code> tool will execute a number of tools, some of which will
execute one or more additional tools.
</p>
<h2 id="iocccsize"><code>iocccsize</code></h2>
<p class="leftbar">
<code>mkiocccentry(1)</code> will use code from <code>iocccsize(1)</code> which
detects a number of issues that you may ignore, if you wish, as described above.
</p>
<p class="leftbar">
In other words, you no longer need to run <code>iocccsize</code> manually.
</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="chkentry"><code>chkentry</code></h2>
<p class="leftbar">
<code>mkiocccentry(1)</code> will write two JSON files: <code>.auth.json</code> and
<code>.info.json</code>. These files contain information about the author(s) and about the
submission. These files <strong>MUST</strong> pass the checks of <code>chkentry(1)</code>!
</p>
<p class="leftbar">
If <code>chkentry</code> does not pass and you used <code>mkiocccentry(1)</code> it is <strong>very likely</strong> a
bug and you should <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the mkiocccentry issues
page</a>.
See the
FAQ on “<a href="../faq.html#mkiocccentry_bugs">reporting mkiocccentry bugs</a>”.
</p>
<p class="leftbar">
Assuming that <code>chkentry(1)</code> successfully validates both <code>.auth.json</code> and
<code>.info.json</code>, then the tarball will be formed and then <code>txzchk(1)</code> will be
executed on it. In this case, there should be no problems, as <code>mkiocccentry(1)</code> should
<strong>NOT</strong> form a tarball if there are any issues.
</p>
<p class="leftbar">
If <code>mkiocccentry(1)</code> is used and <code>chkentry(1)</code> fails to validate either of the
files, then unless it is a system specific problem, it is likely a bug in
<code>mkiocccentry(1)</code>, <code>chkentry(1)</code> or possibly <code>jparse</code>, though this is quite
unlikely.
</p>
<p class="leftbar">
If you want to know what <code>.auth.json</code> is, see the
FAQ on “<a href="../faq.html#auth_json">.auth.json</a>”.
If you want to know what the <code>.info.json</code> file is, see the
FAQ on “<a href="../faq.html#info_json">.info.json</a>”.
On the other hand, if you want to know a bit more details about <code>chkentry</code>, see the
FAQ about “<a href="../faq.html#chkentry">chkentry</a>”.
</p>
<p class="leftbar">
<code>chkentry</code> uses the <code>jparse</code> library. See the
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/README.md">jparse
README.md</a>
in the <a href="https://github.com/ioccc-src/mkiocccentry/tree/master/jparse">mkiocccentry GitHub repo subdirectory
jparse</a> as well as
the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jparse_library_README.md">jparse library README.md
file</a>
in the <a href="https://github.com/ioccc-src/mkiocccentry/tree/master/jparse">mkiocccentry GitHub repo subdirectory
jparse</a>, for more
details.
</p>
<p class="leftbar">
The <code>jparse</code> parser, library and tools were co-developed by
<a href="../authors.html#Cody_Boone_Ferguson">Cody Boone Ferguson</a> and
<a href="http://www.isthe.com/chongo/index.html">Landon Curt Noll</a> in 2022 and come
from the <a href="https://github.com/xexyl/jparse">jparse repo</a>. However, the
<strong>mkiocccentry tools use a <em>clone</em></strong> of the <a href="https://github.com/xexyl/jparse">jparse
repo</a> <strong>at a <em>specific</em> release</strong>.
Thus the <code>mkiocccentry</code> will at times be behind the
<a href="https://github.com/xexyl/jparse">jparse repo</a>!
</p>
<p class="leftbar">
You do <strong>NOT need to install</strong> <code>jparse</code> from the <a href="https://github.com/xexyl/jparse">jparse
repo</a>! The <code>mkiocccentry</code> tools link in the
static library from the <code>mkiocccentry</code>’s <em>clone</em>.
</p>
<p class="leftbar">
The <code>mkiocccentry</code> toolkit <em>also</em> has a clone of <em>both</em> the <a href="https://github.com/lcn2/dbg">dbg
library</a> and the
<a href="https://github.com/lcn2/dyn_array">dyn_array library</a>; the <a href="https://github.com/lcn2/dyn_array">dyn_array
library</a> uses the <a href="https://github.com/lcn2/dbg">dbg
library</a> and the <a href="https://github.com/xexyl/jparse">jparse
library</a> uses both libraries but unlike in the
<a href="https://github.com/xexyl/jparse">jparse repo</a>, the libraries do not need to be
installed separately, in order to use the tools in <code>mkiocccentry</code>.
</p>
<p class="leftbar">
In other words, <code>mkiocccentry</code> <strong>contains everything</strong> you need, and <em>even if you
do install</em> the libraries from their respective repos, it/they will <strong>not be
used</strong> when compiling the <code>mkiocccentry</code> tools. This is important to
make sure that you’re using the correct versions, which is verified by
<code>chkentry</code>. See <a href="rules.html#rule17">Rule 17</a>!
</p>
<p class="leftbar">
Please see the
FAQ on “<a href="../faq.html#chkentry">validating .auth.json and/or .info.json files</a>
for more details on <code>chkentry</code> and how you can use it to validate your
<code>.auth.json</code> and <code>.info.json</code> files manually, without having to repackage your
submission.
</p>
<p class="leftbar">
You might also wish to see the
FAQ on “<a href="../faq.html#auth_json">.auth.json</a>”
and the
FAQ on “<a href="../faq.html#info_json">.info.json</a>”
for much more information on these files.
</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="txzchk"><code>txzchk</code></h2>
<p class="leftbar">
<code>txzchk(1)</code> performs a wide number of sanity checks on the xz
compressed tarball; if any issues are found (‘<code>feathers are stuck in the tarball</code>’ :-) ) <strong>AND if and <em>ONLY IF</em> you used
<code>mkiocccentry(1)</code></strong>, then it is <strong>possibly</strong> a bug in one of the tools and you
might want to <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the mkiocccentry bug report
page</a>. <strong>PLEASE run the
<code>bug_report.sh</code> script to help us out here!</strong> See the
FAQ on “<a href="../faq.html#mkiocccentry_bugs">report mkiocccentry bugs</a>”.
</p>
<p class="leftbar">
As part of its sanity checks, <code>txzchk(1)</code> will run <code>fnamchk(1)</code> on the
<em>filename</em> to verify that the name is valid. See the
FAQ on “<a href="../faq.html#fnamchk">fnamchk</a>”
and <a href="#fnamchk">fnamchk below</a> for more details on this tool.
</p>
<p class="leftbar">
It is beyond the scope of this document to discuss the many tests that
<code>txzchk(1)</code> performs; if you wish to know, we refer you to the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c">source
code</a> or the man
page. You might find a fun option if you do either of these!
</p>
<p class="leftbar">
Of course, as <code>txzchk</code> does not extract the tarball, it is possible that if you
manually package your submission tarball, you could still be violating <a href="rules.html#rule17">Rule
17</a>.
</p>
<p class="leftbar">
See also the
FAQ on “<a href="../faq.html#txzchk">txzchk</a>”.
</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="fnamchk"><code>fnamchk</code></h2>
<p class="leftbar">
As an important part of its algorithm, <a href="#txzchk">txzchk</a> directly executes <code>fnamchk</code>.
If the filename is invalid (or the filename does not match the
directory name of the tarball) then it is an <strong>error</strong> and you risk violating
<a href="rules.html#rule17">Rule 17</a>. Nevertheless, you can run the tool manually, should
you wish to.
</p>
<p class="leftbar">
For more information on <code>fnamchk</code> and how to manually validate your submission
tarball filename, see the
FAQ on “<a href="../faq.html#fnamchk">fnamchk</a>”.
</p>
<p class="leftbar">
Because <code>txzchk(1)</code> tool uses <code>fnamchk(1)</code> tool as part of its algorithm,
<code>mkiocccentry(1)</code> does not directly invoke <code>fnamchk(1)</code>, although we will
in the judging process.
</p>
<p class="leftbar">
It is extremely unlikely that <code>fnamchk(1)</code> reporting an invalid filename is a
bug in <code>fnamchk(1)</code> and as such, ignoring such an issue risks violating <a href="rules.html#rule17">Rule
17</a> which is a big risk. Of course, using <code>mkiocccentry(1)</code>
would prevent this from happening as it would not create such a file anyway. If
<code>mkiocccentry(1)</code> was used it would rather suggest a bug in one of the tools and
you should <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the mkiocccentry issues
page</a>.
See the
FAQ on “<a href="../faq.html#mkiocccentry_bugs">report mkiocccentry bugs</a>”.
</p>
<p class="leftbar">
As you can see, the use of <code>mkiocccentry(1)</code> is <strong>HIGHLY RECOMMENDED</strong>, and at
the risk of stating the obvious, you run <strong>a VERY BIG risk</strong> of having
your submission rejected if you package your own tarball, and there are <strong>ANY
problems</strong>. For instance, if <code>chkentry(1)</code> found a problem in your <code>.info.json</code>
file, the <code>mkiocccentry(1)</code> tool would not package it. But if you were to package
it manually, you would be violating <a href="rules.html#rule17">Rule 17</a>. But even if
everything checks out OK you should <strong>NOT</strong> assume that everything <strong>IS</strong> OK.
</p>
<div id="bugs">
<h1 id="problems-andor-bugs-in-tools">Problems and/or bugs in tools</h1>
</div>
<p class="leftbar">
Although the tools have been tested quite a bit, and although it is quite
unlikely that there are bugs in it, it is nonetheless possible for bugs to
exist, as all programmers know. In this case, <strong>please</strong> ask for help or report what
you think is a bug as a bug, via the <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&amp;labels=bug&amp;projects=&amp;template=bug_report.yml&amp;title=%5BBug%5D+%3Ctitle%3E">bug report issues page in the mkiocccentry
repo</a>.
</p>
<p class="leftbar">
Of course, it is also possible for <code>mkiocccentry(1)</code>, or one or more of the
tools it executes (or another tool executes), to fail, but <strong>NOT</strong> because of a
bug. An example problem is if there is not enough memory available or if some
other library or syscall fails. Nonetheless it might be worth reporting as a
bug; it is a judgement call: if it’s a bug it’ll be addressed and if it’s not
that’s OK too!
</p>
<div id="make">
<div id="makefile">
<h1 id="makefiles">Makefiles</h1>
</div>
</div>
<p class="leftbar">
We <strong>recommend</strong> AND <strong>encourage</strong> you to use the example Makefile <strong>here</strong>,
as the starting point for your submission’s required <code>Makefile</code>:
</p>
<ul>
<li><p class="leftbar">
<a href="https://github.com/ioccc-src/winner/blob/master/next/Makefile.example">view example
Makefile</a>
</p></li>
<li><p class="leftbar">
<a href="Makefile.example"
download="Makefile">download example Makefile</a>
</p></li>
</ul>
<p class="leftbar">
Feel free to modify the <code>Makefile</code> to suit your obfuscation
needs.
</p>
<p class="leftbar">
Please add a space between the <code>=</code> and the value of variables, in the
<code>Makefile</code>, making sure that the <code>=</code> comes immediately after the name. See the
example <code>Makefile</code> for examples.
</p>
<p class="leftbar">
The rest of this section and its subsections will assume that you are using some
variant of the example <code>Makefile</code>, again renamed as <code>Makefile</code>.
</p>
<p class="leftbar">
We suggest that you compile your submission with a commonly available
<code>-std=gnu17</code> (ISO C 2017 with GNU extensions) C compiler.
</p>
<div id="cflags">
<div id="flags">
<h2 id="default-compiler-flags">Default compiler flags</h2>
</div>
</div>
<p class="leftbar">
Unless you <strong>clearly state</strong> otherwise in your <code>remarks.md</code> file, <strong>AND</strong> put in
your submission’s <code>Makefile</code>, we <strong>will</strong> compile using <code>-std=gnu17 -O3 -g3</code>!
</p>
<p class="leftbar">
It <strong>is OK</strong> if you need to require your submission to <strong>NOT be</strong> compiled
using the default <code>-std=gnu17 -O3 -g3</code> settings. Simply <strong>explain why</strong>
your submission should NOT be compiled using <code>-std=gnu17 -O3 -g3</code> in
your <code>remarks.md</code> file, <strong>AND</strong> adjust your <code>Makefile</code> accordingly.
</p>
<p class="leftbar">
One reason that you might have to change the flags, is that the optimiser is
known to break some programs, but there are certainly other possible valid
reasons. Again, just update the <code>Makefile</code> and explain it in your <code>remarks.md</code>.
See the <a href="#optimiser">optimiser section</a> for details for changing optimiser
flags.
</p>
<div id="compilers">
<h2 id="default-compiler">Default compiler</h2>
</div>
<p class="leftbar">
<strong>IMPORTANT NOTE</strong>: The use of <code>-std=gnu17</code> does <strong>NOT</strong> imply the use of the <code>gcc</code>
compiler! We often start by compiling using the <strong>clang</strong> C compiler instead.
</p>
<p class="leftbar">
<strong>PLEASE NOTE</strong>: in macOS, the compiler <code>gcc</code> found at <code>/usr/bin/gcc</code> is
in truth the <code>clang</code> compiler, as <code>/usr/bin/gcc --version</code> will show!
</p>
<div id="cstd">
<div id="standard">
<h2 id="c-standard">C standard</h2>
</div>
</div>
<p class="leftbar">
You may change the standard under which your submission is compiled
by modifying the <code>CSTD</code> Makefile variable. For example, to use <code>c17</code> instead:
</p>
<pre><code> CSTD= -std=c17</code></pre>
<div id="opt">
<div id="optimization">
<div id="optimisation">
<div id="optimizer">
<div id="optimiser">
<h2 id="default-optimisation-level">Default optimisation level</h2>
</div>
</div>
</div>
</div>
</div>
<p class="leftbar">
You may change the level of optimization and compiler debug level
that your submission is compiled with, by modifying the <code>OPT</code> Makefile variable.
For example, to compile without optimization, and to include debug symbols:
</p>
<pre><code> OPT= -O0 -g3</code></pre>
<div id="warnings">
<div id="cwarn">
<h2 id="compiler-warnings">Compiler warnings</h2>
</div>
</div>
<p class="leftbar">
The default warning flags are set via the <code>CWARN</code> variable, as shown in the
example <code>Makefile</code>:
</p>
<pre><code> # Common C compiler warning flags
#
CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN}</code></pre>
<p class="leftbar">
For details on <code>CSILENCE</code> and <code>CUNKNOWN</code>, see the <a href="#disabling-warnings">section on disabling
warnings</a>.
</p>
<div id="weverything">
<h3 id="the--weverything-option">The <code>-Weverything</code> option</h3>
</div>
<p class="leftbar">
For compilers, such as <code>clang</code>, that have the <code>-Weverything</code> option,
while you may wish to try it, you should read our
FAQ on “<a href="../faq.html#weverything">clang -Weverything</a>”.
We do <strong>NOT</strong> recommend that you put
the use of <code>-Weverything</code> into your submission’s <code>Makefile</code> for the reasons
cited there. This goes even if your version does not trigger a warning as some
other version might!
</p>
<p class="leftbar">
On the other hand, if <code>${CC}</code> has “<code>clang</code>” in the name, the example <code>Makefile</code> will
automatically enable <code>-Weverything</code>, so you might have to use <code>-Wno-foo</code>
options anyway, as detailed below. See the
FAQ on “<a href="../faq.html#weverything">-Weverything</a>”
for more details.
</p>
<p class="leftbar">
If “<code>clang</code>” is NOT in <code>${CC}</code>, the <code>CWARN</code> variable will not be further
modified.
</p>
<p class="leftbar">
There is no real penalty for compiler warnings. Sometimes
compiler warnings cannot be helped: especially in the case of
obfuscated C. :-) So if you cannot easily get rid of a compiler
warning, try not fret too much.
</p>
<p class="leftbar">
We <strong>LIKE</strong> code that has a minimum of warnings, especially under the
more strict <code>-Wall -Wextra -pedantic</code> mode:
</p>
<pre><code> CWARN= -Wall -Wextra -pedantic</code></pre>
<p class="leftbar">
The two previous guidelines might be thought by some as being somewhat
contradictory. Isn’t life, and isn’t trying to satisfy “contradictory customer
requirements” all too often like that? :-) Try to minimize warnings if you
can.
</p>
<p class="leftbar">
If you manage to produce very few warnings, or perhaps no warnings at
all under the <code>-Wall -Wextra -pedantic</code> mode, then by all means brag about it in
your <code>remarks.md</code> file <strong>AND BE SURE TO TELL US</strong> the OS, OS version, compiler
and compiler version in which you observed this occurring (in case our OS and
compiler produces a different result: so your submission won’t be penalized for
not meeting your claims).
</p>
<p class="leftbar">
On the other hand, some warnings cannot be disabled and are enabled by compilers
without any warning option specified. These are sometimes inevitable in
obfuscated code and even in some non-obfuscated code, and you should not worry
about this, though it might be worth pointing out.
</p>
<p class="leftbar">
For instance, some compilers like to warn about use of <code>char *</code>s, which seems to
be dubious, as it obviously can’t (always) be avoided, being a big part of C, so
you should not worry about this either; this is the warning
<code>-Wunsafe-buffer-usage</code> and the way to disable it is <code>-Wno-unsafe-buffer-usage</code>.
See also the
FAQ on “<a href="../faq.html#forced_warnings">forced warnings</a>”
and the
FAQ on “<a href="../faq.html#weverything">-Weverything</a>”.
</p>
<h2 id="disabling-warnings">Disabling warnings</h2>
<p class="leftbar">
If you do have to disable warnings due to <code>-Weverything</code> automatically being
included, you might wish to state this fact. :-)
And even without <code>-Weverything</code> there can be warnings, as noted above.
</p>
<p class="leftbar">
If your submission issues lots of warnings but is otherwise
marvelously obfuscated in multiple levels, don’t worry about it. Nevertheless,
be sure that the warnings do not constitute a potential “<strong>show stopper</strong>”
compiler problem. Be sure that compilers such as both <code>gcc</code> and <code>clang</code> won’t
produce a compiler <strong>error</strong> and refuse to compile your code: unless for some
reason that is what you intend to happen in which case document that too in your
<code>remarks.md</code> file. :-)
</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 class="leftbar">
To turn off a compiler warning, in your submission’s <code>Makefile</code>,
try something such as:
</p>
<pre><code> CSILENCE= -Wno-some-thing -Wno-another-thing</code></pre>
<p class="leftbar">
For instance:
</p>
<pre><code> CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation</code></pre>
<p class="leftbar">
If you do add “<code>-Wno-foo</code>” to your Makefile, consider changing:
</p>
<pre><code> CUNKNOWN=</code></pre>
<p class="leftbar">
to:
</p>
<pre><code> CUNKNOWN= -Wno-unknown-warning-option</code></pre>
<p class="leftbar">
Some compilers have reported this as an error, however, and if you have
such a compiler you might want to not add it, or at least note in your
<code>remarks.md</code> which OS, OS version, compiler and compiler version you had the
problem.
</p>
<div id="macros">
<h2 id="defining-macros-in-the-makefile">Defining macros in the Makefile</h2>
</div>
<p class="leftbar">
If you need to define something on the compile line, use
the <code>CDEFINE</code> Makefile variable. For example:
</p>
<pre><code> CDEFINE= -Dfoo -Dbar=baz</code></pre>
<div id="include">
<h2 id="include-files-in-the-makefile">Include files in the Makefile</h2>
</div>
<p class="leftbar">
If you need to include a file (as in <code>#include</code>) on the command line, use the
<code>CINCLUDE</code> Makefile variable. For example:
</p>
<pre><code> CINCLUDE= -include stdio.h</code></pre>
<div id="magic">
<h2 id="magic-in-the-makefile">Magic in the Makefile</h2>
</div>
<p class="leftbar">
If you need to add other “<strong>magic</strong>” flags to your compile line,
use the <code>COTHER</code> Makefile variable. For example:
</p>
<pre><code> COTHER= -fno-math-errno</code></pre>
<p class="leftbar">
<strong>NOTE</strong>: <strong>We only recommend using “<em>magic</em>” flags if <em>BOTH</em> <code>gcc</code>
<em>and</em> <code>clang</code></strong> support it.
</p>
<p class="leftbar">
Again, please note that in macOS, <code>/usr/bin/gcc</code> is actually <code>clang</code>!
</p>
<div id="clobber">
<h2 id="the-clobber-rule">The clobber rule</h2>
</div>
<p class="leftbar">
When <code>make clobber</code> is invoked, we request that submissions be restored
to their original submission state. For example, any temporary files
(<strong>including</strong> the compiled program(s)) created during the build process, or
during execution should be removed by the <code>clobber</code> rule. In other words, the
only things that should be in the directory after running <code>make clobber</code> is what
is in your submission tarball itself.
</p>
<p class="leftbar">
While people are free to mange their submission under <code>git(1)</code> or even use a
GitHub repo, dot-files and dot-directories such as <code>.git</code> are not allowed in a
submission.
</p>
<p class="leftbar">
The <code>mkiocccentry(1)</code> tool will ignore dot-files and dot-directories (such as
<code>.vimrc</code>, <code>.bashrc</code>, <code>.git</code> and <code>.github</code>) and not put them in the submission’s
compressed tarball. So while you may use such files and
directories to help develop your submission, they won’t be included when you run
the <code>mkiocccentry(1)</code> tool.
</p>
<p class="leftbar">
Even if you did manage to get it into the tarball somehow, <code>txzchk(1)</code> will
flag it as an error. When the judges run <code>txzchk(1)</code> on the uploaded submission
compressed tarball, if anything is wrong, for instance if you “sneak in” any
dot files or dot directories, the submission <strong>WILL BE REJECTED</strong> for violating
<a href="rules.html#rule17">Rule 17</a>!
</p>
<p class="leftbar">
You may use whatever tools you need to develop your submission, including the
use of <code>git(1)</code> or <code>gh(1)</code>, just be sure that your submission code and your
submission Makefile don’t depend on such tools.
</p>
<p class="leftbar">
If this is not clear, please do <strong>NOT</strong> use these tools to help with the
<code>clobber</code> rule! For instance, do <strong>NOT</strong> use <code>git clean</code>! Not only does this
depend on the user having <code>git(1)</code> but it also does not account for the
submission tarballs. Even worse is when someone does have it in a <code>git(1)</code> repo
it will remove files that are not under <code>git(1)</code> control! Instead, see the
<code>clobber</code> rule in the example Makefile to see how to manage this.
</p>
<p class="leftbar">
Do <strong>NOT</strong> rely on these tools for any other rule, either.
</p>
<p>Jump to: <a href="#">top</a></p>
<div id="likes">
<div id="dislikes">
<h1 id="our-likes-and-dislikes">OUR LIKES AND DISLIKES:</h1>
</div>
</div>
<p class="leftbar">
We <strong>LIKE</strong> submissions that use an edited variant of the
example Makefile, as described and linked to in the <a href="#makefile">Makefile section</a>,
renamed as <code>Makefile</code> of course. This makes it easier for the <a href="../judges.html">IOCCC judges</a>
to test your submission. And if your submissions wins, it makes it easier to integrate it into
the <a href="https://www.ioccc.org/index.html">Official IOCCC winner website</a>.
</p>
<p class="leftbar">
We <strong>LIKE</strong> submissions that have some educational value. This does <strong>NOT</strong> mean
that your submission should not be obfuscated but the IOCCC has moved away from
the idea of spoilers. In other words, unless your submission does some kind of
encryption (or something with encryption), you should not encrypt your remarks,
say with rot13 or anything else, and it is also appreciated if your remarks have
some education value. And although these are not required, they are a nice bonus.
</p>
<p class="leftbar">
We <strong>LIKE</strong> submissions that use an edited version of the
<code>try.sh</code> example script (and if you have alternate code,
the same applies with the <code>try.alt.sh</code> script):
</p>
<ul>
<li><p class="leftbar">
<a href="https://github.com/ioccc-src/winner/blob/master/next/try.sh">view example try.sh</a>
</p></li>
<li><p class="leftbar">
<a href="try.sh">download example try.sh</a>
</p></li>
<li><p class="leftbar">
<a href="https://github.com/ioccc-src/winner/blob/master/next/try.alt.sh">view example try.alt.sh</a>
</p></li>
<li><p class="leftbar">
<a href="try.alt.sh">download example try.alt.sh</a>
</p></li>
</ul>
<p class="leftbar">
Of course, it is quite possible that only one invocation is
possible, so it is not necessarily detrimental to your submission if you do not
include one, though we do like interesting and creative uses of submissions. See
also the
FAQ on “<a href="../faq.html#try_scripts">submitting try.sh and try.alt.sh scripts</a>”.
</p>
<p class="leftbar">
You might wish to add <code>./try.sh</code> to the <code>try</code> rule in the Makefile you submit.
If you have alternate code, then you could add a <code>try.alt</code> rule or something
like that.
</p>
<p>Doing masses of <code>#define</code>s to obscure the source has become ‘old’. We
tend to ‘see thru’ masses of <code>#define</code>s due to our pre-processor tests
that we apply. Simply abusing <code>#define</code>s or <code>-Dfoo=bar</code> won’t go as far
as a program that is more well rounded in confusion.</p>
<p><strong>Many</strong> C compilers <strong>DISLIKE</strong> the following code, and so do we:</p>
<pre><code> #define d define
#d foo /* &lt;-- don&#39;t expect this to turn into #define foo */</code></pre>
<p class="leftbar">
In other words, it is a compilation error.
</p>
<p>When declaring local or global variables, you should declare the type:</p>
<pre><code> int this_is_fine;
this_is_not; /* &lt;-- Try to avoid implicit type declarations */</code></pre>
<p class="leftbar">
We tend to <strong>like <em>less</em></strong> a submission that requires either
<code>gcc</code> <strong>OR</strong> <code>clang</code>. <strong>We <em>prefer</em> submissions</strong> that can compile
under <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>.
</p>
<p class="leftbar">
We <strong>RECOMMEND</strong> that the compiler flags you use in your
submission’s <code>Makefile</code> are supported by <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>.
</p>
<p class="leftbar">
We <strong>DISLIKE</strong> the use of obscure compiler flags, especially
if <code>gcc</code> and/or <code>clang</code> do not support it. We <strong>suggest</strong>
that you not use any really obscure compiler flags if you can help it.
</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(&quot;The machine that goes BING!!\n&quot;);
}
| please_dont_submit_this();
}</code></pre>
<p>On 2012 July 20, the <a href="../judges.html">judges</a> 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 <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>.</p>
<p class="leftbar">
We <strong>DISLIKE</strong> submissions that require the use of <code>-fnested-functions</code>.
</p>
<p>We prefer programs that do not require a fish license: crayons and
cat detector vans not withstanding.</p>
<p>If your submission uses functions that have a variable number of
arguments, <strong>be careful</strong>. Systems implement <code>va_list</code> in a wide variety
of ways. Because of this, a number of operations using <code>va_list</code> <strong>are
not portable and <em>must not</em> be used</strong>:</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 class="leftbar">
We <strong>DISLIKE</strong> the use of <code>varargs.h</code>. Use <code>stdarg.h</code> instead.
</p>
<p class="leftbar">
We <strong>DISLIKE</strong> the use of <code>gets(3)</code>. Use <code>fgets(3)</code> instead.
</p>
<p class="leftbar">
We tend to <strong>DISLIKE</strong> the blatant use of tarballs in an attempt to simply get
around the extra file number limit. We realize there may be cases where a
tarball containing a number of extra files may be needed. Such a need for a
tarball <strong>MUST</strong> be explained in the <code>remarks.md</code> file.
</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 submission should assume that <code>exit(3)</code> returns a <code>void</code>.</p>
<p class="leftbar">
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 class="leftbar">
While those who are used to temperatures found on <a href="https://science.nasa.gov/dwarf-planets/">dwarf
planets</a>
(<strong>yes Virginia, dwarf planets <em>ARE</em> 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 <strong>DISLIKE</strong> programs that:</p>
<ul>
<li>are very hardware specific</li>
<li>are very OS version specific (<code>index(3)</code>/<code>strchr(3)</code> differences are OK, but
sockets/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 your <code>remarks.md</code> file)</li>
<li><p class="leftbar">
won’t compile or run in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
Specification</a>
environment
</p></li>
<li><p class="leftbar">
depend on a utility or application not normally found
in systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
Specification</a>
</p></li>
<li>abuse the build file to get around the size limit<br></li>
<li><p class="leftbar">
obfuscate by use of ANSI trigraphs
</p></li>
<li><p class="leftbar">
obfuscate by use of digraphs
</p></li>
<li><p class="leftbar">
are larger than they need to be
</p></li>
<li><p class="leftbar">
have more lines than they need to have
</p></li>
<li><p class="leftbar">
are “blob-ier” (just a pile of unformatted C code)
than they need to be
</p></li>
<li><p class="leftbar">
are rather similar to <strong><a href="../years.html">previous
winners</a></strong> :-(
</p></li>
<li><p class="leftbar">
are <strong>identical</strong> to <strong><a href="https://en.wikipedia.org/wiki/Null_device">previous
losers</a></strong> :-)
</p></li>
<li>that mandate the exclusive use of a specific Integrated Development Environment (IDE)</li>
</ul>
<p>In order to encourage submission portability, we <strong>DISLIKE</strong> 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 submission. Nevertheless some of the better IDEs have command-line
interfaces to their compilers, once one learns how to invoke a shell.</p>
<p class="leftbar">
The program must compile and link cleanly in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
Specification</a>
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 &lt;windows.h&gt; /* we DISLIKE this */</code></pre>
<p>Unless you are cramped for space, or unless you are entering the
‘<strong>Best one liner</strong>’ 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 “<strong>how to build</strong>” process (via the <code>Makefile</code> or otherwise) 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">Microsoft Windows</a>. :-)</p>
<p class="leftbar">
Other windows, on the other hand, might be OK: especially where “<strong>X
marks the spot</strong>”. Yet on the third hand, windows are best when they are
“unseen” (i.e., not dirty). :-)
</p>
<p>The <a href="../judges.html">judges</a>, 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 <a href="https://science.nasa.gov/earth/">Earth</a>. :-)</p>
<p class="leftbar">
You should try to restrict commands used in the build file to
commands found in <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a> environments
and systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a>.
</p>
<p class="leftbar">
You may 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 (e.g., Linux, GNU Hurd, BSD, Unix, etc.).</p>
<blockquote>
<p>You are in a maze of twisty <em>guidelines</em>, all different.</p>
</blockquote>
<p>There are at least zero <a href="../judges.html">judges</a> who think that
<a href="https://en.wikipedia.org/wiki/Fideism">Fideism</a> 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>WITHOUT human intervention</strong>. So don’t do things such as:</p>
<pre><code> prog: prog.c
#echo this next line requires data from standard input
cat &gt; prog.c
${CC} prog.c -o prog</code></pre>
<p>However, you can do something cute such as making your program
do something dumb (or cute) when it is built ‘automatically’, and
when it is run with a human involved, do something more clever.
For example, one could put in their <code>Makefile</code>:</p>
<pre><code> prog: prog.c
${CC} prog.c -DNON_HUMAN_COMPILE -o prog
@echo &quot;See remarks section about alternate ways to compile&quot;</code></pre>
<p>and then include special notes in their <code>remarks.md</code> file 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 <strong>DISLIKE</strong> 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 <a href="rules.html#rule2">the source code
size limit</a>. 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>
<blockquote>
<p>All generalizations are false, including this one. – <strong>Mark Twain</strong></p>
</blockquote>
<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 submission. See the <a href="rules.html">IOCCC
rules</a> for details (in particular, <a href="rules.html#rule9">Rule 9</a>).</p>
<p>We suggest that you avoid trying for the ‘<strong>smallest self-replicating</strong>’
source. The smallest, a <a href="../1994/smr/index.html">zero byte entry</a>, won in
<a href="../years.html#1994">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 class="leftbar">
Unless you specify <code>-fwritable-strings</code> (see <code>COTHER</code> in the example
Makefile, described in the <a href="#makefile">Makefile section</a>), do not assume this
sort of code will work:
</p>
<pre><code> char *T = &quot;So many primes, so little time!&quot;;
...
T[14] = &#39;;&#39;; /* modifying a string requires: -fwritable-strings */</code></pre>
<p class="leftbar">
Even so, one should probably not assume that this is universally accepted.
</p>
<p class="leftbar">
Initialized char arrays are OK to write over. For instance, this is OK:
</p>
<pre><code> char b[] = &quot;Is this OK&quot;;
b[9] = &#39;k&#39;; /* modifying an initialized char array is OK */</code></pre>
<p class="leftbar">
There are more than 1 typos in this very sentence.
</p>
<p>X client entries should be as portable as possible. Submissions 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 <a href="https://www.w3.org/standards/">W3C
standard</a>.
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 are not in wide spread use.</p>
<p>This is the only <em>guideline</em> that contains the word
<a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>.</p>
<p class="leftbar">
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 class="leftbar">
OK, there are actually 3 <em>guidelines</em> that contain the word
<a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>.
</p>
<p>We <strong>DISLIKE</strong> 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 class="leftbar">
X client entries should try to not to depend on particular items in
<code>.Xdefaults</code>. If you must do so, be sure to note the required lines
in the your <code>remarks.md</code> file. They should also not depend on any
particular window manager.
</p>
<p class="leftbar">
Try to avoid entries that play music that some people believe is copyrighted
music.
</p>
<p class="leftbar">
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 the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
Specification</a>.
</p>
<p class="leftbar">
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 class="leftbar">
To quote the <a href="../judges.html">IOCCC judges</a>:
</p>
<blockquote>
<p>You very well might not be completely be prohibited from failing to not partly
misunderstand this particular <em>guideline</em>, but of course, we could not possibly
comment! :-) Nevertheless, you are neither prohibited, nor are you fully
required to determine that this or the previous sentence is either false and/or
perhaps misleading. Therefore, it might be wise for you to not fail to consider
to not do so, accordingly. Thank you very much.</p>
</blockquote>
<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 <strong>LIKE</strong> 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 <strong>NUMBER OF DIFFERENT TYPES OF OBFUSCATIONS!</strong> <strong>&lt;== 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 class="leftbar">
You are better off explaining what your submission does in your
<code>remarks.md</code> file section rather than leaving it obscure for the
<a href="../judges.html">judges</a> as we might miss something and/or be too tired to
notice.
</p>
<p class="leftbar">
Please avoid this specific individual <em>guideline</em>, if it at all possible.
</p>
<p class="leftbar">
We freely admit that interesting, creative or humorous comments in
your <code>remarks.md</code> file help your chances of winning. If you had to
read so many twisted submissions, you too would enjoy a good laugh or two.
We think the readers of the contest winners do as well. We do read
your <code>remarks.md</code> content during the judging process, so it is worth your
while to write remarkable <code>remarks.md</code> file.
</p>
<p>We <strong>DISLIKE</strong> 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 class="leftbar">
<a href="rules.html#rule13">Rule 13</a> no longer discourages the use of UTF-8
characters in C code.
</p>
<p class="leftbar">
It is a very good idea to, in your <code>remarks.md</code> file, tell us why you
think your submission is obfuscated. This is particularly true if
your submission has some very subtle obfuscations that we might
otherwise overlook. <strong>&lt;&lt;– Hint!</strong>
</p>
<p>Anyone can format their code into a dense blob. A really clever
author will try format their submission 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 <code>remarks.md</code> where you talk
about why you think your submission 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 class="leftbar">
We prefer code that can run on either a 64-bit or 32-bit
processor. However, it is <strong>UNWISE </strong>to assume it will run on an
some Intel-like x86 architecture.
</p>
<p>We believe that Mark Twain’s quote:</p>
<blockquote>
<p>Get your facts first, then you can distort them as you please.</p>
</blockquote>
<p>… is a good motto for those writing code for the IOCCC.</p>
<p>The IOCCC size tool source is not an original work, unless you are <a href="../authors.html#Anthony_C_Howe">Anthony C
Howe</a>, in which case it is original! :-)
Submitting source that uses the content of
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">iocccsize.c</a>, unless you are
<a href="../authors.html#Anthony_C_Howe">Anthony C Howe</a>, might run the risk of
violating <a href="rules.html#rule7">Rule 7</a>.</p>
<p class="leftbar">
The <code>txzchk(1)</code> tool source is not an original work,
unless you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone Ferguson</a>, in
which case it is original! :-) Submitting source that uses the content of
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c">txzchk.c</a>,
unless you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone Ferguson</a>, might
run the risk of violating <a href="rules.html#rule7">Rule 7</a>.
</p>
<p class="leftbar">
Neither the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/chkentry.c">chkentry tool
source</a> nor
the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/README.md">JSON parser and
library</a>
nor
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jstrencode.c">jstrencode</a>
nor
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jstrdecode.c">jstrdecode</a>
nor any of the other <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse">jparse
tools</a>
(see the <a href="https://github.com/xexyl/jparse/">jparse repo</a>), nor the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/test_ioccc/fnamchk.c">fnamchk tool
source</a>
are original works,
unless you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone Ferguson</a> or
<a href="http://www.isthe.com/chongo/index.html">Landon Curt Noll</a>, in which case they
are original! :-) Submitting source that uses the code of these tools or
library, unless you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone
Ferguson</a> or <a href="http://www.isthe.com/chongo/index.html">Landon Curt
Noll</a>, might run the risk of violating
<a href="rules.html#rule7">Rule 7</a>.
</p>
<p class="leftbar">
Unless you are <a href="http://www.isthe.com/chongo/index.html">Landon Curt Noll</a>, the
remaining tools in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>
are <strong>NOT</strong> original works. Submitting source that uses the content of those tools,
unless you are <a href="http://www.isthe.com/chongo/index.html">Landon Curt Noll</a>, might
run the risk of violating <a href="rules.html#rule7">Rule 7</a>.
</p>
<p class="leftbar">
<a href="rules.html#rule7">Rule 7</a> does not prohibit you from writing your own
obfuscated versions of these tools, unless of course you are <a href="http://www.isthe.com/chongo/index.html">Landon Curt
Noll</a>, in which case you <em>probably</em>
won’t win since <a href="../judges.html">judges</a> are disqualified! :-) However, <strong><em>if</em></strong>
you do write your own version, you <strong><em>might</em></strong> wish to make it do something
<strong><em>more</em> interesting</strong> than simply implementing the <a href="../index.html">IOCCC</a>
tools’ algorithms; on the other hand, if you do this, you might want to keep in
mind that writing an obfuscated version of a library runs the risk of violating
<a href="rules.html#rule1">Rule 1</a> as it is likely not a complete program.
</p>
<p class="leftbar">
Even so, we do not recommend you try and submit a JSON parser due to
the fact it will likely exceed <a href="rules.html#rule2">the source code size limit</a>
and because you likely can’t beat <a href="https://github.com/westes/flex">flex</a> or
<a href="https://www.gnu.org/software/bison/">bison</a> in obfuscation. This isn’t to
say that <a href="https://github.com/xexyl/jparse/blob/master/json_README.md#so-called-json-spec">the so-called JSON spec</a> is not
obfuscated, but unless you have some really clever way to compact and
obfuscate a JSON parser more than <a href="https://github.com/westes/flex">flex</a> and
<a href="https://www.gnu.org/software/bison/">bison</a> you will likely not win, either
because of the <a href="rules.html#rule2">source code size limit</a> or because it is not
as obfuscated as the lexer/parser of
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse">jparse</a>.
</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 class="leftbar">
If <a href="../judges.html">IOCCC judges</a> 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, we might just try your submission on that emulator as well :-)
</p>
<p class="leftbar">
If your submission <strong>MUST</strong> run only on a 64-bit or 32-bit architecture,
then you <strong>MUST</strong> specify the <code>-arch</code> on your command line
(see <code>ARCH</code> in the example
Makefile, described in <a href="#makefile">Makefile section</a>). Do not assume a
processor word size without specifying <code>-arch</code>. For example:
</p>
<pre><code> ARCH= -m64</code></pre>
<p class="leftbar">
Note, however, that some platforms will not necessarily support some
architectures. For instance, more recent versions of <code>macOS</code> do <strong>NOT</strong> support
32-bit!
</p>
<p>Try to be even more creative!</p>
<p class="leftbar">
If there are limitations in your submission, you are highly encouraged
to note such limitations in your <code>remarks.md</code> file. For example if your
submission factors values up to a certain size, you might want to state:
</p>
<blockquote>
<p>This submission factors values up <code>2305567963945518424753102147331756070</code>.
Attempting to factor larger values will produce unpredictable results.</p>
</blockquote>
<p>The <a href="../judges.html">judges</a> might try to factor the value -5, so you want to might state:</p>
<blockquote>
<p>This submission factors positive values up
<code>2305567963945518424753102147331756070</code>. Attempting to factor large values will
produce unpredictable results.</p>
</blockquote>
<p>However the <a href="../judges.html">judges</a> might try to also factor 0, so you want to might state:</p>
<blockquote>
<p>This submission factors values between 1 and
<code>2305567963945518424753102147331756070</code>. Attempting to factor values outside
that range will produce unpredictable results.</p>
</blockquote>
<p>Moreover the might try to also factor 3.5 or 0x7, or Fred, so you want to might state:</p>
<blockquote>
<p>This submission factors integers between 1 and
<code>2305567963945518424753102147331756070</code>. Attempting to factor anything else
will produce unpredictable results.</p>
</blockquote>
<p>You submission 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>
<blockquote>
<p>This submission factors integers between 1 and <code>2305567963945518424753102147331756070</code>.
Attempting to factor anything else will cause the program to insult your pet fish Eric.</p>
</blockquote>
<p>The <a href="../judges.html">judges</a> might not have a pet fish named Eric, so you might want to state:</p>
<blockquote>
<p>This submission factors integers between 1 and
<code>2305567963945518424753102147331756070</code>. 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.</p>
</blockquote>
<p>When all other things are equal, a submission with fewer limitations will be judged
better than a submission with lots of limitations. So you might want to code accordingly
and state:</p>
<blockquote>
<p>This submission 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 might insult a fish named Eric.</p>
</blockquote>
<p class="leftbar">
Do not fear if you’re not 100% sure of the significance of
<code>2305567963945518424753102147331756070</code> as it is not of prime importance: or is
it? :-)
</p>
<p class="leftbar">
We <strong>DISLIKE</strong> the use of use ASCII tab characters in markdown files, such as in the required <code>remarks.md</code> file.
</p>
<p class="leftbar">
We don’t mind the use ASCII tab characters in your C code. Feel free
to use ASCII tab characters if that suits your obfuscation needs. If is
perfectly <strong>OK</strong> to use tab characters elsewhere in your submission, just not in
markdown files as this tends complicate and annoy us when it comes time to
rendering your markdown content.
</p>
<p class="leftbar">
If you do use ASCII tab characters in your non-markdown files, be
aware that some people may use tab stop that is different than the common 8
character tab stop.
</p>
<p class="leftbar">
<strong>PLEASE</strong> observe our <a href="../markdown.html">IOCCC markdown guidelines</a>
when forming your submission’s <code>remarks.md</code> file. And if your submission
contains additional markdown files, please follow those same guidelines for
those files. See also <a href="rules.html#rule19">Rule 19</a> and our
FAQ on “<a href="../faq.html#markdown">markdown</a>”.
</p>
<p class="leftbar">
We <strong>LIKE</strong> reading <code>remarks.md</code> files, especially if they contain
useful, informative, and even humorous content about your submission. Yes, this
is a <strong>hint</strong>. :-)
</p>
<p class="leftbar">
We <strong>RECOMMEND</strong> you put a reasonable amount effort into the content of the
<code>remarks.md</code> file: it is a required for a reason. :-)
</p>
<p>Jump to: <a href="#">top</a></p>
<div id="rules_abuse">
<div id="abusing_rules">
<h1 id="abusing-the-rules">ABUSING THE RULES:</h1>
</div>
</div>
<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 <strong>NOT</strong> an invitation to violate the
<a href="rules.html">IOCCC rules</a>. A submission that violates the <a href="rules.html">rules</a> in the
opinion of the <a href="../judges.html">judges</a>, <strong>WILL</strong> be
disqualified. <strong><em>RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!</em></strong> If you
have a submission 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 class="leftbar">
If you intend to abuse the <a href="rules.html">IOCCC rules</a>,
indicate so in your <code>remarks.md</code> file. You <strong>MUST</strong> 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 submission is valid. Humor and/or creativity help plead a case.
As there is no guarantee that you will succeed, you might consider
submitting an alternate version that conforms to the
<a href="rules.html">IOCCC rules</a>.
</p>
<p class="leftbar">
If you do bypass the <code>mkiocccentry(1)</code> warnings about <a href="rules.html#rule2a">Rule
2a</a> and/or about <a href="rules.html#rule2b">Rule 2b</a>
and submit a submission anyway, you <strong>MUST</strong> try to justify why the IOCCC
<a href="../judges.html">judges</a> should not reject your submission due to a rule violation.
</p>
<p>Abusing the web submission procedure tends to annoy us more
than amuse us. Spend your creative energy on content of your
submission 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 clever 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>
<p>Jump to: <a href="#">top</a></p>
<div id="judging">
<h1 id="judging-process">JUDGING PROCESS:</h1>
</div>
<p>Entries are judged by Leonid A. Broukhis and Landon Curt Noll.</p>
<p>Each submission submitted is given a random id number and subdirectory. The
submission files including, but not limited to <code>prog.c</code>, <code>Makefile</code>,
<code>remarks.md</code> as well as any data files that you submit, are all placed under
their own directory and stored and judged from this directory.</p>
<p>Any information about the authors is not read by the <a href="../judges.html">judges</a> 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 submission.</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 <a href="../judges.html">judges</a> are on to this trick
and therefore consider any obfuscated source or data file claiming to be from
Honeyman to not be from Honeyman. This of course creates an interesting paradox
known as the “<strong>obfuscated Peter Honeyman paradox</strong>”. Should Peter Honeyman
actually submit to the IOCCC, he alone is excluded from the above, as we
will likely believe it’s just another attempt at confusion. This <em>guideline</em> is
known as the “<strong>Peter Honeyman is exempt</strong>” <em>guideline</em>.</p>
<p><strong>BTW</strong>: 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 to the IOCCC 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, <code>remarks.md</code>, data files, etc., the above “<strong>Peter Honeyman is
exempt</strong>” 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 are 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 printouts. By tradition, we do not even
reveal the number of entries that we received.</p>
<p class="leftbar">
During the judging process, a process that spans multiple sessions over
a few weeks, we post general updates from our <a href="https://fosstodon.org/@ioccc">Mastodon
account</a>.
</p>
<p class="leftbar">
<strong>Make sure you reload the feed</strong> every so often <strong>because unless you
are mentioned you will NOT get a push notification!</strong>
</p>
<p>Jump to: <a href="#">top</a></p>
<div id="rounds">
<h2 id="judging-rounds">JUDGING ROUNDS:</h2>
</div>
<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, a submission gets at least two readings.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="readings">
<h2 id="judging-readings">JUDGING READINGS:</h2>
</div>
<p>A reading consists of a number of actions:</p>
<ul>
<li><p class="leftbar">
reading <code>prog.c</code>, the C source, reviewing the <code>remarks.md</code> information
</p></li>
<li>briefly looking any any supplied data files</li>
<li>passing the source thru the C pre-processor
skipping over any <code>#include</code>d 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 <code>#include</code>d files</li>
<li>compiling/building the source</li>
<li>running the program</li>
<li>Doing other things that only <a href="../judges.html">IOCCC judges</a> know about :-)</li>
</ul>
<p>In later rounds, other actions are performed including performing
miscellaneous tests on the source and binary.</p>
<p class="leftbar">
This is the very <strong>guideline</strong> that goes, <strong>BING!</strong>
</p>
<p>Until we reduce the stack of submissions down to about 25 submissions,
submissions are judged on an individual basis. A submission is set aside because it
does not, in our opinion, meet the standard established by the round.
When the number of submissions thins to about 25 submissions, we begin to form
award categories. Submissions begin to compete with each other for awards.
A submission will often compete in several categories.</p>
<p>The actual award category list will vary depending on the types of submissions
we receive. A typical category list might be:</p>
<ul>
<li><strong>best small one line program</strong> (see above about one line programs)</li>
<li><strong>best small program</strong></li>
<li><strong>strangest/most creative source layout</strong></li>
<li><strong>most useful obfuscated program</strong></li>
<li><strong>best game that is obfuscated</strong></li>
<li><strong>most creatively obfuscated program</strong></li>
<li><strong>most deceptive C code</strong> (code with deceptive comments and source code)</li>
<li><strong>best X program</strong> (see <a href="#likes">OUR LIKES AND DISLIKES</a>)</li>
<li><strong>best abuse of ISO C or ANSI C standard</strong> (see above about compilers)</li>
<li><strong>best abuse of the C preprocessor</strong></li>
<li><strong>worst/best abuse of the rules</strong> (or some variation)</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 submission is good enough to win, but is beat out by a
similar, but slightly better submission. For this reason, it is sometimes
worthwhile to resubmit an improved version of a submission that failed to win in
a previous year, the next year. This assumes, of course, that the submission is
worth improving in the first place!</p>
<p class="leftbar">
Over the years, more than one <a href="../judges.html">IOCCC judge</a>
has been known to <strong>bribe</strong> another IOCCC <a href="../judges.html">judge</a> into voting for a
winning entry by offering a bit of high quality chocolate, or
other fun item.
</p>
<p class="leftbar">
One <strong>should NOT</strong> attempt to <strong>bribe</strong> an <a href="../judges.html">IOCCC
judge</a>, <strong>unless you are an <a href="../judges.html">IOCCC judge</a></strong>,
because <strong>bribing</strong> an <a href="../judges.html">IOCCC judge</a> by a non-judge
has been shown to <strong>NOT</strong> be effective when the <strong>person <em>attempting</em>
the <em>bribe</em> is made known</strong> to the <a href="../judges.html">IOCCC judges</a>
(i.e., they are not anonymous) AND/OR the <strong>bribe</strong> is otherwise
associated with a submission to the <a href="../index.html">IOCCC</a>.
</p>
<p class="leftbar">
With the previous guideline in mind: <strong>anonymous</strong> gifts
for the <a href="../judges.html">IOCCC judges</a> that are <strong>NOT ASSOCIATED
WITH</strong> a submission to the <a href="../index.html">IOCCC</a> may be sent to the
<a href="../judges.html">IOCCC judges</a> via the
<a href="https://www.amazon.com/hz/wishlist/ls/3HSNTEL8RQ1M0?ref_=wl_share">IOCCC Amazon wishlist</a>.
It has been shown that receiving <strong>anonymous</strong> gifts provides the
<a href="../judges.html">IOCCC judges</a> with a nice
<a href="https://en.wikipedia.org/wiki/Dopamine">dopamine</a> boost, and happy
<a href="../judges.html">IOCCC judges</a> help make the <a href="../index.html">IOCCC</a> better for everyone. :-)
</p>
<p class="leftbar">
See the
FAQ on “<a href="../faq.html#support">support the IOCCC</a>”.
</p>
<p>More often than not, we select a small submission (usually one line) and a
strange/creative layout submission. We sometimes also select a
submission that abuses the <a href="guidelines.html">IOCCC guidelines</a> in an interesting way,
or that stretches the contest <a href="rules.html">rules</a> that while legal, it
nevertheless goes against the <strong>intent</strong> of the <a href="rules.html">rules</a>.</p>
<p class="leftbar">
Nevertheless, see <a href="rules.html#rule12">Rule 12</a>.
</p>
<p>In the end, we traditionally pick one submission as ‘<strong>best</strong>’. Sometimes such
a submission simply far exceeds any of the other entries. More often, the
‘<strong>best</strong>’ is picked because it does well in a number of categories.</p>
<p>In years past, we renamed the winning submission from <code>prog.c</code> to a
name related to the author(s)’ names. This is no longer done.
Winning source is called <code>prog.c</code>. A compiled binary is called <code>prog</code>.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="announcements">
<h1 id="announcement-of-winners">ANNOUNCEMENT OF WINNERS:</h1>
</div>
<p class="leftbar">
The <a href="../judges.html">judges</a> 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>.
</p>
<p class="leftbar">
We recommend that you follow us on mastodon but <strong>please make sure to
refresh the feed</strong> every so often (if not more often) because unless you are
mentioned or someone boosts your post you will not get a push notification.
</p>
<p>Jump to: <a href="#">top</a></p>
<div id="winners">
<h2 id="how-the-new-ioccc-winners-will-be-announced">How the new IOCCC winners will be announced</h2>
</div>
<p class="leftbar">
The <a href="../status.html">current status of the IOCCC</a> will change from
<strong><a href="../status.html#judging">judging</a></strong> to <strong><a href="../status.html#closed">closed</a></strong> .
</p>
<p class="leftbar">
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 class="leftbar">
When the above happens, the winning entries have been selected by the <a href="../judges.html">IOCCC
judges</a>.
</p>
<p class="leftbar">
The <a href="../judges.html">IOCCC judges</a> will begin to prepare to release the source
code of the new IOCCC winners.
</p>
<p class="leftbar">
The <a href="../judges.html">IOCCC judges</a> will commit the winning source to the
<a href="https://github.com/ioccc-src/winner">IOCCC winner repo</a> which will update the
<a href="https://www.ioccc.org/index.html">Official IOCCC website</a>.
</p>
<p class="leftbar">
The <a href="../news.html">IOCCC news</a> will also contain an announcement of the winners.
</p>
<p>Jump to: <a href="#">top</a></p>
<div id="mastodon">
<h2 id="an-important-update-to-how-winners-are-announced">An important update to how winners are announced</h2>
</div>
<p class="leftbar">
The IOCCC no longer uses twitter. IOCCC entries will be announced by a
<code>git</code> commit to the <a href="https://github.com/ioccc-src/winner">IOCCC entries repo</a>
that, in turn, updates the <a href="https://www.ioccc.org/index.html">Official IOCCC
website</a>.
</p>
<p class="leftbar">
In addition a note is posted to the <a href="https://fosstodon.org/@ioccc">IOCCC Mastodon account</a>.
</p>
<p>Jump to: <a href="#">top</a></p>
<div id="entries">
<h2 id="back-to-announcement-of-winners">Back to announcement of winners</h2>
</div>
<p class="leftbar">
It is pointless to ask the <a href="../judges.html">IOCCC judges</a> how many
submissions we receive. See <a href="../faq.html#how_many">How many submissions do the judges receive for a
given IOCCC?</a>.
</p>
<p>Often, winning entries are published in selected magazines from around the
world. Winners have appeared in books (‘<code>The New Hacker's Dictionary</code>’,
‘<code>Obfuscated C and Other Mysteries</code>’, ‘<code>Pointers On C</code>’, others) and on t-shirts.
More than one winner has been turned into a tattoo!</p>
<p>Last, but not least, <a href="../authors.html">winners</a> receive international fame and flames! :-)</p>
<p>Jump to: <a href="#">top</a></p>
<div id="more-information">
<div id="information">
<h1 id="for-more-information">FOR MORE INFORMATION:</h1>
</div>
</div>
<p class="leftbar">
For questions or comments about the contest, see <a href="../contact.html">Contacting the IOCCC</a>.
</p>
<p class="leftbar">
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 class="leftbar">
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 class="leftbar">
See the <a href="../news.html">Official IOCCC website news</a> for additional information.
</p>
<p class="change marker">
For the updates and breaking <a href="../news.html">IOCCC news</a>, you are encouraged to follow
the <a href="https://fosstodon.org/@ioccc">IOCCC on Mastodon</a>. See our
FAQ on “<a href="../faq.html#try_mastodon">Mastodon</a>”
for more information. <strong>Please be
aware</strong> that unless you are mentioned you most likely will <strong>NOT</strong> get a
notification so you should make sure to check the page.
</p>
<p class="leftbar">
Check out the <a href="https://www.ioccc.org/index.html">Official IOCCC website</a> in general.
</p>
<p>Jump to: <a href="#">top</a></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 &copy; 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%2Fwww.ioccc.org%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 -->