Attempt to fix HTML5 errors. Remove Makefile section from Guidelines as this is in the FAQ. Added links to Makefile FAQ in Guidelines. Ran `make quick_www` to perform the above TODO: Complete the correction for issue #244 ("Restore guidelines"). TODO: Continue to revise and improve the IOCCC guidelines as needed. TODO: Fix typos/nits in the `next/guidelines.md` if needed. TODO: Fix typos/nits in the `next/rules.md` if needed.
1502 lines
78 KiB
HTML
1502 lines
78 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/rules.html" class="sub-item-link">
|
||
IOCCC rules
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../next/guidelines.html" class="sub-item-link">
|
||
IOCCC guidelines
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../markdown.html" class="sub-item-link">
|
||
Markdown guidelines
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../SECURITY.html" class="sub-item-link">
|
||
Security policy
|
||
</a>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
FAQ
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html" class="sub-item-link">
|
||
Frequently asked questions
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../quick-start.html#enter" class="sub-item-link">
|
||
Enter the IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html#compiling" class="sub-item-link">
|
||
Compiling entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html#running_entries" class="sub-item-link">
|
||
Running entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html#help" class="sub-item-link">
|
||
How to help
|
||
</a>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
About
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
|
||
<div class="outfit-font">
|
||
<a href="../index.html" class="sub-item-link">
|
||
Home page
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../social.html" class="sub-item-link">
|
||
IOCCC social media
|
||
</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/rules.html">
|
||
IOCCC rules
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../next/guidelines.html">
|
||
IOCCC guidelines
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../markdown.html">
|
||
Markdown guidelines
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../SECURITY.html">
|
||
Security policy
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
FAQ
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html">
|
||
Frequently asked questions
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../quick-start.html#enter">
|
||
Enter the IOCCC
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html#compiling">
|
||
Compiling entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html#running_entries">
|
||
Running entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html#help">
|
||
How to help
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
About
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../index.html">
|
||
Home page
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../social.html">
|
||
IOCCC social media
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../about.html">
|
||
About the IOCCC
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../judges.html">
|
||
The judges
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../contact.html">
|
||
Contact us
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
</div>
|
||
|
||
<script>
|
||
var headerOpenMenuButton = document.getElementById("header-open-menu-button");
|
||
var headerCloseMenuButton = document.getElementById("header-close-menu-button");
|
||
var mobileMenuPanel = document.getElementById("mobile-menu-panel");
|
||
|
||
headerOpenMenuButton.addEventListener("click", () => {
|
||
headerOpenMenuButton.classList.remove("topbar-mobile-menu");
|
||
headerOpenMenuButton.classList.add("hide-content");
|
||
|
||
headerCloseMenuButton.classList.remove("hide-content");
|
||
headerCloseMenuButton.classList.add("topbar-mobile-menu");
|
||
|
||
mobileMenuPanel.classList.remove("hide-content");
|
||
mobileMenuPanel.classList.add("topbar-mobile-panel");
|
||
});
|
||
|
||
headerCloseMenuButton.addEventListener("click", () => {
|
||
headerCloseMenuButton.classList.remove("topbar-mobile-menu");
|
||
headerCloseMenuButton.classList.add("hide-content");
|
||
|
||
mobileMenuPanel.classList.add("hide-content");
|
||
mobileMenuPanel.classList.remove("topbar-mobile-panel");
|
||
|
||
headerOpenMenuButton.classList.add("topbar-mobile-menu");
|
||
headerOpenMenuButton.classList.remove("hide-content");
|
||
});
|
||
</script>
|
||
|
||
<!-- END: this line ends content from: inc/topbar.default.html -->
|
||
<!-- START: this line starts content from: inc/header.default.html -->
|
||
|
||
<div class="header">
|
||
<a href="../2011/zucker/index.html">
|
||
<img src="../png/ioccc.png"
|
||
alt="IOCCC image by Matt Zucker"
|
||
width=300
|
||
height=110>
|
||
</a>
|
||
<h1>The International Obfuscated C Code Contest</h1>
|
||
<h2>IOCCC Guidelines</h2>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/header.default.html -->
|
||
<!-- START: this line starts content from: inc/navbar.empty.html -->
|
||
|
||
<div class="navbar">
|
||
<a class="Right" href="https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.ioccc.org%2Fnext%2Fguidelines.html">✓</a>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/navbar.empty.html -->
|
||
<!-- START: this line starts content from: inc/before-content.default.html -->
|
||
|
||
<div class="content" id="content">
|
||
|
||
<!-- END: this line ends content from: inc/before-content.default.html -->
|
||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||
|
||
<!-- BEFORE: 1st line of markdown file: next/guidelines.md -->
|
||
<h1 id="th-international-obfuscated-c-code-contest-official-guidelines">29th International Obfuscated C Code Contest Official Guidelines</h1>
|
||
<p class="leftbar">
|
||
Copyright © 2025 Leonid A. Broukhis and Landon Curt Noll.
|
||
</p>
|
||
<p>All Rights Reserved. Permission for personal, education or non-profit use is
|
||
granted provided 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>
|
||
<h1 id="guidelines-version">Guidelines Version</h1>
|
||
<p class="leftbar">
|
||
These IOCCC guidelines are version <strong>29.01 2025-11-29</strong>.
|
||
</p>
|
||
<p class="leftbar">
|
||
The <span style="font-size:28px;"><b>|</b></span> symbol indicates an <strong>change</strong> from the previous IOCCC.
|
||
</p>
|
||
<p class="leftbar">
|
||
Because the <strong>IOCCC29</strong> guidelines was a substantial rewrite, only <strong>important changes</strong> from <strong>IOCCC28</strong> have been marked.
|
||
</p>
|
||
<p>Be sure to read the <a href="rules.html">IOCCC rules</a>.</p>
|
||
<div id="guideline2">
|
||
<div id="guideline-2---size">
|
||
<div id="guideline2-size">
|
||
<h1 id="guidelines-for-rule-2---size-restrictions">Guidelines for <a href="rules.html#rule2-size-restrictions">Rule 2 - Size restrictions</a></h1>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p class="leftbar">
|
||
You should pay attention to our observations on
|
||
<a href="../2024/index.html#code-size-and-rule-2">code size and Rule 2 remarks for IOCCC28</a>.
|
||
</p>
|
||
<p>Your submission must satisfy <strong>BOTH</strong> the
|
||
<a href="rules.html#rule2a-gross-size">Rule 2a Gross Size</a>
|
||
<strong>AND</strong>
|
||
<a href="rules.html#rule2b-net-size">Rule 2b Net Size</a> rules.</p>
|
||
<p>To check your code against
|
||
<a href="rules.html#rule2-size">Rule 2 - Size restrictions</a>, use the <code>iocccentry(1)</code> tool.
|
||
For example:</p>
|
||
<pre><code> iocccsize prog.c</code></pre>
|
||
<p>The IOCCC size tool algorithm can 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 bytes 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>’ byte immediately
|
||
before the end of file.</p>
|
||
<p>ASCII whitespace includes ASCII tab, ASCII space, ASCII newline, ASCII formfeed, and ASCII carriage return.</p>
|
||
<p>When ‘<code>;</code>’, ‘<code>{</code>’ or ‘<code>}</code>’ are within a C string, they may still not be
|
||
counted by the IOCCC size tool.</p>
|
||
</blockquote>
|
||
<p>In cases where the above summary and the algorithm implemented by
|
||
the IOCCC size tool <code>iocccsize(1)</code> conflict, the algorithm implemented
|
||
by the minimum required version of <code>iocccsize(1)</code> is preferred by the <a href="../judges.html">IOCCC
|
||
judges</a>.</p>
|
||
<p>Make sure <code>iocccsize</code> does not flag any issues with your <code>prog.c</code>.</p>
|
||
<p>There a much less need to <code>#define</code> C reserved words in an effort
|
||
to get around the size limits of
|
||
<a href="rules.html#rule2-size">Rule 2 - Size restrictions</a>
|
||
because of the <code>iocccsize(1)</code> algorithm.</p>
|
||
<p>Yes Virginia, <strong>the previous guideline sentence is an important hint</strong>!</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline3">
|
||
<div id="guideline-3---register">
|
||
<h1 id="guidelines-for-rule-3---register-for-the-ioccc">Guidelines for <a href="rules.html#rule3-register">Rule 3 - Register for the IOCCC</a></h1>
|
||
</div>
|
||
</div>
|
||
<p>See FAQ on “<a href="../faq.html#author_handle_faq">What is an author handle?</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline7">
|
||
<div id="guideline-7---original-work">
|
||
<h1 id="guidelines-for-rule-7---original-work">Guidelines for <a href="rules.html#rule7-original-work">Rule 7 - Original Work</a></h1>
|
||
</div>
|
||
</div>
|
||
<p>While it is <strong>NOT</strong> required, you are allowed to use tools or services such as:</p>
|
||
<ul>
|
||
<li>Code generators</li>
|
||
<li>Static and runtime code analysis tools</li>
|
||
<li>Machine learning tools</li>
|
||
<li>Natural language models</li>
|
||
<li>Large language models (LLMs)</li>
|
||
<li>Code copilot tools</li>
|
||
<li>So called “<em>AI services</em>”</li>
|
||
<li>Etc.</li>
|
||
</ul>
|
||
<p>The IOCCC has a rich history of remarkable winning entries created by
|
||
authors who skillfully employed various techniques to develop their code.
|
||
If you do make use of such tools or services, then we <strong>ENCOURAGE you to
|
||
describe how you used such tools</strong> in your <code>remarks.md</code> file.</p>
|
||
<p>In short: You created it, you own it, its an original work, or you have explicit permission to the work.</p>
|
||
<p>See FAQ on “<a href="../faq.html#ai">May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline11">
|
||
<div id="guideline-11---abuse">
|
||
<h1 id="guidelines-for-rule-11---legal-rule-abuse">Guidelines for <a href="rules.html#rule11-legal-rule-abuse">Rule 11 - Legal rule abuse</a></h1>
|
||
</div>
|
||
</div>
|
||
<p>We do realize that there are holes in the <a href="rules.html">IOCCC rules</a>, and invite
|
||
submitters to attempt to apply creative rule interpretation. A rule abuse though, even
|
||
if not rewarded, may result in a subsequent rule change for future contests.</p>
|
||
<p>We sometime award ‘<strong>Best abuse of the rules</strong>’ or ‘<strong>Worst abuse of the rules</strong>’,
|
||
or some variation, to a submission that creatively attempts to exploit a holes in the
|
||
<a href="rules.html">IOCCC rules</a>.</p>
|
||
<p>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.</p>
|
||
<p>Or, maybe not. :-)</p>
|
||
<p>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 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> (especailly <a href="./rules.html#rule-17---packaging">Rule 17 -
|
||
Packaging</a> ). A submission that violates the
|
||
<a href="rules.html">rules</a> in the opinion of the <a href="../judges.html">IOCCC judges</a>,
|
||
<strong>WILL</strong> be disqualified. <strong><em>RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!</em></strong></p>
|
||
<p>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, plead, beg,
|
||
why you consider your rule abuse to be allowed under the
|
||
<a href="rules.html">IOCCC rules</a>. Humor 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>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, making sure to note in the one that does not abuse the rules that
|
||
this is another version, so that the judges do not assume you uploaded it by
|
||
mistake.</p>
|
||
<p>If you do bypass the <code>mkiocccentry(1)</code> warnings about
|
||
<a href="rules.html#rule-2a-gross-size">Rule 2a - Gross Size</a>
|
||
and/or about
|
||
<a href="rules.html#rule-2b-net-size">Rule 2b - Net Size</a>
|
||
or any other
|
||
rule and submit a submission anyway, you <strong>MUST</strong> try to justify why the IOCCC
|
||
<a href="../judges.html">IOCCC judges</a> should not reject your submission due to a rule
|
||
violation, and you would be wise to do this towards the top of your <code>remarks.md</code>
|
||
file.</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 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.</p>
|
||
<p>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 can 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 part of the overall contest. Even so, one might 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, balloning specifications, and requirements from marketing, sales,
|
||
product management and even from customers themselves on an 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="guideline15">
|
||
<div id="guideline-15---building">
|
||
<h1 id="guidelines-for-rule-15---gnu-makefile">Guidelines for <a href="rules.html#rule15-gnu-makefile">Rule 15 - GNU Makefile</a></h1>
|
||
</div>
|
||
</div>
|
||
<p>You may use <code>git,</code> or services such as <a href="https://www.github.com">GitHub</a>
|
||
to develop and maintain your submission. However, we <strong>DISLIKE</strong>
|
||
submissions that <strong>require</strong> such services in order to build/compile your submission.</p>
|
||
<p>Submissions will be judged in an environment that has no <strong>IDE</strong>.
|
||
Any submission that fails to compile/build because it requires
|
||
an <strong>IDE</strong> will be rejected.</p>
|
||
<p>We will use the <code>GNU make(1)</code> tool, your <code>Makefile</code>, as well as tools found in the
|
||
<a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a>
|
||
environments, and commonly found on systems that reasonably conform to the
|
||
<a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a>
|
||
in the building and compiling of your submission.</p>
|
||
<p>Your Makefile <strong>MUST</strong> be compatible with GNU <code>make</code> and we suggest you use
|
||
<a href="Makefile.example">Makefile.example</a> as a template, renamed as Makefile of
|
||
course.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#makefile_details">What are the detailed recommendations for a submission Makefile?</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline17">
|
||
<div id="guideline-17---packaging">
|
||
<div id="guideline17-mkiocccentry">
|
||
<h1 id="guidelines-for-rule-17---use-mkiocccentry">Guidelines for <a href="rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a></h1>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>We <strong>STRONGLY</strong> recommend you <strong>do</strong> install the most recent release of
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
|
||
As use of using older versions of the mkiocccentry toolkit to are <strong>HIGHLY LIKELY</strong> to be <strong>REJECTED</strong>!</p>
|
||
<p>If you submit your own JSON files (other than <code>.auth.json</code> and
|
||
<code>.info.json</code>) then they do <strong>NOT</strong> have to be valid JSON.</p>
|
||
<p>However, if you do provide invalid JSON files, <strong>PLEASE</strong>
|
||
document and <strong>clearly explain</strong> this in your <code>remarks.md</code> file.</p>
|
||
<p class="leftbar">
|
||
An <em>extra file</em> is defined as a file that is not <code>prog.c</code>, <code>prog.alt.c</code>,
|
||
<code>try.sh</code>, <code>try.alt.sh</code>, <code>remarks.md</code>, <code>Makefile</code>, <code>.auth.json</code> and <code>.info.json</code>:
|
||
unless it’s not in the top level directory, in which case it <strong>IS</strong> an <em>extra
|
||
file</em>.
|
||
</p>
|
||
<p class="leftbar">
|
||
The non-extra files (<code>prog.c</code>, <code>prog.alt.c</code>,
|
||
<code>try.sh</code>, <code>try.alt.sh</code>, <code>remarks.md</code>, <code>Makefile</code>, <code>.auth.json</code> and <code>.info.json</code>)
|
||
are considered <em>free files</em>, and to not count towards the
|
||
<a href="rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a>
|
||
limit of <strong>31</strong> <em>extra files</em>.
|
||
</p>
|
||
<p>If you use an optional filename for something other than their intended use
|
||
in order to get past the file limit, we will consider that an abuse of rules.</p>
|
||
<p>The <code>mkiocccentry</code> generated tarball does <strong>NOT</strong> reveal who you are! For this
|
||
reason, the tarball <strong>MUST</strong> be a <strong>v7 format</strong> tarball.</p>
|
||
<p>You should NOT use a tarball as an <em>extra file</em> for a test-suite unless you
|
||
have a very good reason for this: if you do include a tarball as an <em>extra file</em>,
|
||
then you <strong>MUST</strong> specify why in your <code>remarks.md</code> file.</p>
|
||
<p>If you <strong>DO</strong> include a tarball an <em>extra file</em>, and the build process or the program extracts
|
||
said tarball(s), the make <code>clobber</code> rule <strong>MUST</strong> remove the extracted files.</p>
|
||
<p>Instead of including a large test-suite that requires a lot of files as part of your submission,
|
||
and your submission doesn’t require the test-suite to be available to run,
|
||
then in your <code>remarks.md</code> a URL where such a test-suite may be downloaded from
|
||
and how to use the test-suite to test your submission.</p>
|
||
<p>If you <strong>DO</strong> include a tarball then make sure it uses the v7 format. See the
|
||
FAQ on “<a href="../faq.html#extra-files">extra files</a>”
|
||
for details on how to make a v7 tarball.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#try_scripts">What should I do with the <code>try.sh</code> and <code>try.alt.sh</code> scripts?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#auth_json">What is a <code>.auth.json</code> file?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#info_json">What is a <code>.info.json</code> file?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#chksubmit">How can I validate my submission directory?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#file_perms">What permissions may my files be and what if I need different permissions?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#makefile_details">What are the detailed recommendations for a submission Makefile?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#rule17">What are the details behind Rule 17 - Use mkiocccentry?</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="mkiocccentry">
|
||
|
||
</div>
|
||
<div id="mkiocccentry_toolkit">
|
||
|
||
</div>
|
||
<h1 id="guidelines-for-the-mkiocccentry-toolkit">Guidelines for the mkiocccentry toolkit</h1>
|
||
<p>The <a href="https://submit.ioccc.org">IOCCC submit server</a>, and related services
|
||
use the <strong>most recent version</strong> of the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>:
|
||
submissions that package using older versions of the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
|
||
are <strong>LIKELY</strong> to be <strong>REJECTED</strong>!</p>
|
||
<p>You <strong>REALLY SHOULD</strong> use the latest <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
|
||
are <strong>LIKELY</strong> to be <strong>REJECTED</strong>! So you <strong>REALLY SHOULD</strong> use the latest <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
|
||
to package your own submission.</p>
|
||
<p>The <code>mkiocccentry(1)</code> tool runs a number of checks by way of these
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a> tools:</p>
|
||
<ul>
|
||
<li>iocccsize(1)</li>
|
||
<li>txzchk(1)</li>
|
||
<li>fnamchk(1)</li>
|
||
<li>chksubmit(1)</li>
|
||
<li>chkentry(1)</li>
|
||
</ul>
|
||
<p>Do <strong>NOT</strong> use <code>txzchk(1)</code> or <code>fnamchk(1)</code> command line options that are labeled
|
||
“<strong>for TESTING purposes</strong>” in their respective man pages.</p>
|
||
<p>Do <strong>NOT</strong> use <code>fnamchk(1)</code> command line options that are labeled “<strong>for TESTING purposes</strong>”
|
||
in the <code>fnamchk(1)</code> man page.</p>
|
||
<p>Do <strong>NOT</strong> use <code>chkentry(1)</code> command line options that are labeled “<strong>for the use by the IOCCC judges only</strong>”
|
||
in the <code>chksubmit(1)</code> (or <code>chkentry(1)</code>) man page(s).
|
||
Similarly do <strong>NOT</strong> use <code>chkentry(1)</code> command line options marked “<strong>for the use
|
||
by the IOCCC judges only</strong>” in the <code>chkentry(1)</code> man page.</p>
|
||
<p>To view <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a> man pages,
|
||
while your current directory is the top of the source tree:</p>
|
||
<pre><code>man soup/man/man1/mkiocccentry.1
|
||
man soup/man/man1/iocccsize.1
|
||
man soup/man/man1/txzchk.1
|
||
man test_ioccc/man/man1/fnamchk.1
|
||
man soup/man/man1/chksubmit.1
|
||
man soup/man/man1/chkentry.1</code></pre>
|
||
<p>The above <code>man(1)</code> commands will show the toolkit man pages without having to install them first.</p>
|
||
<p>So that you do not have to repeatedly answer all the <code>mkiocccentry(1)</code> questions,
|
||
use <code>mkiocccentry -a answers ...</code> to create a file containing the answers you first give,
|
||
so later enter <code>mkiocccentry -i answers ...</code> to reuse those same answers.</p>
|
||
<p>The <code>mkiocccentry -A answers ...</code> does the same thing except that the <strong>answers file will be overwritten</strong>.</p>
|
||
<p>The <code>mkiocccentry -i answers ...</code> will still be required to confirm “<em>Yes/No</em>” questions.</p>
|
||
<p>Use <code>mkiocccentry -Y -i answers ..</code> to force a yes answers with <strong>great caution</strong>
|
||
because it might force a yes answer to something you do <strong>NOT</strong> want, such as a
|
||
change in your code that violates a detected rule.
|
||
The <code>mkiocccentry -i answers ..</code> will still be required to confirm “<em>Yes/No</em>” questions.
|
||
While <code>mkiocccentry -Y -i answers ..</code> will force yes answers, use with <strong>great caution</strong>,
|
||
because it might force a yes answer to something you do <strong>NOT</strong> want.</p>
|
||
<p>To help with not having to repeatedly enter a UUID, put your UUID into a file and use
|
||
<code>mkiocccentry -u uuidfile ...</code>, or use <code>mkiocccentry -U UUID ...</code> to give the <code>UUID</code>
|
||
on the command line.</p>
|
||
<p>If you wish to <strong>test</strong> that your submission passes the <code>mkiocccentry(1)</code> tests
|
||
without having to type in answers each time, you can use the <code>-d</code> or <code>-s seed</code>
|
||
option to <code>mkiocccentry</code> for the tool to pseudo-randomly create answers for you.
|
||
For example:</p>
|
||
<pre><code>mkiocccentry -d workdir topdir</code></pre>
|
||
<p>Do <strong>NOT</strong> submit a tarball formed by <code>mkiocccentry -d ..</code> <strong>OR</strong> by
|
||
<code>mkiocccentry -s seed ..</code> <strong>OR</strong> by using the <code>test</code> UUID!</p>
|
||
<p>The <code>mkiocccentry(1)</code> tool creates an <code>xz(1)</code> compressed <strong>v7 format</strong> tarball using a <code>tar(1)</code>
|
||
command of the form:</p>
|
||
<pre><code>cd workdir/UUID-slot_num && tar --format=v7 -cJf submit.UUID-slot_num.timestamp.txz UUID-slot_num</code></pre>
|
||
<p>In many places the <code>mkiocccentry(1)</code> tool will prompt you to verify what you input, allowing you to
|
||
correct details as you go along.</p>
|
||
<p>Pressing the “<em>enter key</em>” at the <code>mkiocccentry(1)</code> tool prompts will allow you
|
||
to proceed with a default, however make sure the default is the <strong>CORRECT</strong>
|
||
answer.</p>
|
||
<p>The <code>mkiocccentry(1)</code> tool will use code from <code>iocccsize(1)</code> which detects a number of
|
||
issues (such as <a href="rules.html#rule2-size">Rule 2 - Size</a>) that you may ignore,
|
||
however ignoring such issues <strong>comes with a significant level of risk!</strong></p>
|
||
<p>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>The use of <code>mkiocccentry -W ....</code> is <strong>highly discouraged</strong> as this may ignore
|
||
warnings about a problem that may cause your submission to be <strong>REJECTED!</strong>”</p>
|
||
<p>If <code>mkiocccentry</code> encounters an <strong>error</strong>, the program will exit and the xz
|
||
compressed tarball <strong>will NOT be generated</strong>: this is a <strong>feature, not a bug</strong>!</p>
|
||
<p>If you encounter a <strong>bug</strong> with the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
|
||
<strong>PLEASE run the <code>bug_report.sh</code> script to help us out here!</strong></p>
|
||
<p>While you don’t have to install the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>,
|
||
then in order to run a tool outside the repo directory
|
||
you will have to specify <code>mkiocccentry(1)</code> command line options to locate required tools
|
||
such as <code>chkentry(1)</code> (<code>mkiocccentry -C chkentry ..</code>), <code>txzchk(1)</code> (<code>mkiocccentry -T txzchk ..</code>),
|
||
and <code>fnamchk(1)</code> (<code>mkiocccentry -F fnamchk ..</code>).</p>
|
||
<p>The <code>mkiocccentry(1)</code> tool will ignore any filename or directory that begins with a period (<code>.</code>).</p>
|
||
<p>The <code>mkiocccentry(1)</code> tool will ignore all files that begin with <code>COPYING</code>, <code>COPYRIGHT</code>, and <code>LICENSE</code>, regardless
|
||
of filename case.</p>
|
||
<p>The <code>mkiocccentry(1)</code> tool will reject any of the following files if they are found directly under
|
||
the top level directory (<code>topdir</code>):</p>
|
||
<ul>
|
||
<li>README.md</li>
|
||
<li>index.html</li>
|
||
<li>prog</li>
|
||
<li>prog.alt</li>
|
||
<li>prog.alt.o</li>
|
||
<li>prog.orig.c</li>
|
||
<li>filenames matching the <code>[0-9][0-9][0-9][0-9]_*.tar.bz2</code> file glob</li>
|
||
</ul>
|
||
<p>The files listed in the above list are allowed to exist in sub-directories: just <strong>NOT</strong> directly under
|
||
the top level directory (<code>topdir</code>).</p>
|
||
<p>The <code>mkiocccentry(1)</code> tool evaluates all filenames and directory names in a case
|
||
independent way: thus <code>FOO</code>, <code>Foo</code>, and <code>foo</code> are considered the <strong>SAME</strong> file
|
||
even if your filesystem doesn’t do the same.</p>
|
||
<p>Having two or more filenames that differ only by case <strong>WILL</strong> lead to problems
|
||
because of the previous statement.</p>
|
||
<p>When the <code>mkiocccentry(1)</code> tool ignores a file, that file is <strong>NOT</strong> included as
|
||
part of your submission.</p>
|
||
<p>When the <code>mkiocccentry(1)</code> tool ignores a directory, that directory,
|
||
and everything under that directory is <strong>NOT</strong> included as part of
|
||
your submission.</p>
|
||
<p>The <code>mkiocccentry(1)</code> tool will ignore all symlinks.</p>
|
||
<p>Creating a directory directly under the top level directory (<code>topdir</code>)
|
||
that is normally considered to be a regular file, such as a directory
|
||
named <code>Makefile</code>, <code>prog.alt.c</code>, <code>prog.c</code>, <code>remarks.md</code>, <code>try.alt.sh</code>,
|
||
or <code>try.sh</code> is <strong>NOT</strong> a good idea and will likely cause the
|
||
<code>mkiocccentry(1)</code> tool to abort with a <strong>fatal error</strong>.</p>
|
||
<p>The required <code>Makefile</code> and <code>remarks.md</code> files may <strong>NOT</strong> be empty. This
|
||
does not mean just 0 bytes but also that it <strong>MUST</strong> have <strong>content</strong>, and
|
||
content that is relevant (e.g. a Makefile with just comments is <strong>NOT</strong>
|
||
allowed). However, with the exception of the <code>Makefile</code>, the <code>mkiocccentry(1)</code>
|
||
tool will <strong>ONLY</strong> check file size.</p>
|
||
<p>If the optional file <code>try.alt.sh</code>, or <code>try.sh</code> exists and is an empty file,
|
||
the <code>mkiocccentry(1)</code> tool will abort with a <strong>fatal error</strong>.</p>
|
||
<p>If the <code>mkiocccentry(1)</code> tool encounters anything that isn’t a file, isn’t a
|
||
directory, and isn’t a symlink (which the tool ignores), the <code>mkiocccentry(1)</code>
|
||
tool to abort with a <strong>fatal error</strong>.</p>
|
||
<p>See
|
||
FAQ on “<a href="../faq.html#mkiocccentry_bugs">How do I report bugs in an <code>mkiocccentry</code> tool?</a>”.</p>
|
||
<p>See <a href="rules.html#rule11-legal-rulea-abuse">Rule 11 - Legal rule abuse</a> for warnings about ignoring <code>mkiocccentry(1)</code> tool warnings.</p>
|
||
<p>See
|
||
FAQ on “<a href="../faq.html#fnamchk">What is the <code>fnamchk</code> tool?</a>”.</p>
|
||
<p>See
|
||
FAQ on “<a href="../faq.html#about_mkiocccentry">What is mkiocccentry in simple terms?</a>”.</p>
|
||
<p>See
|
||
FAQ on “<a href="../faq.html#mkiocccentry">What is the mkiocccentry tool, how do I obtain it and how do I use it</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="general">
|
||
<h1 id="general-guidelines">General Guidelines</h1>
|
||
</div>
|
||
<h1 id="general-overall-guidelines">General Overall Guidelines</h1>
|
||
<p>These <a href="guidelines.html">guideline</a> are <strong>hints</strong> and <strong>suggestions</strong>, <strong>NOT</strong> <a href="rules.html">IOCCC rules</a>.</p>
|
||
<p>While submissions that violate <a href="guidelines.html">guideline</a> are allowed,
|
||
submissions that remain within the <a href="guidelines.html">IOCCC guidelines</a> are preferred.</p>
|
||
<p>You are encouraged to review the following <a href="../faq.html">FAQs</a>:</p>
|
||
<ul>
|
||
<li><p><a href="../quick-start.html#enter">How to enter the IOCCC</a></p></li>
|
||
<li><p><a href="../faq.html#mkiocccentry">Obtaining and compiling the most recent mkiocccentry toolkit</a></p></li>
|
||
<li><p><a href="../next/submit.html">How to upload your submission</a></p></li>
|
||
</ul>
|
||
<p>While the contest is <strong><a href="../faq.html#open">open</a></strong>, you may modify your
|
||
previously uploaded submission by rebuilding your submission with the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>,
|
||
and then re-uploading it to <strong>the same slot number</strong> on the
|
||
<a href="https://submit.ioccc.org">submit server</a>.</p>
|
||
<p>The <strong>official locale</strong> of the <strong>IOCCC</strong> is <strong>C</strong>.</p>
|
||
<p>You are <strong>encouraged</strong> to examine the <a href="../years.html">winners of previous contests</a>.</p>
|
||
<p>Because <a href="rules.html">rules</a> change from year to year, some <a href="../years.html">winning entries</a>
|
||
of the past may be rejected this year.</p>
|
||
<p>What was <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>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 (such as <code>clang-format(1)</code>)</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 as in certain cases,
|
||
a test is not important.</p>
|
||
<p>Submissions that compete for the
|
||
‘<strong>strangest/most creative source layout</strong>’ need not do as well as
|
||
others in terms of their algorithm.</p>
|
||
<p>Given two submissions, we are more inclined to pick the submission that
|
||
does something interesting when it’s executed.</p>
|
||
<p><strong>IMPORTANT:</strong> Be sure that <strong>your submission works</strong> as documented in your <code>remarks.md</code> file.</p>
|
||
<p>We sometimes make an 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 otherwise excellent submissions
|
||
fall down because they didn’t work as documented.</p>
|
||
<p>If you submission has bugs and/or mis-features, you are <strong>MUCH BETTER</strong> off
|
||
documenting such bugs and/or mis-features in your <code>remarks.md</code> file.</p>
|
||
<p>Consider an example of a <a href="https://en.wikipedia.org/wiki/Prime_number">prime number</a>
|
||
printing program that claims that 16 is a prime number.
|
||
Noting such a bug in your <code>remarks.md</code> file could save your submission:</p>
|
||
<blockquote>
|
||
<p>“<em>this submission sometimes prints the 4th power of a prime by mistake</em>”</p>
|
||
</blockquote>
|
||
<p>Sometimes a strange bug or (mis-)feature can even help the submission! Of course, a correctly
|
||
working submission might be better.</p>
|
||
<p>We tend to look down on a
|
||
<a href="https://en.wikipedia.org/wiki/Prime_number">prime number</a>
|
||
printer that claims that 16 is a prime number.
|
||
Clever people will note that 16 might be prime under certain conditions. ;-)
|
||
Wise people, when submitting something clever
|
||
will <strong>fully explain such cleverness</strong> 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>Consider using misleading or subtle tricks layered on top of or under
|
||
an appropriate level of obfuscation.</p>
|
||
<p>A clean looking program with
|
||
misleading comments and variable names might be a <strong>VERY GOOD START</strong>
|
||
to a great submission!</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="likes">
|
||
|
||
</div>
|
||
<div id="dislikes">
|
||
|
||
</div>
|
||
<h1 id="our-likes-and-dislikes">OUR LIKES AND DISLIKES:</h1>
|
||
<p>We <strong>VERY MUCH LIKE</strong> submissions that use an edited variant of the
|
||
example Makefile, as described and linked to in the <a href="#makefile">Makefile section</a>,
|
||
renamed as <code>Makefile</code> of course. This makes it easier for the <a href="../judges.html">IOCCC judges</a>
|
||
to test your submission. And if your submissions wins, it makes it easier to integrate it into
|
||
the <a href="https://www.ioccc.org/index.html">Official IOCCC winner website</a>.</p>
|
||
<p>We <strong>VERY MUCH LIKE</strong> submissions that have some educational value. This does <strong>NOT</strong> mean
|
||
that your submission should not be obfuscated but rather that the IOCCC has moved away from
|
||
the idea of “spoilers”. You should not encrypt or rot13 content in your <code>remarks.md</code> file.</p>
|
||
<p>It is <strong>VERY MUCH</strong> appreciated if your remarks have some educational
|
||
value. And although educational value is not required, it is an
|
||
<strong>EXCELLENT</strong> bonus.</p>
|
||
<p>We <strong>LIKE</strong> submissions that use an edited version of the
|
||
<code>try.sh</code> example script (and if you have alternate code,
|
||
the same applies with the <code>try.alt.sh</code> script):</p>
|
||
<ul>
|
||
<li><p><a href="https://github.com/ioccc-src/winner/blob/master/next/try.sh">view example try.sh</a></p></li>
|
||
<li><p><a href="try.sh">download example try.sh</a></p></li>
|
||
<li><p><a href="https://github.com/ioccc-src/winner/blob/master/next/try.alt.sh">view example try.alt.sh</a></p></li>
|
||
<li><p><a href="try.alt.sh">download example try.alt.sh</a></p></li>
|
||
</ul>
|
||
<p>Of course, it is quite possible that only one invocation is
|
||
possible, so it is not necessarily detrimental to your submission if you do not
|
||
include one, though we do like interesting and creative uses of submissions. See
|
||
also the
|
||
FAQ on “<a href="../faq.html#try_scripts">submitting try.sh and try.alt.sh scripts</a>”.</p>
|
||
<p class="leftbar">
|
||
Even if it only has one invocation we still <strong>LIKE</strong> the try scripts.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you do include a <code>try.sh</code> then <strong>PLEASE</strong> remove the <code>try</code> rule in the Makefile.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you do include a <code>try.alt.sh</code> then <strong>PLEASE</strong> remove the <code>try.alt</code> rule in the Makefile.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you don’t have a prog.alt.c, then <strong>PLEASE</strong> remove the <code>try.alt</code> rule as well.
|
||
</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>In other words, it is a compilation error, and in order to get older
|
||
IOCCC winning entries that did this to compile, we had to update them to not do this.</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>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>. <strong>Hint!</strong></p>
|
||
<p>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>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> int 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">IOCCC judges</a> rescinded the encouragement of
|
||
nested functions. Such constructions, while interesting and sometimes
|
||
amusing, will have to wait until they are required by a C standard that are
|
||
actually implemented in <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>.</p>
|
||
<p>We <strong>DISLIKE</strong> submissions that require the use of <code>-fnested-functions</code>.</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>.</p>
|
||
<p>We <strong>DISLIKE</strong> the use of <code>varargs.h</code>. Use <code>stdarg.h</code> instead.</p>
|
||
<p>We <strong>DISLIKE</strong> the use of <code>gets(3)</code>. Use <code>fgets(3)</code> instead.</p>
|
||
<p>We tend to <strong>DISLIKE</strong> the blatant use of tarballs in an attempt to simply get
|
||
around the extra file number limit. We realize there may be cases where a
|
||
tarball containing a number of extra files may be needed. Such a need for a
|
||
tarball <strong>MUST</strong> be explained in the <code>remarks.md</code> file.</p>
|
||
<p class="leftbar">
|
||
Using a mass of <code>goto</code>s to obfuscate your code has become ‘old’ and is unlikely
|
||
to make it through the final rounds, if it even gets that far.
|
||
</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 byte.</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>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>One line programs should be short one line programs: say around <strong>80</strong> to <strong>132</strong>
|
||
bytes long. Going well beyond <strong>132</strong> bytes 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>won’t compile or run in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>
|
||
environment</li>
|
||
<li>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></li>
|
||
<li>abuse the build file to get around the size limit</li>
|
||
<li>obfuscate by use of ANSI trigraphs</li>
|
||
<li>obfuscate by use of digraphs</li>
|
||
<li>are larger than they need to be</li>
|
||
<li>have more lines than they need to have</li>
|
||
<li>are “blob-ier” (just a pile of unformatted C code) than they need to be</li>
|
||
<li>are rather similar to <strong><a href="../years.html">previous winners</a></strong> :-(</li>
|
||
<li>are <strong>identical</strong> to <strong><a href="https://en.wikipedia.org/wiki/Null_device">previous losers</a></strong> :-)</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> submissions 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.</p>
|
||
<p>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>The <code>Makefile</code> 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>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>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 of 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>
|
||
<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 your <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
|
||
bytes. <strong>REALLY TRY</strong> 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> submissions that make blatant use of including
|
||
large data files to get around the source code size limit.</p>
|
||
<p>Did we remember to indicate that programs that blatantly use
|
||
some complex state machine to do something simple, are boring?
|
||
We think we did. :-)</p>
|
||
<p>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#rule8-submitting-requirements">Rule 8 - Submitting requirements</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 <strong>NOT</strong> the smallest C source file that when compiled and run, dumps core:</p>
|
||
<pre><code> main;</code></pre>
|
||
<p>Unless you specify <code>-fwritable-strings</code> (see <code>COTHER</code> in the example
|
||
Makefile, described in the <a href="#makefile">Makefile section</a>), do not assume this
|
||
sort of code will work:</p>
|
||
<pre><code> char *T = "So many primes, so little time!";
|
||
...
|
||
T[14] = ';'; /* modifying a string requires: -fwritable-strings */</code></pre>
|
||
<p>Even so, one should probably not assume that this is universally accepted.</p>
|
||
<p>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>X client submissions 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 submissions should avoid using X related libraries and
|
||
software that are not in wide spread use.</p>
|
||
<p>As of Red Hat RHEL9.0, the X.org server is deprecated. See the
|
||
FAQ on “<a href="../faq.html#Xorg_deprecated">Xorg deprecation”</a>”
|
||
for more details. This does not mean that a submission using this will
|
||
necessarily be rejected, but it would be better if it can support Wayland in
|
||
some way or another.</p>
|
||
<p>We <strong>DISLIKE</strong> submissions 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>X client submissions 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>Try to avoid submissions that play music that some people believe is copyrighted
|
||
music.</p>
|
||
<p>While we recognize that UNIX is not a universal operating system, the contest
|
||
does have a bias towards such systems. In an effort to expand the scope of the
|
||
contest, we phrase our bias to favor the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>.</p>
|
||
<p>You are <strong>well advised</strong> to submit code that conforms to the <a href="https://unix.org/version4/overview.html">Single UNIX
|
||
Specification Version 4</a>.</p>
|
||
<p>To quote the <a href="../judges.html">IOCCC judges</a>:</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>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">IOCCC judges</a> as we might miss something and/or be too tired to
|
||
notice.</p>
|
||
<p>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 a 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 submissions. 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 both BSD
|
||
and Linux curses.</p>
|
||
<p class="leftbar">
|
||
If you do <code>#include <curses.h></code> make <strong>CERTAIN</strong> you link in curses (i.e.
|
||
<code>-lcurses</code>) and not ncurses (i.e. <code>-lncurses</code>).
|
||
</p>
|
||
<p><a href="rules.html#rule12-utf8">Rule 12 - UTF-8</a>
|
||
no longer discourages the use of UTF-8
|
||
characters in C code.</p>
|
||
<p>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>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>While programs that only run in a specific word size are OK, if you have
|
||
to pick, choose a 64-bit word size.</p>
|
||
<p>If your submission <strong>MUST</strong> run only on a 64-bit or 32-bit architecture,
|
||
then you <strong>MUST</strong> specify the <code>-arch</code> on your command line
|
||
(see <code>ARCH</code> in the example
|
||
Makefile, described in <a href="#makefile">Makefile section</a>). Do not assume a
|
||
processor word size without specifying <code>-arch</code>. For example:</p>
|
||
<pre><code> ARCH= -m64</code></pre>
|
||
<p>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>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">IOCCC 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">IOCCC 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 they 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">IOCCC 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>We <strong>DISLIKE</strong> the use of ASCII tab characters in markdown files, such as in the required <code>remarks.md</code> file.</p>
|
||
<p>We don’t mind the use of 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 annoy us when it comes time to
|
||
rendering your markdown content as it complicates the process.</p>
|
||
<p>If you do use ASCII tab characters in your non-markdown files, be
|
||
aware that some people may use a tab stop that is different than the common 8
|
||
character tab stop.</p>
|
||
<p><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#rule4-required-files">Rule 4 - Required files</a>,
|
||
and the
|
||
FAQ on “<a href="../faq.html#markdown">markdown</a>”.</p>
|
||
<p>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>We <strong>RECOMMEND</strong> you put a reasonable amount effort into the content of the
|
||
<code>remarks.md</code> file: it is a required file for a reason. :-)</p>
|
||
<p>Try to be even more creative!</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="fun">
|
||
|
||
</div>
|
||
<h1 id="fundamental-guidelines">Fun😄damental Guidelines</h1>
|
||
<p>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>At least 2 of several reasons for selecting the prime, 2503, for
|
||
<a href="rules.html#rule2b-net-size">Rule 2b - Net Size</a>
|
||
may be found on the <a href="https://t5k.org/curios/page.php/2503.html">“Curios!” about 2503</a>.</p>
|
||
<p>The 2503 value for <a href="rules.html#rule2b-net-size">Rule 2b - Net Size</a> is a decimal anagram
|
||
of the number of the kernel disk pack of one of the judge’s <a href="https://en.wikipedia.org/wiki/BESM-6">BESM-6</a>.</p>
|
||
<p>There may or may not be fewer than 2^7+1 reasons why these <a href="guidelines.html">IOCCC
|
||
guidelines</a> seem obfuscated.</p>
|
||
<p>Excessively “<em>dotty”</em> use of the <code>chksubmit(1)</code> or <code>chkentry(1)</code> commands suggests that
|
||
either you like silly things, or that you”<em>RTFS”</em> with some level of care.</p>
|
||
<p>Some people might question what actually constitutes a valid JSON file, given
|
||
the state of the “<em>so-called</em>” JSON spec.. :-)</p>
|
||
<p>We prefer programs that do not require a fish license: crayons and
|
||
cat detector vans not withstanding.</p>
|
||
<p class="leftbar">
|
||
This <em>guideline</em> has a change mark at the very start of this line.
|
||
</p>
|
||
<p>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>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 <strong>60</strong>.</p>
|
||
<p>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">IOCCC judges</a>, as a group, have a history giving wide degree of latitude
|
||
to reasonable submissions. 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>. :-)
|
||
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">IOCCC judges</a>, as a group, have a history giving wide degree of latitude
|
||
to reasonable submissions. 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>
|
||
<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">IOCCC 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>
|
||
<blockquote>
|
||
<p>All generalizations are false, including this one. – <strong>Mark Twain</strong></p>
|
||
</blockquote>
|
||
<p class="leftbar">
|
||
There are more than about 1 typos in this very sentence.
|
||
</p>
|
||
<p>This could be 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>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>OK, there are actually 2 <em>guidelines</em> that contain the word
|
||
<a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>,
|
||
unless you count this one, in which case there are 3. :-)</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">
|
||
You very well might not be completely 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 or partly
|
||
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 (allegedly).
|
||
</p>
|
||
<p>Any complaints about the above <em>guideline</em> could be addressed to the
|
||
Speaker of the House of Commons, or to the speaker of your national
|
||
parliament should you have one.</p>
|
||
<p class="leftbar">
|
||
Please try to avoid this specific individual <em>guideline</em>, if it at all possible.
|
||
</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 class="leftbar">
|
||
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-size">Rule 2 - Size</a>.
|
||
This isn’t to say that another highly compact and obfuscated
|
||
replacement of <code>init(8)</code> would not be an interesting submission.
|
||
</p>
|
||
<p class="leftbar">
|
||
The
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
|
||
is not an original work, unless you one of the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/graphs/contributors">several mkiocccentry toolkit contributors</a>.
|
||
in which case it is original! :-)
|
||
</p>
|
||
<p>If the <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>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>Jump to: <a href="#">top</a></p>
|
||
<div id="more-information">
|
||
|
||
</div>
|
||
<div id="information">
|
||
|
||
</div>
|
||
<h1 id="for-more-information">FOR MORE INFORMATION:</h1>
|
||
<p>For questions or comments about the contest, see <a href="../contact.html">Contacting the IOCCC</a>.</p>
|
||
<p><strong>Be SURE</strong> to review the <a href="index.html">IOCCC Rules and Guidelines</a> as they
|
||
may (and <strong>often do</strong>) change from year to year.</p>
|
||
<p><strong>PLEASE</strong> be sure you have the current <a href="rules.html">IOCCC rules</a> and
|
||
<a href="guidelines.html">IOCCC guidelines</a> prior to submitting to the contest.</p>
|
||
<p>See the <a href="../news.html">Official IOCCC website news</a> for additional information.</p>
|
||
<p>For the updates and breaking IOCCC news, 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. Please do note that unless
|
||
you are mentioned by us you will <strong>NOT</strong> get a notification from the app <em>so you
|
||
should refresh the page <strong>even if you do follow us</strong></em>.</p>
|
||
<p>Check out the <a href="https://www.ioccc.org/index.html">Official IOCCC winner website</a> in general.</p>
|
||
<p>Consider joining the IOCCC discord community via this link:
|
||
<a href="https://discord.gg/Wa42Qujwnw">https://discord.gg/Wa42Qujwnw</a></p>
|
||
<p>See the
|
||
FAQs on “<a href="../faq.html#mkiocccentry">obtaining, compiling, installing and using the mkiocccentry tools</a>”
|
||
and the
|
||
FAQ on “<a href="../quick-start.html#enter">how to enter the IOCCC</a>”
|
||
as that FAQ has important details on
|
||
<a href="../next/register.html">how to register</a>
|
||
as well as
|
||
<a href="../next/submit.html">how to upload your submission</a> for the IOCCC.</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-2025 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-2025 by Landon Curt Noll:
|
||
<a href="https://creativecommons.org/faq/#what-does-some-rights-reserved-mean"
|
||
target="_blank"
|
||
rel="license noopener noreferrer">Some Rights Reserved</a></h3>
|
||
<p>
|
||
This work is <b>licensed by Landon Curt Noll</b> under
|
||
<b><a href="https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1"
|
||
target="_blank"
|
||
rel="license noopener noreferrer"
|
||
style="display:inline-block;">CC BY-SA 4.0</a></b>.
|
||
<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;"
|
||
src="../png/cc.png"
|
||
alt="cc inside circle symbol">
|
||
<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;"
|
||
src="../png/by.png"
|
||
alt="person inside circle symbol">
|
||
<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;"
|
||
src="../png/sa.png"
|
||
alt="arrow looping back on itself inside circle symbol"><br>
|
||
You should <b>carefully review</b> the
|
||
<b><a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.en"
|
||
target="_blank"
|
||
rel="license noopener noreferrer">CC BY-SA 4.0 LEGAL CODE</a></b>
|
||
before using the licensed material.<br>
|
||
You may wish to review the
|
||
<b><a href="../license.html"
|
||
target="_blank"
|
||
rel="license noopener noreferrer">highlights of some of the key features and terms</a></b>
|
||
of <b>CC BY-SA 4.0</b>.<br>
|
||
</p>
|
||
</div>
|
||
|
||
<div id="coda"><h3>Coda</h3>
|
||
<p>
|
||
<a href="https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.ioccc.org%2Fnext%2Fguidelines.html" rel="nofollow">Nu HTML check this web page</a><br>
|
||
<a href="#top">Jump to top</a> <a href="#content">Jump to Content</a>
|
||
</p>
|
||
</div>
|
||
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/footer.default.html -->
|
||
<!-- START: this line starts content from: inc/bottom.default.html -->
|
||
|
||
</body>
|
||
</html>
|
||
|
||
<!-- END: this line ends content from: inc/bottom.default.html -->
|