2067 lines
100 KiB
HTML
2067 lines
100 KiB
HTML
<!DOCTYPE html>
|
||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||
<!-- START: two lines up starts content from: inc/top.default.html -->
|
||
|
||
<!-- END: this line ends content from: inc/top.default.html -->
|
||
<!-- START: this line starts content from: inc/head.default.html -->
|
||
|
||
<head>
|
||
<link rel="stylesheet" href="../ioccc.css">
|
||
<link href="https://fonts.googleapis.com/css2?family=Outfit:wght@100..900&display=swap" rel="stylesheet">
|
||
<meta charset="utf-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
|
||
<title>The International Obfuscated C Code Contest</title>
|
||
<link rel="icon" type="image/x-icon" href="../favicon.ico">
|
||
<meta name="description" content="IOCCC Guidelines">
|
||
<meta name="keywords" content="IOCCC, guidelines, Guidelines">
|
||
</head>
|
||
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
|
||
<!-- END: this line ends content from: inc/head.default.html -->
|
||
|
||
<!-- -->
|
||
<!-- This web page was formed via the tool: bin/gen-top-html.sh -->
|
||
<!-- The content of main section of this web page came from: next/guidelines.md -->
|
||
<!-- -->
|
||
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: next/guidelines.md !!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: next/guidelines.md !!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: next/guidelines.md !!! -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
|
||
<!-- Markdown content was converted into HTML via the tool: bin/md2html.sh -->
|
||
|
||
<!-- START: this line starts content from: inc/body.default.html -->
|
||
|
||
<body>
|
||
|
||
<!-- END: this line ends content from: inc/body.default.html -->
|
||
<!-- START: this line starts content from: inc/topbar.default.html -->
|
||
|
||
<div class="theader">
|
||
<nav class="topbar">
|
||
<div class="container">
|
||
<div class="logo">
|
||
<a href="../index.html" class="logo-link">
|
||
IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="topbar-items">
|
||
<div class="item">
|
||
<span class="item-header">
|
||
Entries
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
<div class="outfit-font">
|
||
<a href="../years.html" class="sub-item-link">
|
||
Winning entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../authors.html" class="sub-item-link">
|
||
Winning authors
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../location.html" class="sub-item-link">
|
||
Location of 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="../faq.html#submit" class="sub-item-link">
|
||
How to enter
|
||
</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="../faq.html#submit">
|
||
How to enter
|
||
</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%2Fioccc-src.github.io%2Ftemp-test-ioccc%2Fnext%2Fguidelines.html">✓</a>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/navbar.empty.html -->
|
||
<!-- START: this line starts content from: inc/before-content.default.html -->
|
||
|
||
<div class="content" id="content">
|
||
|
||
<!-- END: this line ends content from: inc/before-content.default.html -->
|
||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||
|
||
<!-- BEFORE: 1st line of markdown file: next/guidelines.md -->
|
||
<!-- START: this line starts content from: inc/guidelines.closed.hdr -->
|
||
<h1 id="warning-these-guidelines-are-out-of-date">WARNING: These guidelines are OUT OF DATE</h1>
|
||
<p>These guidelines are a <strong>VERY TENTATIVE proposal</strong> for the next IOCCC
|
||
and are <strong>VERY LIKELY</strong> to be updated before the next IOCCC.
|
||
They are are provided as a <strong>VERY TENTATIVE</strong> hint at <strong>what
|
||
MIGHT</strong> be used in the next IOCCC. In some cases they might
|
||
even be a copy of the guidelines from the previous IOCCC.</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">asking questions</a>”
|
||
about these guidelines. You might also find the
|
||
FAQ in general useful, especially the
|
||
<a href="../faq.html#submit">FAQ section “How to enter: the bare minimum you need to know”</a>.</p>
|
||
<h1 id="the-ioccc-is-closed">The IOCCC is closed</h1>
|
||
<p>The IOCCC is <strong>NOT</strong> accepting new submissions at this time. See the
|
||
<a href="../years.html">IOCCC winning entries page</a> for the entries that have won the
|
||
IOCCC in the past.</p>
|
||
<p>Watch both <a href="../status.html">the IOCCC status page</a> and the
|
||
<a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> mastodon feed</a> for information about
|
||
future IOCCC openings.</p>
|
||
<p><strong>HINT to mastodon users</strong>: You may wish to refresh the <a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span>
|
||
mastodon feed</a> page and/or mastodon
|
||
app from time to time to view IOCCC mastodon updates.</p>
|
||
<!-- END: the next line ends content from: inc/guidelines.closed.hdr -->
|
||
<!-- This is the last line modified by the tool: bin/gen-status.sh -->
|
||
<h1 id="th-international-obfuscated-c-code-contest-official-guidelines">28th International Obfuscated C Code Contest Official Guidelines</h1>
|
||
<p 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.24 2024-12-02</strong>.
|
||
</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">
|
||
<h2 id="change-marks">Change marks</h2>
|
||
</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-MMM-DD HH:MM:SS UTC</strong> to <strong>YYYY-MMM-DD HH:MM:SS UTC</strong>.<br>
|
||
<strong>XXX - date/time is TBD - XXX</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 start of this IOCCC, 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>.
|
||
</p>
|
||
<p class="leftbar">
|
||
The submit URL should be active on or slightly before <strong>2024-MMM-DD HH:MM:SS UTC</strong>.<br>
|
||
<strong>XXX - date/time is TBD - XXX</strong>
|
||
</p>
|
||
<p class="leftbar">
|
||
The <a href="rules.html">IOCCC rules</a> and these <a href="guidelines.html">IOCCC
|
||
guidelines</a> will be available on the <a href="https://www.ioccc.org">Official IOCCC
|
||
website</a> on or slightly before start of this IOCCC. Please check our
|
||
FAQ on “<a href="../faq.html#submit">how to submit</a>”
|
||
to see how to submit entries, on or after the start of this IOCCC, to be sure
|
||
you are using the correct versions of these items before using the
|
||
IOCCC submission URL.
|
||
</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>. See below for more details about the example Makefile
|
||
for more help.
|
||
</p>
|
||
<p class="leftbar">
|
||
Submissions are in the form of 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">
|
||
You <strong>are encouraged</strong> to use <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/next/Makefile.example">this
|
||
Makefile.example</a>,
|
||
rather than the one at the <code>mkiocccentry</code> repo.
|
||
</p>
|
||
<p class="leftbar">
|
||
The IOCCC submission URL, <a href="../status.html#open">when the IOCCC is open</a>, is
|
||
<a href="https://submit.ioccc.org/">submit.ioccc.org</a>.
|
||
</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 less than 2^7+1 reasons why these <a href="guidelines.html">IOCCC
|
||
guidelines</a> seem obfuscated.
|
||
</p>
|
||
<p>Check out your program and be sure that it works. We sometimes make
|
||
the effort to debug 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>
|
||
<h2 id="mkiocccentry"><code>mkiocccentry</code></h2>
|
||
<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=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E">report as a bug at the
|
||
mkiocccentry issues
|
||
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">
|
||
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">
|
||
However, just because there are errors <strong>does not</strong> 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.
|
||
</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>
|
||
<p class="leftbar">
|
||
Below are the tools that <code>mkiocccentry(1)</code> will run.
|
||
</p>
|
||
<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; <code>chkentry(1)</code> will use the JSON parser
|
||
library <code>jparse(3)</code>; 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 original <code>jparse</code> code, co-developed by Landon and Cody Boone Ferguson in
|
||
2022, comes from the <a href="https://github.com/xexyl/jparse">jparse repo</a> <strong>but the
|
||
mkiocccentry tools use a <em>clone</em></strong> of this repo <strong>at a <em>specific</em> release</strong>.
|
||
Thus the <code>mkiocccentry</code> will at times be behind the <code>jparse</code> repo!
|
||
</p>
|
||
<p class="leftbar">
|
||
<p>You do <strong>NOT</strong> need to install <code>jparse</code>! The <code>mkiocccentry</code> tools link in the
|
||
static library from the <code>mkiocccentry</code> clone! This also goes for the
|
||
<a href="https://github.com/lcn2/dbg">dbg</a> and
|
||
<a href="https://github.com/lcn2/dyn_array">dyn_array</a> libraries. In other words,
|
||
<code>mkiocccentry</code> contains <strong>everything</strong> you need.</p>
|
||
<p>Jump to: <a href="#">top</a></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.
|
||
As we already discussed how to invoke this we will not include it here again.
|
||
</p>
|
||
<p class="leftbar">
|
||
This tool was originally part of a winning entry by Anthony C Howe, but with
|
||
some modifications over time, as things have changed.
|
||
</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=&labels=bug&projects=&template=bug_report.yml&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> 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. 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">
|
||
Please see the
|
||
FAQ on “<a href="../faq.html#chkentry">validating .auth.json and/or .info.json files</a>
|
||
for more details on this tool 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=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the mkiocccentry issues
|
||
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> do. In this case 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">
|
||
A tool that <a href="#txzchk">txzchk</a> runs is <code>fnamchk</code>. This is an important part of
|
||
its algorithm. If the filename is incorrect (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">
|
||
Note that the <code>txzchk(1)</code> tool uses <code>fnamchk(1)</code> tool as part of its algorithm.
|
||
Thus <code>mkiocccentry(1)</code> does not directly invoke <code>fnamchk(1)</code>, although we will
|
||
in the judging process.
|
||
</p>
|
||
<hr>
|
||
<p class="leftbar">
|
||
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>
|
||
<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=&labels=bug&projects=&template=bug_report.yml&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>.
|
||
</p>
|
||
<div id="bugs">
|
||
<h1 id="problemsbugs-in-tools">Problems/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=&labels=bug&projects=&template=bug_report.yml&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, and <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">
|
||
<h1 id="makefiles">Makefiles</h1>
|
||
</div>
|
||
<p class="leftbar">
|
||
<p>We <strong>recommend</strong> that you use the <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/next/Makefile.example">example
|
||
Makefile</a>,
|
||
renamed as <code>Makefile</code> of course, as the starting point for your submission’s
|
||
required <code>Makefile</code>. Feel free to modify the <code>Makefile</code> to suit your obfuscated
|
||
needs.</p>
|
||
<p class="leftbar">
|
||
The rest of this section will assume that you are using some variant of the
|
||
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/next/Makefile.example">example Makefile</a>,
|
||
renamed as <code>Makefile</code> of course.
|
||
</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>
|
||
<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 is <strong>OK</strong> to require your submission to not be 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 and adjust your <code>Makefile</code> accordingly.
|
||
</p>
|
||
<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">
|
||
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>
|
||
<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">
|
||
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 debug symbols:
|
||
</p>
|
||
<pre><code> OPT= -O0 -g3</code></pre>
|
||
<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 may 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 (see below for an example).
|
||
</p>
|
||
<p class="leftbar">
|
||
Additionally: some compilers like to warn about certain use of <code>char *</code>s which
|
||
is not only dubious itself, but it obviously can’t (always) be avoided, so you
|
||
should not worry about this either; this is the warning
|
||
<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"><code>-Weverything</code></a>”.
|
||
</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 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>
|
||
<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>For instance:</p>
|
||
<pre><code> CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation</code></pre>
|
||
<p class="leftbar">
|
||
<p>If you do add “<code>-Wno-foo</code>” to your Makefile, consider changing:</p>
|
||
<pre><code> CUNKNOWN=</code></pre>
|
||
<p>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> the OS, OS version and compiler that this shows up.
|
||
</p>
|
||
<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>
|
||
<p class="leftbar">
|
||
If you need to include a file on the command line, use
|
||
the <code>CINCLUDE</code> Makefile variable. For example:
|
||
</p>
|
||
<pre><code> CINCLUDE= -include stdio.h</code></pre>
|
||
<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>
|
||
<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
|
||
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/next/Makefile.example">example Makefile</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 use an edited version of the
|
||
<a href="try.sh">try.sh</a> example script (and if you have alternate code,
|
||
the same applies with the <a href="try.alt.sh">try.alt.sh</a>
|
||
example script). 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
|
||
</p>
|
||
<p class="leftbar">
|
||
You might wish to add <code>./try.sh</code>, and if you have alternate code,
|
||
<code>./try.alt.sh</code>, to the <code>try</code> rule in the Makefile you submit. See also the
|
||
FAQ on “<a href="../faq.html#try_scripts">submitting try.sh and try.alt.sh scripts</a>”.
|
||
</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 /* <-- don'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; /* <-- 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("The machine that goes BING!!\n");
|
||
}
|
||
| 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>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 <windows.h> /* 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 > 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 "See remarks section about alternate ways to compile"</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 <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/next/Makefile.example">example
|
||
Makefile</a>)
|
||
do not assume this sort of code will work:
|
||
</p>
|
||
<pre><code> char *T = "So many primes, so little time!";
|
||
...
|
||
T[14] = ';'; /* 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[] = "Is this OK";
|
||
b[9] = 'k'; /* 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><== 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><a href="rules.html#rule13">Rule 13</a> states any C source that fails to compile because of unescaped
|
||
octets with the high bit set (octet value >= 128) <strong>might</strong> be rejected.
|
||
Instead of unescaped octets, you should use or escapes:</p>
|
||
<pre><code>
|
||
/* 123456789 123456789 123456789 123456 */
|
||
char *foo = "This string is 36 octets in length \263";
|
||
/* This octet requires 4 octets of source ^^^^ */
|
||
if (strlen(foo) == 36) printf("foo is 36 octets plus a final NUL\n");
|
||
else printf("This code should not print this message\n");</code></pre>
|
||
<p 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><<– 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>
|
||
are original works (see the <a href="https://github.com/xexyl/jparse/">jparse repo</a> for
|
||
the original), 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 part 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 <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/next/Makefile.example">example
|
||
Makefile</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>BTW: None of the entries claiming to be from Peter Honeyman have ever
|
||
won an award. So it is theoretically possible that Peter Honeyman
|
||
did submit 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 © 1984-2024 by Landon Curt Noll:
|
||
<a href="https://creativecommons.org/faq/#what-does-some-rights-reserved-mean"
|
||
target="_blank"
|
||
rel="license noopener noreferrer">Some Rights Reserved</a></h3>
|
||
<p>
|
||
This work is <b>licensed by Landon Curt Noll</b> under
|
||
<b><a href="https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1"
|
||
target="_blank"
|
||
rel="license noopener noreferrer"
|
||
style="display:inline-block;">CC BY-SA 4.0</a></b>.
|
||
<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;"
|
||
src="../png/cc.png"
|
||
alt="cc inside circle symbol">
|
||
<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;"
|
||
src="../png/by.png"
|
||
alt="person inside circle symbol">
|
||
<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;"
|
||
src="../png/sa.png"
|
||
alt="arrow looping back on itself inside circle symbol"><br>
|
||
You should <b>carefully review</b> the
|
||
<b><a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.en"
|
||
target="_blank"
|
||
rel="license noopener noreferrer">CC BY-SA 4.0 LEGAL CODE</a></b>
|
||
before using the licensed material.<br>
|
||
You may wish to review the
|
||
<b><a href="../license.html"
|
||
target="_blank"
|
||
rel="license noopener noreferrer">highlights of some of the key features and terms</a></b>
|
||
of <b>CC BY-SA 4.0</b>.<br>
|
||
</p>
|
||
</div>
|
||
|
||
<div id="coda"><h3>Coda</h3>
|
||
<p>
|
||
<a href="https://validator.w3.org/nu/?doc=https%3A%2F%2Fioccc-src.github.io%2Ftemp-test-ioccc%2Fnext%2Fguidelines.html" rel="nofollow">Nu HTML check this web page</a><br>
|
||
<a href="#top">Jump to top</a> <a href="#content">Jump to Content</a>
|
||
</p>
|
||
</div>
|
||
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/footer.default.html -->
|
||
<!-- START: this line starts content from: inc/bottom.default.html -->
|
||
|
||
</body>
|
||
</html>
|
||
|
||
<!-- END: this line ends content from: inc/bottom.default.html -->
|