This commit also removed some of the 'new marks' in the guidelines and rules (as they're no longer new) and some that were in the FAQ (which only happened when they were changed over to the FAQ). Removed problematic FAQs (per discussion). This required renumbering. Updated references of chkentry to chksubmit (only a few references to chkentry remain now - advising contestants to not use it but simply stating it is for the judges and it is what chksubmit uses). Added note in guidelines about gotos becoming 'old' (as Landon told me it is something Leo wanted in the next guidelines thanks to me). Just so Landon does not forget my C sins. :-) I have regenerated the html files but the guidelines.html and rules.html files have not been link-checked as these files will be modified by the judges a fair amount so there is no point yet. I believe I got references to nuked FAQs out but it's possible some were missed. The quick-start.md and next/submit.md (and their html files) were updated as well to refer to chksubmit instead of chkentry. It is quite possible some things were missed but this should help move things closer to getting ready for IOCCC29 in December.
2174 lines
121 KiB
HTML
2174 lines
121 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 -->
|
||
<!-- START: this line starts content from: inc/guidelines.closed.hdr -->
|
||
<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>These guidelines are a <strong>TENTATIVE proposal</strong> for the next IOCCC
|
||
and are <strong>likely be to be updated</strong> before the next 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">about asking questions</a>”
|
||
about these guidelines. You might also find the FAQ in general useful, especially the
|
||
FAQ on “<a href="../quick-start.html#enter">how to enter the IOCCC</a>”.</p>
|
||
<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-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 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.49 2025-11-17</strong>.
|
||
</p>
|
||
<p>The markdown form of these guidelines <a href="guidelines.md"
|
||
download="guidelines.md">is available for download</a>.</p>
|
||
<p><strong>IMPORTANT</strong>: Be <strong>SURE</strong> to read the <a href="rules.html">IOCCC rules</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="change_marks">
|
||
<h1 id="change-marks">Change marks</h1>
|
||
</div>
|
||
<p class="leftbar">
|
||
<strong>← Lines that start with this symbol indicate a change from the
|
||
previous IOCCC</strong>.
|
||
</p>
|
||
<p>Most lines (we sometimes make mistakes) that were modified since the previous
|
||
IOCCC start with a solid 4 pixel black left border (or, in the case of a code
|
||
block or blockquote, just a vertical bar).</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="about_guidelines">
|
||
<h1 id="about-this-file">ABOUT THIS FILE:</h1>
|
||
</div>
|
||
<p>This file contains <em>guidelines</em> intended to help people who wish to
|
||
participate in the <a href="https://www.ioccc.org">International Obfuscated C Code Contest
|
||
(IOCCC)</a>.</p>
|
||
<p>These are <strong>NOT the <a href="rules.html">IOCCC rules</a></strong>, though it does contain comments
|
||
about them. The <a href="guidelines.html">IOCCC guidelines</a> should be viewed as
|
||
<strong>hints</strong> and <strong>suggestions</strong>. <strong>Submission 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>Of course if a guideline is talking about a rule and you break that guideline,
|
||
you stand a good chance of having your submission rejected for breaking the
|
||
rule, not the guideline.</p>
|
||
<p>You <strong>SHOULD read the CURRENT <a href="rules.html">IOCCC rules</a></strong>, <em>prior</em> to submitting
|
||
code to the contest.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="new">
|
||
<h1 id="whats-new-this-ioccc">WHAT’S NEW THIS IOCCC</h1>
|
||
</div>
|
||
<p class="leftbar">
|
||
This IOCCC runs from <strong>2024-12-29 23:58:13.213455 UTC</strong> to <strong>2025-06-05 04:03:02.010099 UTC</strong>.
|
||
This IOCCC marks the <strong>40th anniversary</strong> of the contest!
|
||
</p>
|
||
<p class="leftbar">
|
||
This contest will enter the <strong><a href="../faq.html#pending">pending</a></strong> state on or about
|
||
<strong>2024-12-29 23:58:13.213455 UTC</strong>.
|
||
When this happens, you may begin registering to enter the IOCCC.
|
||
</p>
|
||
<p class="leftbar">
|
||
This contest will enter the <strong><a href="../faq.html#open">open</a></strong> state on <strong>2025-03-05 23:19:17.131107 UTC</strong>.
|
||
When this happens, you may begin uploading your submissions to the IOCCC.
|
||
</p>
|
||
<p class="leftbar">
|
||
This contest will enter the <strong><a href="../faq.html#judging">judging</a></strong> state on <strong>2025-06-05 04:03:02.010099 UTC</strong>.
|
||
When this happens, you may no longer upload your submissions to the IOCCC.
|
||
</p>
|
||
<p><strong>IMPORTANT NOTE</strong>: Until the contest enters the <strong><a href="../faq.html#open">open</a></strong> state, any or all
|
||
of the above <strong>dates and times may change <em>AT ANY TIME</em></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>Until the contest status becomes <strong><a href="../faq.html#open">open</a></strong>,
|
||
the <a href="rules.html">IOCCC rules</a>,
|
||
<a href="guidelines.html">IOCCC guidelines</a> and the tools in the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a> <strong>SHOULD be
|
||
considered</strong> provisional <strong>BETA</strong> versions and <strong>may be adjusted <em>AT ANY TIME</em></strong>
|
||
before the contest status becomes <strong><a href="../faq.html#open">open</a></strong>.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../quick-start.html#enter">how to register and submit to the IOCCC</a>”
|
||
for instructions on registering and participating in the IOCCC, as the process
|
||
may change from contest to contest.</p>
|
||
<p>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>See FAQs regarding:</p>
|
||
<ul>
|
||
<li><a href="../faq.html#obtaining_mkiocccentry">obtaining the latest mkiocccentry tools</a></li>
|
||
<li><a href="../faq.html#compiling_mkiocccentry">compiling the mkiocccentry tools</a></li>
|
||
<li><a href="../faq.html#install">installing the mkiocccentry tools</a></li>
|
||
<li><a href="../faq.html#using_mkiocccentry">using the mkiocccentry tools</a></li>
|
||
</ul>
|
||
<p>Uploading a tarball not formed by <code>mkiocccentry(1)</code> puts you at a very big risk of
|
||
violating <a href="rules.html#rule17">Rule 17</a>, especially as <code>mkiocccentry(1)</code> does a
|
||
great number of things that are required, and it also runs many checks, and if
|
||
any of those checks fail, you are at a very great risk of having your submission
|
||
rejected for violating <a href="rules.html#rule17">Rule 17</a>.</p>
|
||
<p>We <strong>STRONGLY</strong> recommend you <strong>do</strong> install the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>.</p>
|
||
<p><strong>IMPORTANT NOTE</strong>: the tools that require other tools, <code>mkiocccentry(1)</code> and
|
||
<code>txzchk(1)</code>, will, as of version <code>2.0.2 2025-03-11</code>, search under <code>$PATH</code>. If
|
||
you have an earlier version and you have not installed the tools and run the
|
||
tools from outside the repo directory, you will have to use the options to the
|
||
tools to set the path to the required tools.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#mkiocccentry">obtaining and compiling the most recent 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> to the IOCCC.</p>
|
||
<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
|
||
<code>mkiocccentry(1)</code> tool 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><strong>HINT:</strong> so that you do not have to repeatedly answer all the
|
||
questions, the <code>mkiocccentry(1)</code> tool has the options <code>-a answers</code>, <code>-A answers</code>
|
||
and <code>-i answers</code>, where <code>-a</code> will write to an answers file (if it does not
|
||
already exist), <code>-A</code> <strong>WILL OVERWRITE THE FILE</strong> and <code>-i</code> will read the answers from
|
||
the file. If you use <code>-A</code>, <strong>BE SURE</strong> you don’t overwrite another file by accident!</p>
|
||
<p>Be aware that even with the <code>-i answers</code> you will still be required to confirm
|
||
most if not all <code>y/n</code> questions - you just don’t have to input the name of the
|
||
submission, the abstract, the author details etc. If you really wish to
|
||
circumvent this you can use the <code>-Y</code> option but we do not recommend this because
|
||
if your update breaks a rule or there is some problem, you might not see it.</p>
|
||
<p>To help with not having to repeatedly enter a UUID, whether for the same
|
||
submission or multiple submissions, you can use the <code>-u uuidfile</code> or <code>-U UUID</code>
|
||
option. See the
|
||
FAQ on “<a href="../faq.html#uuid">how to avoid re-entering your UUID</a>”
|
||
for more details. Note that the <code>-i answers</code> option cannot be used with the UUID
|
||
options as the answers file includes the UUID.</p>
|
||
<p>The overall size limit (see <a href="rules.html#rule2a">Rule 2a</a>) on <code>prog.c</code> has been
|
||
<strong>increased from 4096 to 4993</strong> bytes.
|
||
The <a href="rules.html#rule2a">Rule 2a</a> size was changed from
|
||
<strong>4096</strong> to <strong>4993</strong> to keep 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>The <a href="rules.html#rule2b">Rule 2b</a> size has <strong>increased from 2053 to 2503</strong>
|
||
bytes.</p>
|
||
<p class="leftbar">
|
||
However, you should pay especial attention to our remarks in the <a href="../2024/index.html">IOCCC28
|
||
index.html</a>:
|
||
</p>
|
||
<p class="leftbar">
|
||
<blockquote>
|
||
<p><strong>IMPORTANT HINT</strong>: Only 3 of the 23 <strong>IOCCC28 winners</strong> came close to the
|
||
<a href="../next/rules.html#rule2">Rule 2 size limit</a>. Large code size isn’t
|
||
everything. :-) Those submitting to future contents should <strong>take a careful
|
||
note</strong> of that fact.</p>
|
||
</blockquote>
|
||
</p>
|
||
<p>Your submission must satisfy <strong>BOTH</strong> the maximum size
|
||
<a href="rules.html#rule2a">Rule 2a</a> <strong>AND</strong> the IOCCC size <a href="rules.html#rule2b">Rule 2b</a>.</p>
|
||
<p>To check your code against <a href="rules.html#rule2">Rule 2</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>
|
||
</blockquote>
|
||
<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. This is a <strong>feature</strong>, not a bug!</p>
|
||
<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 current version of <code>iocccsize(1)</code> is preferred by the <a href="../judges.html">IOCCC judges</a>.</p>
|
||
<p>In other words, make sure <code>iocccsize</code> does not flag any issues with your
|
||
<code>prog.c</code>.</p>
|
||
<p>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>The <strong>official locale</strong> of the <strong>IOCCC</strong> is <strong>C</strong>.</p>
|
||
<p class="leftbar">
|
||
Did you really think anything else? :-)
|
||
</p>
|
||
The <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>,
|
||
as of <a href="https://github.com/ioccc-src/mkiocccentry/releases/tag/2.4.4">Release version 2.4.4 2025-03-15</a>,
|
||
will run with a locale set to <strong>C</strong>.
|
||
</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 <strong>encouraged</strong> 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>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. Submissions 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 submissions, we are more inclined to pick the submission that
|
||
does something interesting when it’s executed.</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>The IOCCC has a rich history of remarkable winning entries created by
|
||
authors who skillfully employed various techniques to develop their code.
|
||
While it is <strong>NOT</strong> required, you are allowed to use tools to develop
|
||
and test your submission. These tools may include, but are not limited
|
||
to code generators, code analysis tools, static code analysis tools,
|
||
runtime analysis tools, machine learning tools, natural language models,
|
||
code copilot tools, so-called AI services, large language models (LLMS), etc.
|
||
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>You may use git, 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> them 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>make(1)</code> tool, your <code>Makefile</code>, and other tools 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>
|
||
in the building and compiling of your submission.</p>
|
||
<p>We do realize that there are holes in the <a href="rules.html">rules</a>, and invite
|
||
submitters to attempt to exploit them. We may 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>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>There may be fewer than 2^7+1 reasons why these <a href="guidelines.html">IOCCC
|
||
guidelines</a> seem obfuscated.</p>
|
||
<p><strong>IMPORTANT:</strong> Be sure that <strong>your submission works</strong> as documented in your
|
||
<code>remarks.md</code> file. 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 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 <strong>VERY GOOD START</strong>
|
||
to a great submission!</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<h1 id="mkiocccentry"><code>mkiocccentry</code></h1>
|
||
<p><a href="rules.html#rule17">Rule 17</a> (the <code>mkiocccentry(1)</code> rule) states that
|
||
you <strong>REALLY SHOULD</strong> use the <code>mkiocccentry(1)</code> tool to package your submission tarball.</p>
|
||
<p>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><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><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, including running
|
||
<code>chksubmit(1)</code> on the submission directory.</p>
|
||
<p>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
|
||
<a href="#chksubmit">chksubmit</a> fails to validate the submission directory, either because
|
||
of a validation error in the <code>.auth.json</code> or <code>.info.json</code>
|
||
<a href="https://www.json.org/json-en.html">JSON</a> files or because of
|
||
something else that <code>mkiocccentry(1)</code> creates or does, it is an
|
||
<strong>error</strong> 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 bug report
|
||
page</a>.
|
||
<strong>PLEASE run the <code>bug_report.sh</code> script to help us out here!</strong> See the
|
||
FAQ on “<a href="../faq.html#mkiocccentry_bugs">reporting mkiocccentry bugs</a>”.</p>
|
||
<p>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>However, even if <code>mkiocccentry</code> or one of the tools it invokes reports an error,
|
||
it <strong>does not</strong> necessarily mean it is a bug in the code. It might be an issue with
|
||
your submission. Thus if you report an error as a bug it might not be something
|
||
that will be fixed as there might not be anything wrong with the tools.</p>
|
||
<p>On the other hand, some conditions flagged by <code>mkiocccentry(1)</code> 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. Using
|
||
<code>-Y</code> will say ‘<em>yes</em>’ to even more prompts. Needless to say, we do <strong>NOT</strong>
|
||
recommend these options.</p>
|
||
<p>In many places it will prompt you to verify what you input, allowing you to
|
||
correct details as you go along. Be advised that there is a default answer and
|
||
if you press enter it will proceed with that default, so make sure you have
|
||
provided the correct answer.</p>
|
||
<p>If you wish to <strong>test</strong> that your submission passes the <code>mkiocccentry(1)</code> tests
|
||
without having to type in 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><strong>IMPORTANT NOTE</strong>: if you run an IOCCC related tool outside the repo directory
|
||
(specifying the absolute or relative path to the tool) and you have not
|
||
installed the tools (and we <strong>STRONGLY</strong> recommend you <strong>do</strong> install them),
|
||
then you will have to specify the options (such as paths) for the tools that are required like
|
||
<code>chksubmit(1)</code>, <code>txzchk(1)</code> and <code>fnamchk(1)</code>.</p>
|
||
<p>Make sure you have
|
||
the latest version of of the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
|
||
so that you do not violate <a href="rules.html#rule17">Rule 17</a> by mistake.</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>The synopsis of the <code>mkiocccentry(1)</code> tool is:</p>
|
||
<pre><code> mkiocccentry [options] workdir topdir</code></pre>
|
||
<p>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. If you do use the overwrite option, <strong>MAKE SURE</strong> you do
|
||
not overwrite another file!</p>
|
||
<p>See the
|
||
FAQ on the
|
||
“<a href="../faq.html#mkiocccentry">mkiocccentry tool</a>”
|
||
for how to use this tool and the
|
||
FAQ on the
|
||
“<a href="../faq.html#mkiocccentry_details">finer details of mkiocccentry</a>”
|
||
for even more information.</p>
|
||
<div id="tools">
|
||
<h1 id="other-mkiocccentry-tools">Other mkiocccentry tools</h1>
|
||
</div>
|
||
<p>The <code>mkiocccentry(1)</code> tool will execute a number of tools, some of which will
|
||
execute one or more additional tools.</p>
|
||
<h2 id="iocccsize"><code>iocccsize</code></h2>
|
||
<p><code>mkiocccentry(1)</code> will use code from <code>iocccsize(1)</code> which detects a number of
|
||
issues (such as <a href="rules.html#rule2">Rule 2</a>) that you may ignore, if you wish, as
|
||
noted above.</p>
|
||
<p>In other words, you no longer need to run <code>iocccsize</code> manually. However, the
|
||
checks described above are still made but through the <code>mkiocccentry(1)</code> tool itself.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<h2 id="chksubmit"><code>chksubmit</code></h2>
|
||
<p><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. After these files are formed, the <code>chksubmit(1)</code> tool will be run on
|
||
the submission directory; this tool not only validates the two JSON files
|
||
(and runs specific checks on them after validating the JSON), but it also
|
||
verifies that what is in the manifest in <code>.info.json</code> matches the contents of
|
||
the directory, in addition to other checks. If <code>chksubmit(1)</code> fails to validate
|
||
anything at all, your submission <strong>WILL BE</strong> rejected!</p>
|
||
<p><strong>IMPORTANT</strong>: although <code>chksubmit(1)</code> validates the files in the directory, it
|
||
only inspects the contents of the two JSON files; it performs other kinds of
|
||
checks on the other files, and those checks are run on the two JSON files as
|
||
well.</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.
|
||
However, if you do provide such invalid JSON files, <strong>PLEASE</strong>
|
||
document and explain this in your <code>remarks.md</code> file.</p>
|
||
<p class="leftbar">
|
||
On the other hand, some people might question what actually constitutes a valid
|
||
JSON file. :-)
|
||
</p>
|
||
<p>If <code>chksubmit</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>.
|
||
<strong>PLEASE</strong> run the command:</p>
|
||
<pre><code> make bug_report</code></pre>
|
||
<p>from the top level repo directory itself and attach the bug report file (it will
|
||
tell you the name of the file). See also the
|
||
FAQ on “<a href="../faq.html#mkiocccentry_bugs">reporting mkiocccentry bugs</a>”.</p>
|
||
<p>Assuming that <code>chksubmit(1)</code> successfully validates your submission directory,
|
||
the tarball will be formed and then <code>txzchk(1)</code> will be executed on it. In this
|
||
case, there should be no problems, as <code>mkiocccentry(1)</code> should <strong>NOT</strong> form a
|
||
tarball if there are any issues.</p>
|
||
<p>If <code>mkiocccentry(1)</code> is used and <code>chksubmit(1)</code> fails to validate your submission
|
||
directory, then unless it is a system specific problem, it could be a bug in
|
||
<code>mkiocccentry(1)</code>, <code>chksubmit(1)</code> or possibly <code>jparse</code>, although this is unlikely.
|
||
Nonetheless, if you believe there is a bug, you may report it as explained above.</p>
|
||
<p>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>chksubmit(1)</code>, see the
|
||
FAQ about “<a href="../faq.html#chksubmit">chksubmit</a>”.</p>
|
||
<p><code>chksubmit</code> uses the <code>jparse</code> library. See the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/README.md">jparse
|
||
README.md</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/tree/master/jparse">mkiocccentry GitHub repo subdirectory
|
||
jparse</a> as well as
|
||
the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jparse_library_README.md">jparse library README.md
|
||
file</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/tree/master/jparse">mkiocccentry GitHub repo subdirectory
|
||
jparse</a>, for more
|
||
details.</p>
|
||
<p>The <code>jparse</code> parser, library and tools were co-developed by <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone
|
||
Ferguson</a> and <a href="http://www.isthe.com/chongo/index.html">Landon Curt
|
||
Noll</a> in 2022-2025 and come from the
|
||
<a href="https://github.com/xexyl/jparse">jparse repo</a>. However, the <strong>mkiocccentry
|
||
tools use a <em>clone</em></strong> of the <a href="https://github.com/xexyl/jparse">jparse repo</a> <strong>at
|
||
a <em>specific</em> release</strong>. Thus the <code>mkiocccentry</code> will at times be behind the
|
||
<a href="https://github.com/xexyl/jparse">jparse repo</a>!</p>
|
||
<p>You do <strong>NOT need to install</strong> <code>jparse</code> from the <a href="https://github.com/xexyl/jparse">jparse
|
||
repo</a>! The <code>mkiocccentry</code> tools link in the
|
||
static library from <code>mkiocccentry</code>’s <em>clone</em>.</p>
|
||
<p>The <code>mkiocccentry</code> toolkit <em>also</em> has a clone of <em>both</em> the <a href="https://github.com/lcn2/dbg">dbg
|
||
library</a> and the
|
||
<a href="https://github.com/lcn2/dyn_array">dyn_array library</a>; the <a href="https://github.com/lcn2/dyn_array">dyn_array
|
||
library</a> uses the <a href="https://github.com/lcn2/dbg">dbg
|
||
library</a> and the <a href="https://github.com/xexyl/jparse">jparse
|
||
library</a> uses both libraries but unlike in the
|
||
<a href="https://github.com/xexyl/jparse">jparse repo</a>, the libraries do not need to be
|
||
installed separately, in order to use the tools in <code>mkiocccentry</code>.</p>
|
||
<p>In other words, <code>mkiocccentry</code> <strong>contains everything</strong> you need, and <em>even if you
|
||
do install</em> the libraries from their respective repos, it/they will <strong>not be
|
||
used</strong> when compiling the <code>mkiocccentry</code> tools. This is important to
|
||
make sure that you’re using the correct versions, which is also verified by
|
||
<code>chksubmit</code> (in the JSON files created by <code>mkiocccentry(1)</code>). See <a href="rules.html#rule17">Rule
|
||
17</a>!</p>
|
||
<p class="leftbar">
|
||
We <strong>HIGHLY</strong> recommend you install the <code>mkiocccentry</code> toolkit, however.
|
||
</p>
|
||
<p>Please see the
|
||
FAQ on “<a href="../faq.html#chksubmit">validating your submission directory</a>
|
||
for more details on <code>chksubmit(1)</code>.</p>
|
||
<p>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><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 bug report
|
||
page</a>.
|
||
<strong>PLEASE run the <code>bug_report.sh</code> script to help us out here!</strong> You may do this
|
||
by running from the top level directory of the repo <code>make bug_report</code>. See the
|
||
FAQ on “<a href="../faq.html#mkiocccentry_bugs">reporting mkiocccentry bugs</a>”.</p>
|
||
<p>As part of its algorithm, <code>txzchk(1)</code> will run <code>fnamchk(1)</code> on the
|
||
<em>tarball</em> to verify that the <em>filename</em> is valid. See the
|
||
FAQ on “<a href="../faq.html#fnamchk">fnamchk</a>”
|
||
and the <a href="#fnamchk">fnamchk section</a> below for more details on this tool.</p>
|
||
<p>It is beyond the scope of this document to discuss the many tests that
|
||
<code>txzchk(1)</code> performs; if you wish to know, we refer you to the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c">source
|
||
code</a> or the man
|
||
page. You might just find a fun option if you do either of these!</p>
|
||
<p>Of course, as <code>txzchk</code> does not extract the tarball, it is possible that if you
|
||
manually package your submission tarball and/or find and exploit a missing
|
||
check, you could still be violating <a href="rules.html#rule17">Rule 17</a>.</p>
|
||
<div id="extra-files">
|
||
<h2 id="including-optional-and-extra-files">Including optional and extra files</h2>
|
||
</div>
|
||
<p class="leftbar">
|
||
The maximum total number of <em>extra files</em> that may be submitted is 31.
|
||
</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>. The non-extra files are considered <em>free files</em>.
|
||
</p>
|
||
<p class="leftbar">
|
||
Of course any dot file that is not <code>.auth.json</code> and <code>.info.json</code> will result in
|
||
a violation of <a href="rules.html#rule17">Rule 17</a>, regardless of its depth.
|
||
</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 class="leftbar">
|
||
For information on the <code>try</code> script files see the
|
||
FAQ on the “<a href="../faq.html#try_script">try.sh script system</a>”
|
||
and for more details on alt code (including the <code>try.alt.sh</code> script) see the
|
||
FAQ on “<a href="../faq.html#alt_code">alt code</a>”.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you really <strong>MUST</strong> include more files than the limit allows, then you may do
|
||
so by including as an extra file, a tarball. This does <strong>NOT</strong> have to pass
|
||
<code>txzchk(1)</code> tests; only the submission tarball must pass the <code>txzchk(1)</code> tests.
|
||
</p>
|
||
<p class="leftbar">
|
||
You <strong>MUST</strong> justify including extra files beyond the limit, should you do so.
|
||
Even so this does not mean it will be considered valid.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you use a tarball for a depth beyond the maximum, you <strong>MUST</strong> justify this
|
||
as well. Even so this does not mean it will be considered valid.
|
||
</p>
|
||
<p>If you <strong>DO</strong> include a tarball, 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><strong>IMPORTANT REMINDER</strong>: make <strong>SURE</strong> your tarball does <strong>NOT</strong> reveal who you are!
|
||
The <code>mkiocccentry(1)</code> tool creates a v7 format tarball to prevent this. You can
|
||
do the same like:</p>
|
||
<pre><code> tar --format=v7 -cJf foo.txz directory</code></pre>
|
||
<p>See <a href="rules.html#rule17">Rule 17</a> and also the
|
||
FAQ on “<a href="../faq.html#max-files">maximum number of files</a>”.</p>
|
||
<p>If you do not follow these points, you
|
||
are at a great risk of violating <a href="rules.html#rule17">Rule 17</a>!</p>
|
||
<p><strong>NOTE</strong>: if you want to include a test-suite that requires a lot of files,
|
||
please suggest this in your <code>remarks.md</code> and if your submission wins it can
|
||
be done. In other words you should NOT use a tarball for a test-suite unless you
|
||
have a very good reason for this (and if you do, make <strong>SURE</strong> you specify why
|
||
in your <code>remarks.md</code> file).</p>
|
||
<p>See also the
|
||
FAQ on “<a href="../faq.html#txzchk">txzchk</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="fnamchk">
|
||
<h2 id="fnamchk1"><code>fnamchk(1)</code></h2>
|
||
</div>
|
||
<p>As an important part of its algorithm, <a href="#txzchk">txzchk(1)</a> directly executes
|
||
<code>fnamchk(1)</code>. If the filename is invalid (or the filename does not match the
|
||
directory name of the tarball) then it is an <strong>error</strong> and you risk violating
|
||
<a href="rules.html#rule17">Rule 17</a>. Nevertheless, you can run the tool manually,
|
||
should you wish to.</p>
|
||
<p>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>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">reporting mkiocccentry bugs</a>”.</p>
|
||
<p>As you can see, the use of <code>mkiocccentry(1)</code> is <strong>HIGHLY RECOMMENDED</strong>, and at
|
||
the risk of stating the obvious, you run <strong>A VERY BIG RISK</strong> of having
|
||
your submission rejected if you package your own tarball, and there are <strong>ANY
|
||
problems</strong>. For instance, if <code>chksubmit(1)</code> found a problem in your <code>.info.json</code>
|
||
file, the <code>mkiocccentry(1)</code> tool would not package it. But if you were to package
|
||
it manually, you would be violating <a href="rules.html#rule17">Rule 17</a>. But even if
|
||
everything checks out OK you should <strong>NOT</strong> assume that everything <strong>IS</strong> OK.</p>
|
||
<div id="bugs">
|
||
<h1 id="problems-andor-bugs-in-the-mkiocccentry-toolkit">Problems and/or bugs in the mkiocccentry toolkit</h1>
|
||
</div>
|
||
<p>Although the tools have been tested extensively, it is nonetheless possible for bugs to
|
||
exist in the code, as all programmers know. In this case, <strong>please</strong> ask for help or report what
|
||
you think is 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>Of course, it is also possible for <code>mkiocccentry(1)</code>, or one or more of the
|
||
tools it executes (or another tool executes), to fail, but <strong>NOT</strong> because of a
|
||
bug. An example problem is if there is not enough memory available or if some
|
||
other library or syscall fails. Nonetheless it might be worth reporting as a
|
||
bug; it is a judgement call: if it’s a bug it’ll be addressed and if it’s not
|
||
that’s OK too!</p>
|
||
<div id="make">
|
||
<div id="makefile">
|
||
<h1 id="makefiles">Makefiles</h1>
|
||
</div>
|
||
</div>
|
||
<p>We <strong>recommend</strong> AND <strong>encourage</strong> you to use the example Makefile,
|
||
as the starting point for your submission’s required <code>Makefile</code>:</p>
|
||
<ul>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/next/Makefile.example">view example Makefile</a></li>
|
||
<li><a href="Makefile.example" download="Makefile">download example Makefile</a></li>
|
||
</ul>
|
||
<p>Feel free to modify the <code>Makefile</code> to suit your obfuscation
|
||
needs.</p>
|
||
<p><strong>Please</strong> add a space between the <code>=</code> and the value of variables, in the
|
||
<code>Makefile</code>, making sure that the <code>=</code> comes immediately after the name. See the
|
||
example <code>Makefile</code> for examples.</p>
|
||
<p class="leftbar">
|
||
This helps us fit the Makefile into a winning entry, should your submission win.
|
||
</p>
|
||
<p>The rest of this section and its subsections will assume that you are using some
|
||
variant of the example <code>Makefile</code>, again renamed as <code>Makefile</code>.</p>
|
||
<p>We suggest that you compile your submission with a commonly available
|
||
<code>-std=gnu17</code> (ISO C 2017 with GNU extensions) C compiler, via <code>clang(1)</code>
|
||
and/or <code>gcc(1)</code>.</p>
|
||
<div id="cflags">
|
||
<div id="flags">
|
||
<h2 id="default-compiler-flags">Default compiler flags</h2>
|
||
</div>
|
||
</div>
|
||
<p>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</code>!</p>
|
||
<p>It <strong>is OK</strong> if you need to require your submission to <strong>NOT be</strong> compiled
|
||
using the default <code>-std=gnu17 -O3</code> settings. Simply <strong>explain why</strong>
|
||
your submission should NOT be compiled using <code>-std=gnu17 -O3</code> in
|
||
your <code>remarks.md</code> file, <strong>AND</strong> adjust your <code>Makefile</code> accordingly.</p>
|
||
<p class="leftbar">
|
||
You really should <strong>NOT</strong> redefine <code>CC</code> because doing so makes it less portable. <– <strong>Hint!</strong>
|
||
</p>
|
||
<p>One reason that you might have to change the flags, is that the optimiser is
|
||
known to break some programs, but there are certainly other possible valid
|
||
reasons. Again, just update the <code>Makefile</code> and explain it in your <code>remarks.md</code>.
|
||
See the <a href="#optimiser">optimiser section</a> for details for changing optimiser
|
||
flags.</p>
|
||
<p>For more fun when it comes to optimisers breaking code, see
|
||
<a href="../1986/marshall/compilers.html">1986/marshall/compilers.html</a>.</p>
|
||
<div id="compilers">
|
||
<h2 id="default-compiler">Default compiler</h2>
|
||
</div>
|
||
<p><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><strong>PLEASE NOTE</strong>: in macOS, the compiler <code>gcc</code> found at <code>/usr/bin/gcc</code> is
|
||
in truth the <code>clang</code> compiler, as <code>/usr/bin/gcc --version</code> will show!</p>
|
||
<div id="cstd">
|
||
<div id="standard">
|
||
<h2 id="c-standard">C standard</h2>
|
||
</div>
|
||
</div>
|
||
<p>You may change the standard under which your submission is compiled
|
||
by modifying the <code>CSTD</code> Makefile variable. For example, to use <code>c99</code> instead:</p>
|
||
<pre><code> CSTD= -std=c99</code></pre>
|
||
<div id="opt">
|
||
<div id="optimization">
|
||
<div id="optimisation">
|
||
<div id="optimizer">
|
||
<div id="optimiser">
|
||
<h2 id="default-optimisation-level">Default optimisation level</h2>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>You may change the level of optimization and compiler debug level
|
||
that your submission is compiled with, by modifying the <code>OPT</code> Makefile variable.
|
||
For example, to compile without optimization, and to include debug symbols:</p>
|
||
<pre><code> OPT= -O0 -g3</code></pre>
|
||
<div id="warnings">
|
||
<div id="cwarn">
|
||
<h2 id="compiler-warnings">Compiler warnings</h2>
|
||
</div>
|
||
</div>
|
||
<p>The default warning flags are set via the <code>CWARN</code> variable, as shown in the
|
||
example <code>Makefile</code>:</p>
|
||
<pre><code> # Common C compiler warning flags
|
||
#
|
||
CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN}</code></pre>
|
||
<p>For details on <code>CSILENCE</code> and <code>CUNKNOWN</code>, see the <a href="#disabling-warnings">section on disabling
|
||
warnings</a>.</p>
|
||
<div id="weverything">
|
||
<h3 id="the--weverything-option">The <code>-Weverything</code> option</h3>
|
||
</div>
|
||
<p>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>On the other hand, if <code>${CC}</code> has “<code>clang</code>” in the name, the example <code>Makefile</code> will
|
||
automatically enable <code>-Weverything</code>, so you might have to use <code>-Wno-foo</code>
|
||
options anyway, as detailed below. See the
|
||
FAQ on “<a href="../faq.html#weverything">-Weverything</a>”
|
||
for more details.</p>
|
||
<p>If “<code>clang</code>” is NOT in <code>${CC}</code>, the <code>CWARN</code> variable will not be further
|
||
modified.</p>
|
||
<p>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 to fret too much.</p>
|
||
<p>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>The two previous guidelines might be thought by some as being somewhat
|
||
contradictory. Isn’t life, and isn’t trying to satisfy “contradictory customer
|
||
requirements” all too often like that? :-) Try to minimize warnings if you
|
||
can.</p>
|
||
<p>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>On the other hand, some warnings cannot be disabled and are enabled by compilers
|
||
without any warning option specified. These are sometimes inevitable in
|
||
obfuscated code and even in some non-obfuscated code, and you should not worry
|
||
about this, though it might be worth pointing out.</p>
|
||
<p>For instance, some compilers like to warn about use of pointers as arrays, which seems to
|
||
be dubious, as it obviously can’t (always) be avoided, being a big part of C, so
|
||
you should not worry about this either; this is the warning
|
||
<code>-Wunsafe-buffer-usage</code> and the way to disable it is <code>-Wno-unsafe-buffer-usage</code>.
|
||
See also the
|
||
FAQ on “<a href="../faq.html#forced_warnings">forced warnings</a>”
|
||
and the
|
||
FAQ on “<a href="../faq.html#weverything">-Weverything</a>”.</p>
|
||
<h2 id="disabling-warnings">Disabling warnings</h2>
|
||
<p class="leftbar">
|
||
If you do have to disable warnings due to <code>-Weverything</code> automatically being
|
||
included, you might wish to state this fact in your <code>remarks.md</code> file.
|
||
And even without <code>-Weverything</code> there can be warnings, as noted above.
|
||
</p>
|
||
<p>If your submission issues lots of warnings but is otherwise
|
||
marvelously obfuscated in multiple levels, don’t worry about it. Nevertheless,
|
||
be sure that the warnings do not constitute a potential “<strong>show stopper</strong>”
|
||
compiler problem. Be sure that compilers such as both <code>gcc</code> and <code>clang</code> won’t
|
||
produce a compiler <strong>error</strong> and refuse to compile your code: unless for some
|
||
reason that is what you intend to happen in which case document that too in your
|
||
<code>remarks.md</code> file. :-)</p>
|
||
<p>All other things being equal, a program that must turn off fewer
|
||
warnings will be considered better, for certain values of better.</p>
|
||
<p>To turn off a compiler warning, in your submission’s <code>Makefile</code>,
|
||
try something such as:</p>
|
||
<pre><code> CSILENCE= -Wno-some-thing -Wno-another-thing</code></pre>
|
||
<p class="leftbar">
|
||
For instance:
|
||
</p>
|
||
<pre><code> CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation</code></pre>
|
||
<div id="macros">
|
||
<h2 id="defining-macros-in-the-makefile">Defining macros in the Makefile</h2>
|
||
</div>
|
||
<p>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><strong>NOTE</strong>: just because we offer a default way to use the <code>-D</code> option, we still
|
||
do not like excess use of <code>-D</code> to get past size limits, especially since you
|
||
could use <code>#define</code> in your code instead.</p>
|
||
<div id="include">
|
||
<h2 id="include-files-in-the-makefile">Include files in the Makefile</h2>
|
||
</div>
|
||
<p>If you need to include a file (as in <code>#include</code>) on the command line, use the
|
||
<code>CINCLUDE</code> Makefile variable. For example:</p>
|
||
<pre><code> CINCLUDE= -include stdio.h</code></pre>
|
||
<div id="magic">
|
||
<h2 id="magic-in-the-makefile">Magic in the Makefile</h2>
|
||
</div>
|
||
<p>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><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>Again, please note that in macOS, <code>/usr/bin/gcc</code> is actually <code>clang</code>!</p>
|
||
<div id="clobber">
|
||
<h2 id="the-clobber-rule">The clobber rule</h2>
|
||
</div>
|
||
<p>When <code>make clobber</code> is invoked, we request that submissions be restored
|
||
to their original submission state. For example, any temporary files
|
||
(<strong>including</strong> the compiled program(s)) created during the build process, or
|
||
during execution should be removed by the <code>clobber</code> rule. In other words, the
|
||
only things that should be in the directory after running <code>make clobber</code> is what
|
||
is in your submission tarball itself.</p>
|
||
<p>While people are free to manage their submission under <code>git(1)</code> or even use a
|
||
GitHub repo, dot-files and dot-directories such as <code>.git</code> are not allowed in a
|
||
submission.</p>
|
||
<p>The <code>mkiocccentry(1)</code> tool will ignore dot-files and dot-directories (such as
|
||
<code>.vimrc</code>, <code>.bashrc</code>, <code>.git</code> and <code>.github</code>) and not put them in the submission’s
|
||
compressed tarball. So while you may use such files and
|
||
directories to help develop your submission, they won’t be included when you run
|
||
the <code>mkiocccentry(1)</code> tool.</p>
|
||
<p>Even if you did manage to get dot files or dot directories in the tarball
|
||
somehow, <code>txzchk(1)</code> will flag it as an error. When the judges run <code>txzchk(1)</code>
|
||
on the uploaded submission compressed tarball, if anything is wrong, for
|
||
instance if you “sneak in” any dot files or dot directories, the submission
|
||
<strong>WILL BE REJECTED</strong> for violating <a href="rules.html#rule17">Rule 17</a>!</p>
|
||
<p>You may use whatever tools you need to develop your submission, including the
|
||
use of <code>git(1)</code> or <code>gh(1)</code>, just be sure that your submission code and your
|
||
submission Makefile don’t depend on such tools.</p>
|
||
<p>Of course if you do use GitHub to work on your submission, you might want to
|
||
make the repo private so you don’t reveal who you are. :-)</p>
|
||
<p class="leftbar">
|
||
In other words, make <strong>SURE</strong> you keep anonymous who submitted the code!
|
||
</p>
|
||
<p class="leftbar">
|
||
Please do <strong>NOT</strong> use these tools to help with the
|
||
<code>clobber</code> rule! For instance, do <strong>NOT</strong> use <code>git clean</code>! Not only does this
|
||
depend on the user having <code>git(1)</code> but it also does not account for the
|
||
submission tarballs. Even worse is when someone does have it in a <code>git(1)</code> repo
|
||
it will remove files that are not under <code>git(1)</code> control! Instead, see the
|
||
<code>clobber</code> rule in the example Makefile to see how to manage this.
|
||
</p>
|
||
<p>In other words, for <code>make clobber</code>, do something like:</p>
|
||
<pre><code> clobber:
|
||
${RM} -f foo bar baz</code></pre>
|
||
<p>and <strong>NOT</strong> something like this:</p>
|
||
<pre><code> # do NOT do this!
|
||
clobber:
|
||
-git clean -f # WRONG !!!</code></pre>
|
||
<p>And do <strong>NOT</strong> use <code>git</code> for any other <code>Makefile</code> rule either.</p>
|
||
<p><strong>NOTE</strong>: <code>mkiocccentry(1)</code> will directly run <code>make clobber</code> in the submission
|
||
directory. And although it is not an error if this fails, if it fails because the
|
||
Makefile does not have a clobber rule, it will be flagged by <code>mkiocccentry(1)</code>
|
||
(you may ignore this but it does put you at a risk of violating the rules).</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>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>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>.</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 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>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 <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>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>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>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>
|
||
<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>
|
||
<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>
|
||
<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 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">the source code
|
||
size limit</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>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 <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>There are more than 1 typos in this very sentence.</p>
|
||
<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>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>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><strong>NOTE</strong>: The previous <em>guideline</em> in this spot has been replaced by this <em>guideline</em>:</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>
|
||
<blockquote>
|
||
<p>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
|
||
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>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>Please avoid this specific individual <em>guideline</em>, if it at all possible.</p>
|
||
<p>We freely admit that interesting, creative or humorous comments in
|
||
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 BSD
|
||
or 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#rule13">Rule 13</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>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 code that uses the contents of
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">iocccsize.c</a>,
|
||
<em>unless</em> 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>The IOCCC submission tarball validator 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 code that uses the contents of
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c">txzchk.c</a>,
|
||
<em>unless</em> 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>In addition to the above tools, none of the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||
tools</a>, <em>including, <strong>but not
|
||
limited</strong></em> to
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/mkiocccentry.c">mkiocccentry</a>,
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/chksubmit.c">chksubmit</a>,
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/chksubmit.c">chksubmit</a>,
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/test_ioccc/fnamchk.c">fnamchk</a>
|
||
and
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/location_main.c">location</a>,
|
||
nor the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/README.md">JSON parser and
|
||
library</a>,
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jstrencode.c">jstrencode</a>,
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jstrdecode.c">jstrdecode</a>
|
||
or any of the other <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse">jparse
|
||
tools</a>
|
||
(see the <a href="https://github.com/xexyl/jparse/">jparse repo</a>), are original works,
|
||
unless you are <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone Ferguson</a> or
|
||
<a href="http://www.isthe.com/chongo/index.html">Landon Curt Noll</a>, in which case they
|
||
are original! :-) Submitting source code that uses the content of any of these tools or
|
||
library, <em>unless</em> 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>And unless you are <a href="https://en.wikipedia.org/wiki/Landon_Curt_Noll">Landon Curt Noll</a>,
|
||
the code in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/tree/master/dbg">dbg</a> and
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/tree/master/dyn_array">dyn_array</a> are
|
||
not original works. Submitting source code that uses the contents of those
|
||
libraries, <em>unless</em> you <a href="https://en.wikipedia.org/wiki/Landon_Curt_Noll">Landon Curt Noll</a>,
|
||
might run the risk of violating <a href="rules.html#rule7">Rule 7</a>.</p>
|
||
<p><a href="rules.html#rule7">Rule 7</a> does not prohibit you from writing your own
|
||
obfuscated 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">IOCCC judges</a> should not enter the IOCCC! :-)
|
||
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.</p>
|
||
<p>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> and
|
||
<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 <a href="https://github.com/westes/flex">flex</a> and <a href="https://www.gnu.org/software/bison/">bison</a>
|
||
generated code 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>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>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>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>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#rule19">Rule 19</a> and our
|
||
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="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
|
||
submissions, 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">IOCCC 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>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>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> 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>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 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 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 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="judging">
|
||
<h1 id="judging-process">JUDGING PROCESS:</h1>
|
||
</div>
|
||
<p>Submissions are judged by Leonid A. Broukhis and Landon Curt Noll.</p>
|
||
<p>Each submission submitted is given a random string and subdirectory. The
|
||
submission files including, but not limited to <code>prog.c</code>, <code>Makefile</code>,
|
||
<code>remarks.md</code>, <code>.info.json</code>, <code>.auth.json</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">IOCCC 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 and/or writing style might reveal the
|
||
information about the authors. 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">IOCCC judges</a> are on to this trick
|
||
and therefore consider any obfuscated source or data file claiming to be from
|
||
Honeyman to not be from Honeyman. This of course creates an interesting paradox
|
||
known as the “<strong>obfuscated Peter Honeyman paradox</strong>”. Should Peter Honeyman
|
||
actually submit to the IOCCC, he alone is excluded from the above, as we
|
||
will likely believe it’s just another attempt at confusion. This <em>guideline</em> is
|
||
known as the “<strong>Peter Honeyman is exempt</strong>” <em>guideline</em>.</p>
|
||
<p><strong>BTW</strong>: None of the submissions 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 submissions 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 submissions 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 submissions that we receive.</p>
|
||
<p>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><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 submissions 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 submissions that were eliminated in the
|
||
previous round. Thus, a submission gets at least two readings and
|
||
often more than two.</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>Reading <code>prog.c</code>, the C source and reviewing the <code>remarks.md</code> information</li>
|
||
<li>Briefly looking at 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>This is the very <strong>guideline</strong> that goes, <strong>BING!</strong></p>
|
||
<p>Okay, technically that was the <em>second</em> <strong>guideline</strong> that goes <strong>BING</strong>, and this
|
||
is the third. :-)</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> and the FAQ on “<a href="../faq.html#Xorg_deprecated">Xorg
|
||
being deprecated</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 submissions 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 submissions (typically about 25) down to to about
|
||
half that number: declaring those remaining to be winners.</p>
|
||
<p>Often we are confident that the submissions 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, however.</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>Over the years, more than one <a href="../judges.html">IOCCC judge</a>
|
||
has been known to <strong>bribe</strong> another <a href="../judges.html">IOCCC judge</a> into voting for a
|
||
winning submissions by offering a bit of high quality chocolate, or
|
||
other fun item.</p>
|
||
<p class="leftbar">
|
||
Over the years some judges have submitted code that had to be rejected once it
|
||
was discovered to be a judge.
|
||
</p>
|
||
<p>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>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>See the
|
||
FAQ on “<a href="../faq.html#support">supporting 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>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 submissions. 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>The <a href="../judges.html">IOCCC judges</a> will toot initial announcement of who won, the name
|
||
of their award, and a very brief description (award title) 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>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>The <a href="../status.html">current status of the IOCCC</a> will change from
|
||
<strong><a href="../faq.html#judging">judging</a></strong> to <strong><a href="../faq.html#closed">closed</a></strong> .</p>
|
||
<p>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>When the above happens, the winning entries have been selected by the <a href="../judges.html">IOCCC
|
||
judges</a>.</p>
|
||
<p>The <a href="../judges.html">IOCCC judges</a> will begin to prepare to release the source
|
||
code of the new IOCCC winners.</p>
|
||
<p>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>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. Winning 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 class="leftbar">
|
||
We will also post a notice to the IOCCC discord server.
|
||
</p>
|
||
<p>Consider joining the IOCCC discord community via this link:
|
||
<a href="https://discord.gg/Wa42Qujwnw">https://discord.gg/Wa42Qujwnw</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>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
|
||
(sometimes by the author(s) themselves). There have been multiple classes
|
||
that have focused in part, on IOCCC winning entries. And 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>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 -->
|