Congratulations to: * 2024/anders - Prize in sound coding - layered music generator * 2024/burton - Prize in pentagrammatology - wordle hard mode solver * 2024/cable1 - Prize in bot talk - LLM inference engine * 2024/cable2 - Prize in murky waters - salmon recipe * 2024/carlini - Prize in perfect timing - Intel 4004 emulation * 2024/codemeow - Prize in tray planting - bonsai generator * 2024/endoh1 - Prize in patient pointillism - slow ray tracer in CPP * 2024/endoh2 - Prize in solid body physics - rotating rigid body simulation * 2024/ferguson1 - Prize in diabolical logistics - Oregon trail pact with the devil * 2024/ferguson2 - Prize in yil-tas - Navajo code talker translator * 2024/howe - Nice accent eh-ward - mini vi * 2024/kramer - Prize in linguistic arithmetic - natural language numerical calculator * 2024/kurdyukov1 - Prize in phased periodicity - phase of the Moon * 2024/kurdyukov2 - Prize in art restoration - JPEG artifact removal * 2024/kurdyukov3 - Prize in virtual quietus - gaming VM and doom * 2024/kurdyukov4 - Prize in embiggening - encode without literals * 2024/maffiodo - Prize in creative interpretation - Jav\*script interpreter * 2024/mills - Prize in ℤ₃ - Infocom v3 story interpreter * 2024/stedolan - Best one liner - icon from MD5 * 2024/straadt - Prize in imitative rebooting - OpenRISC CPU and Linux * 2024/tmarrec - Prize in cyclonic coding - 3D tornado simulation * 2024/tompng - Prize in quasi bijection - vortex encryptor decryptor * 2024/weaver - Sur prize - rickroll Ran `make update` to perform the above. new file: 2024/burton/.entry.json
2613 lines
125 KiB
HTML
2613 lines
125 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.47 2025-03-15</strong>.
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
<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 class="leftbar">
|
||
<strong>NOTE</strong>: the updates to these guidelines on 2025-03-10 explained the new <code>-u uuidfile</code> and <code>-U uuidstr</code> options and are <strong>NOT</strong> important to read, in order
|
||
to follow the guidelines. The options are in a release <strong>AFTER THIS</strong> IOCCC’s
|
||
official release and not updating the toolkit is <strong>PERFECTLY</strong> okay.
|
||
</p>
|
||
<p class="leftbar">
|
||
<strong>NOTE</strong>: the updates to these guidelines on 2025-03-12 also explain how the
|
||
tools that require other tools now search under <code>$PATH</code>. It is perfectly fine to
|
||
not use the newer versions so long as you use the minimum required version of
|
||
the tools. See the
|
||
FAQ on “<a href="../faq.html#minimum_versions">minimum required version of the tools</a>”
|
||
for more details and the
|
||
FAQ on “<a href="../faq.html#obtaining_mkiocccentry">obtaining the most recent release of the
|
||
toolkit</a>”
|
||
for more help.
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
See the
|
||
FAQ on “<a href="../quick-start.html#enter">how to register and submit to the IOCCC</a>”
|
||
for instructions on registering and participating in the IOCCC, as the process
|
||
may change from contest to contest.
|
||
</p>
|
||
<p class="leftbar">
|
||
To assist in the formation of the xz compressed tarball for submission, use the
|
||
<code>mkiocccentry(1)</code> tool as found in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
We <strong>STRONGLY</strong> recommend you <strong>do</strong> install the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
<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 class="leftbar">
|
||
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 class="leftbar">
|
||
See also the
|
||
FAQ on “<a href="../faq.html#minimum_versions">what the minimum required versions are for this
|
||
contest</a>”
|
||
for more details on how to verify you have the correct versions for this
|
||
contest.
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
<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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
The <a href="rules.html#rule2b">Rule 2b</a> size has <strong>increased from 2053 to 2503</strong>
|
||
bytes.
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
When ‘<code>;</code>’, ‘<code>{</code>’ or ‘<code>}</code>’ are within a C string, they may still not be
|
||
counted by the IOCCC size tool. This is a <strong>feature</strong>, not a bug!
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
In other words, make sure <code>iocccsize</code> does not flag any issues with your
|
||
<code>prog.c</code>.
|
||
</p>
|
||
<p class="leftbar">
|
||
There are at least 2 other reasons for selecting 2503 as the 2nd limit besides
|
||
the fact that 2503 is a prime. These reasons may be searched for and discovered
|
||
if you are <a href="https://t5k.org/curios/page.php/2503.html">“Curios!” about 2503</a>.
|
||
:-) Moreover, 2053 was the number of the kernel disk pack of one of the judge’s
|
||
BESM-6, and 2503 is a decimal anagram of 2053.
|
||
</p>
|
||
<p>Take note that this secondary limit imposed by the IOCCC size tool
|
||
obviates some of the need to <code>#define</code> C reserved words in an effort
|
||
to get around the size limits of <a href="rules.html#rule2">Rule 2</a>.</p>
|
||
<p>Yes Virginia, <strong>that is a hint</strong>!</p>
|
||
<p class="leftbar">
|
||
The <strong>official locale</strong> of the <strong>IOCCC</strong> is <strong>C</strong>.
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
When we do need to plug a hole in the <a href="rules.html">IOCCC rules</a> or <a href="guidelines.html">IOCCC
|
||
guidelines</a>, we will attempt to use a very small plug, if not
|
||
smaller. Or, maybe not. :-)
|
||
</p>
|
||
<p class="leftbar">
|
||
There may be fewer than 2^7+1 reasons why these <a href="guidelines.html">IOCCC
|
||
guidelines</a> seem obfuscated.
|
||
</p>
|
||
<p class="leftbar">
|
||
<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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
We tend to look down on a <a href="https://en.wikipedia.org/wiki/Prime_number">prime
|
||
number</a> printer that claims that
|
||
16 is a prime number.
|
||
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 class="leftbar">
|
||
<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 class="leftbar">
|
||
See the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>
|
||
for the <code>mkiocccentry(1)</code> tool and below for more details.
|
||
</p>
|
||
<p class="leftbar">
|
||
<strong>IMPORTANT NOTE</strong>: make <strong>CERTAIN</strong> you have the most recent version of the
|
||
<code>mkiocccentry</code> toolkit! See the
|
||
FAQ on “<a href="../faq.html#obtaining_mkiocccentry">obtaining the mkiocccentry toolkit</a>”.
|
||
</p>
|
||
<p class="leftbar">
|
||
<code>mkiocccentry</code> runs a number of checks, by the tool itself and by executing
|
||
other tools, <em>before</em> packaging your xz compressed tarball, including running
|
||
<code>chkentry(1)</code> on the submission directory.
|
||
</p>
|
||
<p class="leftbar">
|
||
If <code>mkiocccentry</code> encounters an <strong>error</strong>, the program will exit and the xz
|
||
compressed tarball <strong>will not be formed</strong>. For instance, if
|
||
<a href="#chkentry">chkentry</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 class="leftbar">
|
||
Once the tarball is packaged it will
|
||
run <code>txzchk(1)</code>, which will also run <code>fnamchk(1)</code>, as part of its algorithm.
|
||
</p>
|
||
<p class="leftbar">
|
||
However, even if <code>mkiocccentry</code> or one of the tools it invokes reports an error,
|
||
it <strong>does not</strong> necessarily mean it is a bug in the code. It might be an issue with
|
||
your submission. Thus if you report an error as a bug it might not be something
|
||
that will be fixed as there might not be anything wrong with the tools.
|
||
</p>
|
||
<p class="leftbar">
|
||
On the other hand, some conditions 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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
<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>chkentry(1)</code>, <code>txzchk(1)</code> and <code>fnamchk(1)</code>.
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
The synopsis of the <code>mkiocccentry(1)</code> tool is:
|
||
</p>
|
||
<pre><code> mkiocccentry [options] workdir topdir</code></pre>
|
||
<p class="leftbar">
|
||
To help you with editing a submission, the <code>mkiocccentry(1)</code> tool has
|
||
some options to write <em>OR</em> read from an answers file so you do not have to input
|
||
the information about the author(s) and the submission more than once, unless of
|
||
course you need to make some changes, in which case you can use the option that
|
||
overwrites the file. If you do use the overwrite option, <strong>MAKE SURE</strong> you do
|
||
not overwrite another file!
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
The <code>mkiocccentry(1)</code> tool will execute a number of tools, some of which will
|
||
execute one or more additional tools.
|
||
</p>
|
||
<h2 id="iocccsize"><code>iocccsize</code></h2>
|
||
<p class="leftbar">
|
||
<code>mkiocccentry(1)</code> will use code from <code>iocccsize(1)</code> which detects a number of
|
||
issues (such as <a href="rules.html#rule2">Rule 2</a>) that you may ignore, if you wish, as
|
||
noted above.
|
||
</p>
|
||
<p class="leftbar">
|
||
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="chkentry"><code>chkentry</code></h2>
|
||
<p class="leftbar">
|
||
<code>mkiocccentry(1)</code> will write two JSON files: <code>.auth.json</code> and
|
||
<code>.info.json</code>. These files contain information about the author(s) and about the
|
||
submission. After these files are formed, the <code>chkentry(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>chkentry(1)</code> fails to validate
|
||
anything at all, your submission <strong>WILL BE</strong> rejected!
|
||
</p>
|
||
<p class="leftbar">
|
||
<strong>IMPORTANT</strong>: although <code>chkentry(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 class="leftbar">
|
||
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">
|
||
If <code>chkentry</code> does not pass and you used <code>mkiocccentry(1)</code> it is <strong>very likely</strong> a
|
||
bug and you should <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the mkiocccentry issues
|
||
page</a>.
|
||
<strong>PLEASE</strong> run the command:
|
||
</p>
|
||
<pre><code> make bug_report</code></pre>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
Assuming that <code>chkentry(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 class="leftbar">
|
||
If <code>mkiocccentry(1)</code> is used and <code>chkentry(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>chkentry(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 class="leftbar">
|
||
If you want to know what <code>.auth.json</code> is, see the
|
||
FAQ on “<a href="../faq.html#auth_json">.auth.json</a>”.
|
||
If you want to know what the <code>.info.json</code> file is, see the
|
||
FAQ on “<a href="../faq.html#info_json">.info.json</a>”.
|
||
On the other hand, if you want to know a bit more details about <code>chkentry(1)</code>, see the
|
||
FAQ about “<a href="../faq.html#chkentry">chkentry</a>”.
|
||
</p>
|
||
<p class="leftbar">
|
||
<code>chkentry</code> uses the <code>jparse</code> library. See the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/README.md">jparse
|
||
README.md</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/tree/master/jparse">mkiocccentry GitHub repo subdirectory
|
||
jparse</a> as well as
|
||
the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jparse_library_README.md">jparse library README.md
|
||
file</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/tree/master/jparse">mkiocccentry GitHub repo subdirectory
|
||
jparse</a>, for more
|
||
details.
|
||
</p>
|
||
<p class="leftbar">
|
||
The <code>jparse</code> parser, library and tools were co-developed by <a href="../authors.html#Cody_Boone_Ferguson">Cody Boone
|
||
Ferguson</a> and <a href="http://www.isthe.com/chongo/index.html">Landon Curt
|
||
Noll</a> in 2022-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 class="leftbar">
|
||
You do <strong>NOT need to install</strong> <code>jparse</code> from the <a href="https://github.com/xexyl/jparse">jparse
|
||
repo</a>! The <code>mkiocccentry</code> tools link in the
|
||
static library from <code>mkiocccentry</code>’s <em>clone</em>.
|
||
</p>
|
||
<p class="leftbar">
|
||
The <code>mkiocccentry</code> toolkit <em>also</em> has a clone of <em>both</em> the <a href="https://github.com/lcn2/dbg">dbg
|
||
library</a> and the
|
||
<a href="https://github.com/lcn2/dyn_array">dyn_array library</a>; the <a href="https://github.com/lcn2/dyn_array">dyn_array
|
||
library</a> uses the <a href="https://github.com/lcn2/dbg">dbg
|
||
library</a> and the <a href="https://github.com/xexyl/jparse">jparse
|
||
library</a> uses both libraries but unlike in the
|
||
<a href="https://github.com/xexyl/jparse">jparse repo</a>, the libraries do not need to be
|
||
installed separately, in order to use the tools in <code>mkiocccentry</code>.
|
||
</p>
|
||
<p class="leftbar">
|
||
In other words, <code>mkiocccentry</code> <strong>contains everything</strong> you need, and <em>even if you
|
||
do install</em> the libraries from their respective repos, it/they will <strong>not be
|
||
used</strong> when compiling the <code>mkiocccentry</code> tools. This is important to
|
||
make sure that you’re using the correct versions, which is also verified by
|
||
<code>chkentry</code> (in the JSON files created by <code>mkiocccentry(1)</code>). See <a href="rules.html#rule17">Rule
|
||
17</a>!
|
||
</p>
|
||
<p class="leftbar">
|
||
Please see the
|
||
FAQ on “<a href="../faq.html#chkentry">validating your submission directory</a>
|
||
for more details on <code>chkentry(1)</code>.
|
||
</p>
|
||
<p class="leftbar">
|
||
You might also wish to see the
|
||
FAQ on “<a href="../faq.html#auth_json">.auth.json</a>”
|
||
and the
|
||
FAQ on “<a href="../faq.html#info_json">.info.json</a>”
|
||
for much more information on these files.
|
||
</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<h2 id="txzchk"><code>txzchk</code></h2>
|
||
<p class="leftbar">
|
||
<code>txzchk(1)</code> performs a wide number of sanity checks on the xz compressed
|
||
tarball; if any issues are found (‘<code>feathers are stuck in the tarball</code>’ :-) )
|
||
<strong>AND if and <em>ONLY IF</em> you used <code>mkiocccentry(1)</code></strong>, then it is <strong>possibly</strong> a
|
||
bug in one of the tools and you might want to <a href="https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E">report it as a bug at the
|
||
mkiocccentry 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 class="leftbar">
|
||
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 class="leftbar">
|
||
It is beyond the scope of this document to discuss the many tests that
|
||
<code>txzchk(1)</code> performs; if you wish to know, we refer you to the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c">source
|
||
code</a> or the man
|
||
page. You might just find a fun option if you do either of these!
|
||
</p>
|
||
<p class="leftbar">
|
||
Of course, as <code>txzchk</code> does not extract the tarball, it is possible that if you
|
||
manually package your submission tarball 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 files that may be submitted has changed to <strong>39</strong> files.
|
||
However, of those files, <strong>5</strong> are mandatory (<code>prog.c</code>, <code>Makefile</code>, <code>remarks.md</code> and
|
||
the two JSON files generated by <code>mkiocccentry(1)</code>, <code>.info.json</code> and
|
||
<code>.auth.json</code>).
|
||
</p>
|
||
<p class="leftbar">
|
||
Additionally, three of the files, if included, <strong>MUST</strong> be
|
||
specific file(name)s <strong>AND</strong> in the top level directory, or they will be counted as
|
||
an extra file, not an optional file.
|
||
</p>
|
||
<p class="leftbar">
|
||
In particular, any file that is not <code>prog.c</code>, <code>Makefile</code>, <code>remarks.md</code>,
|
||
<code>try.sh</code>, <code>prog.alt.c</code> or <code>try.alt.sh</code> will be counted as an extra file, and if
|
||
<code>try.sh</code>, <code>prog.alt.c</code> or <code>try.alt.sh</code> are not in the top level submission
|
||
directory they will also be counted as an extra file. The <code>.info.json</code> and
|
||
<code>.auth.json</code> files are not counted as extra files but are required.
|
||
</p>
|
||
<p class="leftbar">
|
||
In other words, the actual amount of <strong>EXTRA</strong> files is <strong>31</strong>.
|
||
</p>
|
||
<p class="leftbar">
|
||
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. For more details on the optional files, see the
|
||
FAQ on the “<a href="../faq.html#try_script">try.sh script system</a>”
|
||
and the
|
||
FAQ on “<a href="../faq.html#alt_code">alt code</a>”.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you <strong>REALLY 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">
|
||
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. Even so, if you
|
||
include a tarball to get past the limit on the number of files, you <strong>MUST</strong>
|
||
justify this in your <code>remarks.md</code> file.
|
||
</p>
|
||
<p class="leftbar">
|
||
<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 class="leftbar">
|
||
See <a href="rules.html#rule17">Rule 17</a> and in particular the part about the <a href="../faq.html#max-files">maximum
|
||
number of files</a>. If you do not follow these points, you
|
||
are at a great risk of violating <a href="rules.html#rule17">Rule 17</a>!
|
||
</p>
|
||
<p class="leftbar">
|
||
<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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
For more information on <code>fnamchk</code> and how to manually validate your submission
|
||
tarball filename, see the
|
||
FAQ on “<a href="../faq.html#fnamchk">fnamchk</a>”.
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
As you can see, the use of <code>mkiocccentry(1)</code> is <strong>HIGHLY RECOMMENDED</strong>, and at
|
||
the risk of stating the obvious, you run <strong>A VERY BIG RISK</strong> of having
|
||
your submission rejected if you package your own tarball, and there are <strong>ANY
|
||
problems</strong>. For instance, if <code>chkentry(1)</code> found a problem in your <code>.info.json</code>
|
||
file, the <code>mkiocccentry(1)</code> tool would not package it. But if you were to package
|
||
it manually, you would be violating <a href="rules.html#rule17">Rule 17</a>. But even if
|
||
everything checks out OK you should <strong>NOT</strong> assume that everything <strong>IS</strong> OK.
|
||
</p>
|
||
<div id="bugs">
|
||
<h1 id="problems-andor-bugs-in-tools">Problems and/or bugs in tools</h1>
|
||
</div>
|
||
<p class="leftbar">
|
||
Although the tools have been tested 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 class="leftbar">
|
||
Of course, it is also possible for <code>mkiocccentry(1)</code>, or one or more of the
|
||
tools it executes (or another tool executes), to fail, but <strong>NOT</strong> because of a
|
||
bug. An example problem is if there is not enough memory available or if some
|
||
other library or syscall fails. Nonetheless it might be worth reporting as a
|
||
bug; it is a judgement call: if it’s a bug it’ll be addressed and if it’s not
|
||
that’s OK too!
|
||
</p>
|
||
<div id="make">
|
||
<div id="makefile">
|
||
<h1 id="makefiles">Makefiles</h1>
|
||
</div>
|
||
</div>
|
||
<p class="leftbar">
|
||
We <strong>recommend</strong> AND <strong>encourage</strong> you to use the example Makefile,
|
||
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 class="leftbar">
|
||
Feel free to modify the <code>Makefile</code> to suit your obfuscation
|
||
needs.
|
||
</p>
|
||
<p class="leftbar">
|
||
<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">
|
||
The rest of this section and its subsections will assume that you are using some
|
||
variant of the example <code>Makefile</code>, again renamed as <code>Makefile</code>.
|
||
</p>
|
||
<p class="leftbar">
|
||
We suggest that you compile your submission with a commonly available
|
||
<code>-std=gnu17</code> (ISO C 2017 with GNU extensions) C compiler, 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 class="leftbar">
|
||
Unless you <strong>clearly state</strong> otherwise in your <code>remarks.md</code> file, <strong>AND</strong> put in
|
||
your submission’s <code>Makefile</code>, we <strong>will</strong> compile using <code>-std=gnu17 -O3</code>!
|
||
</p>
|
||
<p class="leftbar">
|
||
It <strong>is OK</strong> if you need to require your submission to <strong>NOT be</strong> compiled
|
||
using the default <code>-std=gnu17 -O3</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">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
<strong>IMPORTANT NOTE</strong>: The use of <code>-std=gnu17</code> does <strong>NOT</strong> imply the use of the <code>gcc</code>
|
||
compiler! We often start by compiling using the <strong>clang</strong> C compiler instead.
|
||
</p>
|
||
<p class="leftbar">
|
||
<strong>PLEASE NOTE</strong>: in macOS, the compiler <code>gcc</code> found at <code>/usr/bin/gcc</code> is
|
||
in truth the <code>clang</code> compiler, as <code>/usr/bin/gcc --version</code> will show!
|
||
</p>
|
||
<div id="cstd">
|
||
<div id="standard">
|
||
<h2 id="c-standard">C standard</h2>
|
||
</div>
|
||
</div>
|
||
<p class="leftbar">
|
||
You may change the standard under which your submission is compiled
|
||
by modifying the <code>CSTD</code> Makefile variable. For example, to use <code>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 class="leftbar">
|
||
You may change the level of optimization and compiler debug level
|
||
that your submission is compiled with, by modifying the <code>OPT</code> Makefile variable.
|
||
For example, to compile without optimization, and to include debug symbols:
|
||
</p>
|
||
<pre><code> OPT= -O0 -g3</code></pre>
|
||
<div id="warnings">
|
||
<div id="cwarn">
|
||
<h2 id="compiler-warnings">Compiler warnings</h2>
|
||
</div>
|
||
</div>
|
||
<p class="leftbar">
|
||
The default warning flags are set via the <code>CWARN</code> variable, as shown in the
|
||
example <code>Makefile</code>:
|
||
</p>
|
||
<pre><code> # Common C compiler warning flags
|
||
#
|
||
CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN}</code></pre>
|
||
<p class="leftbar">
|
||
For details on <code>CSILENCE</code> and <code>CUNKNOWN</code>, see the <a href="#disabling-warnings">section on disabling
|
||
warnings</a>.
|
||
</p>
|
||
<div id="weverything">
|
||
<h3 id="the--weverything-option">The <code>-Weverything</code> option</h3>
|
||
</div>
|
||
<p class="leftbar">
|
||
For compilers, such as <code>clang</code>, that have the <code>-Weverything</code> option,
|
||
while you may wish to try it, you should read our
|
||
FAQ on “<a href="../faq.html#weverything">clang -Weverything</a>”.
|
||
We do <strong>NOT</strong> recommend that you put
|
||
the use of <code>-Weverything</code> into your submission’s <code>Makefile</code> for the reasons
|
||
cited there. This goes even if your version does not trigger a warning as some
|
||
other version might!
|
||
</p>
|
||
<p class="leftbar">
|
||
On the other hand, if <code>${CC}</code> has “<code>clang</code>” in the name, the example <code>Makefile</code> will
|
||
automatically enable <code>-Weverything</code>, so you might have to use <code>-Wno-foo</code>
|
||
options anyway, as detailed below. See the
|
||
FAQ on “<a href="../faq.html#weverything">-Weverything</a>”
|
||
for more details.
|
||
</p>
|
||
<p class="leftbar">
|
||
If “<code>clang</code>” is NOT in <code>${CC}</code>, the <code>CWARN</code> variable will not be further
|
||
modified.
|
||
</p>
|
||
<p class="leftbar">
|
||
There is no real penalty for compiler warnings. Sometimes
|
||
compiler warnings cannot be helped: especially in the case of
|
||
obfuscated C. :-) So if you cannot easily get rid of a compiler
|
||
warning, try not to fret too much.
|
||
</p>
|
||
<p class="leftbar">
|
||
We <strong>LIKE</strong> code that has a minimum of warnings, especially under the
|
||
more strict <code>-Wall -Wextra -pedantic</code> mode:
|
||
</p>
|
||
<pre><code> CWARN= -Wall -Wextra -pedantic</code></pre>
|
||
<p class="leftbar">
|
||
The two previous guidelines might be thought by some as being somewhat
|
||
contradictory. Isn’t life, and isn’t trying to satisfy “contradictory customer
|
||
requirements” all too often like that? :-) Try to minimize warnings if you
|
||
can.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you manage to produce very few warnings, or perhaps no warnings at
|
||
all under the <code>-Wall -Wextra -pedantic</code> mode, then by all means brag about it in
|
||
your <code>remarks.md</code> file <strong>AND BE SURE TO TELL US</strong> the OS, OS version, compiler
|
||
and compiler version in which you observed this occurring (in case our OS and
|
||
compiler produces a different result: so your submission won’t be penalized for
|
||
not meeting your claims).
|
||
</p>
|
||
<p class="leftbar">
|
||
On the other hand, some warnings cannot be disabled and are enabled by compilers
|
||
without any warning option specified. These are sometimes inevitable in
|
||
obfuscated code and even in some non-obfuscated code, and you should not worry
|
||
about this, though it might be worth pointing out.
|
||
</p>
|
||
<p class="leftbar">
|
||
For instance, some compilers like to warn about use of 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 class="leftbar">
|
||
If your submission issues lots of warnings but is otherwise
|
||
marvelously obfuscated in multiple levels, don’t worry about it. Nevertheless,
|
||
be sure that the warnings do not constitute a potential “<strong>show stopper</strong>”
|
||
compiler problem. Be sure that compilers such as both <code>gcc</code> and <code>clang</code> won’t
|
||
produce a compiler <strong>error</strong> and refuse to compile your code: unless for some
|
||
reason that is what you intend to happen in which case document that too in your
|
||
<code>remarks.md</code> file. :-)
|
||
</p>
|
||
<p>All other things being equal, a program that must turn off fewer
|
||
warnings will be considered better, for certain values of better.</p>
|
||
<p class="leftbar">
|
||
To turn off a compiler warning, in your submission’s <code>Makefile</code>,
|
||
try something such as:
|
||
</p>
|
||
<pre><code> CSILENCE= -Wno-some-thing -Wno-another-thing</code></pre>
|
||
<p class="leftbar">
|
||
For instance:
|
||
</p>
|
||
<pre><code> CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation</code></pre>
|
||
<p class="leftbar">
|
||
If you do add “<code>-Wno-foo</code>” to your Makefile, consider changing:
|
||
</p>
|
||
<pre><code> CUNKNOWN=</code></pre>
|
||
<p class="leftbar">
|
||
to:
|
||
</p>
|
||
<pre><code> CUNKNOWN= -Wno-unknown-warning-option</code></pre>
|
||
<p class="leftbar">
|
||
Some compilers have reported this as an error, however, and if you have
|
||
such a compiler you might want to not add it, or at least note in your
|
||
<code>remarks.md</code> file, which OS, OS version, compiler and compiler version
|
||
that has such a problem.
|
||
</p>
|
||
<div id="macros">
|
||
<h2 id="defining-macros-in-the-makefile">Defining macros in the Makefile</h2>
|
||
</div>
|
||
<p class="leftbar">
|
||
If you need to define something on the compile line, use
|
||
the <code>CDEFINE</code> Makefile variable. For example:
|
||
</p>
|
||
<pre><code> CDEFINE= -Dfoo -Dbar=baz</code></pre>
|
||
<p class="leftbar">
|
||
<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 class="leftbar">
|
||
If you need to include a file (as in <code>#include</code>) on the command line, use the
|
||
<code>CINCLUDE</code> Makefile variable. For example:
|
||
</p>
|
||
<pre><code> CINCLUDE= -include stdio.h</code></pre>
|
||
<div id="magic">
|
||
<h2 id="magic-in-the-makefile">Magic in the Makefile</h2>
|
||
</div>
|
||
<p class="leftbar">
|
||
If you need to add other “<strong>magic</strong>” flags to your compile line,
|
||
use the <code>COTHER</code> Makefile variable. For example:
|
||
</p>
|
||
<pre><code> COTHER= -fno-math-errno</code></pre>
|
||
<p class="leftbar">
|
||
<strong>NOTE</strong>: <strong>We only recommend using “<em>magic</em>” flags if <em>BOTH</em> <code>gcc</code>
|
||
<em>and</em> <code>clang</code></strong> support it.
|
||
</p>
|
||
<p class="leftbar">
|
||
Again, please note that in macOS, <code>/usr/bin/gcc</code> is actually <code>clang</code>!
|
||
</p>
|
||
<div id="clobber">
|
||
<h2 id="the-clobber-rule">The clobber rule</h2>
|
||
</div>
|
||
<p class="leftbar">
|
||
When <code>make clobber</code> is invoked, we request that submissions be restored
|
||
to their original submission state. For example, any temporary files
|
||
(<strong>including</strong> the compiled program(s)) created during the build process, or
|
||
during execution should be removed by the <code>clobber</code> rule. In other words, the
|
||
only things that should be in the directory after running <code>make clobber</code> is what
|
||
is in your submission tarball itself.
|
||
</p>
|
||
<p class="leftbar">
|
||
While people are free to 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 class="leftbar">
|
||
The <code>mkiocccentry(1)</code> tool will ignore dot-files and dot-directories (such as
|
||
<code>.vimrc</code>, <code>.bashrc</code>, <code>.git</code> and <code>.github</code>) and not put them in the submission’s
|
||
compressed tarball. So while you may use such files and
|
||
directories to help develop your submission, they won’t be included when you run
|
||
the <code>mkiocccentry(1)</code> tool.
|
||
</p>
|
||
<p class="leftbar">
|
||
Even if you did manage to get 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 class="leftbar">
|
||
You may use whatever tools you need to develop your submission, including the
|
||
use of <code>git(1)</code> or <code>gh(1)</code>, just be sure that your submission code and your
|
||
submission Makefile don’t depend on such tools.
|
||
</p>
|
||
<p class="leftbar">
|
||
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">
|
||
If this is not clear, please do <strong>NOT</strong> use these tools to help with the
|
||
<code>clobber</code> rule! For instance, do <strong>NOT</strong> use <code>git clean</code>! Not only does this
|
||
depend on the user having <code>git(1)</code> but it also does not account for the
|
||
submission tarballs. Even worse is when someone does have it in a <code>git(1)</code> repo
|
||
it will remove files that are not under <code>git(1)</code> control! Instead, see the
|
||
<code>clobber</code> rule in the example Makefile to see how to manage this.
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
And do <strong>NOT</strong> use <code>git</code> for any other <code>Makefile</code> rule either.
|
||
</p>
|
||
<p class="leftbar">
|
||
<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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
We <strong>LIKE</strong> submissions that use an edited version of the
|
||
<code>try.sh</code> example script (and if you have alternate code,
|
||
the same applies with the <code>try.alt.sh</code> script):
|
||
</p>
|
||
<ul>
|
||
<li><p><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 class="leftbar">
|
||
Of course, it is quite possible that only one invocation is
|
||
possible, so it is not necessarily detrimental to your submission if you do not
|
||
include one, though we do like interesting and creative uses of submissions. See
|
||
also the
|
||
FAQ on “<a href="../faq.html#try_scripts">submitting try.sh and try.alt.sh scripts</a>”.
|
||
</p>
|
||
<p class="leftbar">
|
||
You might wish to add <code>./try.sh</code> to the <code>try</code> rule in the Makefile you submit.
|
||
If you have alternate code, then you can use 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 class="leftbar">
|
||
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 class="leftbar">
|
||
We tend to <strong>like <em>less</em></strong> a submission that requires either
|
||
<code>gcc</code> <strong>OR</strong> <code>clang</code>. <strong>We <em>prefer</em> submissions</strong> that can compile
|
||
under <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>.
|
||
</p>
|
||
<p class="leftbar">
|
||
We <strong>RECOMMEND</strong> that the compiler flags you use in your
|
||
submission’s <code>Makefile</code> are supported by <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>.
|
||
</p>
|
||
<p class="leftbar">
|
||
We <strong>DISLIKE</strong> the use of obscure compiler flags, especially
|
||
if <code>gcc</code> and/or <code>clang</code> do not support it. We <strong>suggest</strong>
|
||
that you not use any really obscure compiler flags if you can help it.
|
||
</p>
|
||
<p>One side effect of the above is that you cannot assume the use
|
||
of nested functions such as:</p>
|
||
<pre><code> 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 class="leftbar">
|
||
We <strong>DISLIKE</strong> submissions that require the use of <code>-fnested-functions</code>.
|
||
</p>
|
||
<p>We prefer programs that do not require a fish license: crayons and
|
||
cat detector vans not withstanding.</p>
|
||
<p>If your submission uses functions that have a variable number of
|
||
arguments, <strong>be careful</strong>. Systems implement <code>va_list</code> in a wide variety
|
||
of ways. Because of this, a number of operations using <code>va_list</code> <strong>are
|
||
not portable and <em>must not</em> be used</strong>:</p>
|
||
<ul>
|
||
<li>assigning a non-<code>va_list</code> variable to/from a <code>va_list</code> variable</li>
|
||
<li>casting a non-<code>va_list</code> variable into/from a <code>va_list</code> variable</li>
|
||
<li>passing a <code>va_list</code> variable to a function expecting a non-<code>va_list</code> arg</li>
|
||
<li>passing a non-<code>va_list</code> variable to a function expecting a <code>va_list</code> arg</li>
|
||
<li>performing arithmetic on <code>va_list</code> variables</li>
|
||
<li>using <code>va_list</code> as a structure or union</li>
|
||
</ul>
|
||
<p>In particular, do not treat <code>va_list</code> variables as if they were a <code>char **</code>.</p>
|
||
<p class="leftbar">
|
||
We <strong>DISLIKE</strong> the use of <code>varargs.h</code>. Use <code>stdarg.h</code> instead.
|
||
</p>
|
||
<p class="leftbar">
|
||
We <strong>DISLIKE</strong> the use of <code>gets(3)</code>. Use <code>fgets(3)</code> instead.
|
||
</p>
|
||
<p class="leftbar">
|
||
We tend to <strong>DISLIKE</strong> the blatant use of tarballs in an attempt to simply get
|
||
around the extra file number limit. We realize there may be cases where a
|
||
tarball containing a number of extra files may be needed. Such a need for a
|
||
tarball <strong>MUST</strong> be explained in the <code>remarks.md</code> file.
|
||
</p>
|
||
<p>On 28 January 2007, the Judges rescinded the requirement that the
|
||
<code>#</code> in a C preprocessor directive must be the 1st non-whitespace 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 class="leftbar">
|
||
While those who are used to temperatures found on <a href="https://science.nasa.gov/dwarf-planets/">dwarf
|
||
planets</a>
|
||
(<strong>yes Virginia, dwarf planets <em>ARE</em> planets!</strong>), such as
|
||
<a href="https://science.nasa.gov/dwarf-planets/pluto/">Pluto</a>, might be able to
|
||
explain to the Walrus why our seas are boiling hot, the question of
|
||
whether pigs have wings is likely to remain a debatable point to most.
|
||
</p>
|
||
<p class="leftbar">
|
||
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><p class="leftbar">
|
||
won’t compile or run in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>
|
||
environment
|
||
</p></li>
|
||
<li><p class="leftbar">
|
||
depend on a utility or application not normally found
|
||
in systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>
|
||
</p></li>
|
||
<li>abuse the build file to get around the size limit<br></li>
|
||
<li><p class="leftbar">
|
||
obfuscate by use of ANSI trigraphs
|
||
</p></li>
|
||
<li><p class="leftbar">
|
||
obfuscate by use of digraphs
|
||
</p></li>
|
||
<li><p class="leftbar">
|
||
are larger than they need to be
|
||
</p></li>
|
||
<li><p class="leftbar">
|
||
have more lines than they need to have
|
||
</p></li>
|
||
<li><p class="leftbar">
|
||
are “blob-ier” (just a pile of unformatted C code)
|
||
than they need to be
|
||
</p></li>
|
||
<li><p class="leftbar">
|
||
are rather similar to <strong><a href="../years.html">previous
|
||
winners</a></strong> :-(
|
||
</p></li>
|
||
<li><p class="leftbar">
|
||
are <strong>identical</strong> to <strong><a href="https://en.wikipedia.org/wiki/Null_device">previous
|
||
losers</a></strong> :-)
|
||
</p></li>
|
||
<li>that mandate the exclusive use of a specific Integrated Development Environment (IDE)</li>
|
||
</ul>
|
||
<p>In order to encourage submission portability, we <strong>DISLIKE</strong> 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 class="leftbar">
|
||
The program must compile and link cleanly in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>
|
||
environment. Therefore do not assume the system has a
|
||
<a href="https://en.wikipedia.org/wiki/Windows.h">windows.h</a> include file:
|
||
</p>
|
||
<pre><code> #include <windows.h> /* we DISLIKE this */</code></pre>
|
||
<p>Unless you are cramped for space, or unless you are entering the
|
||
‘<strong>Best one liner</strong>’ category, we suggest that you format your program
|
||
in a more creative way than simply forming excessively long lines.</p>
|
||
<p>At least one judge prefers to maintain the use of the
|
||
<a href="https://en.wikipedia.org/wiki/Leap_second">leap-second</a>
|
||
as part of the world’s time standard. If your code prints time
|
||
with seconds, we prefer that your code be capable of printing the
|
||
time of day during a leap-second where the value in seconds
|
||
after the minute mark is <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 class="leftbar">
|
||
Other windows, on the other hand, might be OK: especially where “<strong>X
|
||
marks the spot</strong>”. Yet on the third hand, windows are best when they are
|
||
“unseen” (i.e., not dirty). :-)
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
You should try to restrict commands used in the build file to commands found in
|
||
<a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>
|
||
environments and systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
You may compile and use your own programs. If you do, try to build and execute
|
||
from the current directory. This restriction is not a hard and
|
||
absolute one. The intent is to ensure that the building 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>We do not recommend submitting <a href="https://systemd.io">systemd</a> source code to the IOCCC,
|
||
if nothing else because that code is likely to exceed <a href="rules.html#rule2">the source code
|
||
size limit</a>. This isn’t to say that another highly compact and obfuscated
|
||
replacement of <code>init</code> would not be an interesting submission.</p>
|
||
<p>Did we remember to indicate that programs that blatantly use
|
||
some complex state machine to do something simple, are boring?
|
||
We think we did. :-)</p>
|
||
<blockquote>
|
||
<p>All generalizations are false, including this one. – <strong>Mark Twain</strong></p>
|
||
</blockquote>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
Unless you specify <code>-fwritable-strings</code> (see <code>COTHER</code> in the example
|
||
Makefile, described in the <a href="#makefile">Makefile section</a>), do not assume this
|
||
sort of code will work:
|
||
</p>
|
||
<pre><code> char *T = "So many primes, so little time!";
|
||
...
|
||
T[14] = ';'; /* modifying a string requires: -fwritable-strings */</code></pre>
|
||
<p class="leftbar">
|
||
Even so, one should probably not assume that this is universally accepted.
|
||
</p>
|
||
<p class="leftbar">
|
||
Initialized char arrays are OK to write over. For instance, this is OK:
|
||
</p>
|
||
<pre><code> char b[] = "Is this OK";
|
||
b[9] = 'k'; /* modifying an initialized char array is OK */</code></pre>
|
||
<p class="leftbar">
|
||
There are more than 1 typos in this very sentence.
|
||
</p>
|
||
<p>X client 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 class="leftbar">
|
||
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 class="leftbar">
|
||
However, do you know how to play <a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>?
|
||
You do?!? (Except on Tuesday?)
|
||
</p>
|
||
<p class="leftbar">
|
||
OK, there are actually 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 class="leftbar">
|
||
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 class="leftbar">
|
||
Try to avoid submissions that play music that some people believe is copyrighted
|
||
music.
|
||
</p>
|
||
<p class="leftbar">
|
||
While we recognize that UNIX is not a universal operating system, the contest
|
||
does have a bias towards such systems. In an effort to expand the scope of the
|
||
contest, we phrase our bias to favor the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
You are <strong>well advised</strong> to submit code that conforms to the <a href="https://unix.org/version4/overview.html">Single UNIX
|
||
Specification Version 4</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
To quote the <a href="../judges.html">IOCCC judges</a>:
|
||
</p>
|
||
<blockquote>
|
||
<p>You very well might not be completely prohibited from failing to not partly
|
||
misunderstand this particular <em>guideline</em>, but of course, we could not possibly
|
||
comment! :-) Nevertheless, you are neither prohibited, nor are you fully
|
||
required to determine that this or the previous sentence is either false and/or
|
||
perhaps misleading. Therefore, it might be wise for you to not fail to consider
|
||
to not do so, accordingly. Thank you very much.</p>
|
||
</blockquote>
|
||
<p>Any complaints about the above <em>guideline</em> could be addressed to the
|
||
Speaker of the House of Commons, or to the speaker of your national
|
||
parliament should you have one.</p>
|
||
<p>We <strong>LIKE</strong> programs that:</p>
|
||
<ul>
|
||
<li>are as concise and small as they need to be</li>
|
||
<li>do something at least quasi-interesting</li>
|
||
<li>are portable</li>
|
||
<li>are unique or novel in their obfuscation style</li>
|
||
<li>make use of a <strong>NUMBER OF DIFFERENT TYPES OF OBFUSCATIONS!</strong> <strong><== HINT!!</strong></li>
|
||
<li>make us laugh and/or throw up :-) (humor really helps!)</li>
|
||
<li>make us want to eat good chocolate</li>
|
||
</ul>
|
||
<p>Some types of programs can’t excel (anti-tm) in some areas. Your
|
||
program doesn’t have to excel in all areas, but doing well in several
|
||
areas really does help.</p>
|
||
<p class="leftbar">
|
||
You are better off explaining what your submission does in your
|
||
<code>remarks.md</code> file section rather than leaving it obscure for the
|
||
<a href="../judges.html">IOCCC judges</a> as we might miss something and/or be too tired to
|
||
notice.
|
||
</p>
|
||
<p class="leftbar">
|
||
Please avoid this specific individual <em>guideline</em>, if it at all possible.
|
||
</p>
|
||
<p class="leftbar">
|
||
We freely admit that interesting, creative or humorous comments in
|
||
your <code>remarks.md</code> file help your chances of winning. If you had to
|
||
read so many twisted submissions, you too would enjoy a good laugh or two.
|
||
We think the readers of the contest winners do as well. We do read
|
||
your <code>remarks.md</code> content during the judging process, so it is worth your
|
||
while to write 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">
|
||
<a href="rules.html#rule13">Rule 13</a> no longer discourages the use of UTF-8
|
||
characters in C code.
|
||
</p>
|
||
<p class="leftbar">
|
||
It is a very good idea to, in your <code>remarks.md</code> file, tell us why you
|
||
think your submission is obfuscated. This is particularly true if
|
||
your submission has some very subtle obfuscations that we might
|
||
otherwise overlook. <strong><<– Hint!</strong>
|
||
</p>
|
||
<p>Anyone can format their code into a dense blob. A really clever
|
||
author will try format their submission using a “normal” formatting style
|
||
such that at first glance (if you squint and don’t look at the details)
|
||
the code might pass for non-obfuscated C. Deceptive comments,
|
||
and misleading formatting, in some cases, may be a plus. On the
|
||
other hand, a misleading code style requires more source bytes.</p>
|
||
<p>If you do elect to use misleading formatting and comments, we
|
||
suggest you remark on this point in your <code>remarks.md</code> where you talk
|
||
about why you think your submission is obfuscated. On the other hand,
|
||
if you are pushing up against the size limits, you may be forced
|
||
into creating a dense blob. Such are the trade-offs that obfuscators face!</p>
|
||
<p class="leftbar">
|
||
We prefer code that can run on either a 64-bit or 32-bit
|
||
processor. However, it is <strong>UNWISE </strong>to assume it will run on an
|
||
some Intel-like x86 architecture**.
|
||
</p>
|
||
<p>We believe that Mark Twain’s quote:</p>
|
||
<blockquote>
|
||
<p>Get your facts first, then you can distort them as you please.</p>
|
||
</blockquote>
|
||
<p>… is a good motto for those writing code for the IOCCC.</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
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/chkentry.c">chkentry</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 class="leftbar">
|
||
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 class="leftbar">
|
||
<a href="rules.html#rule7">Rule 7</a> does not prohibit you from writing your own
|
||
obfuscated versions of these tools, unless of course you are <a href="http://www.isthe.com/chongo/index.html">Landon Curt
|
||
Noll</a>, in which case you <em>probably</em>
|
||
won’t win since <a href="../judges.html">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 class="leftbar">
|
||
Even so, we do not recommend you try and submit a JSON parser due to
|
||
the fact it will likely exceed <a href="rules.html#rule2">the source code size limit</a>
|
||
and because you likely can’t beat <a href="https://github.com/westes/flex">flex</a> 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 class="leftbar">
|
||
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 class="leftbar">
|
||
If your submission <strong>MUST</strong> run only on a 64-bit or 32-bit architecture,
|
||
then you <strong>MUST</strong> specify the <code>-arch</code> on your command line
|
||
(see <code>ARCH</code> in the example
|
||
Makefile, described in <a href="#makefile">Makefile section</a>). Do not assume a
|
||
processor word size without specifying <code>-arch</code>. For example:
|
||
</p>
|
||
<pre><code> ARCH= -m64</code></pre>
|
||
<p class="leftbar">
|
||
Note, however, that some platforms will not necessarily support some
|
||
architectures. For instance, more recent versions of <code>macOS</code> do <strong>NOT</strong> support
|
||
32-bit!
|
||
</p>
|
||
<p class="leftbar">
|
||
If there are limitations in your submission, you are highly encouraged
|
||
to note such limitations in your <code>remarks.md</code> file. For example if your
|
||
submission factors values up to a certain size, you might want to state:
|
||
</p>
|
||
<blockquote>
|
||
<p>This submission factors values up <code>2305567963945518424753102147331756070</code>.
|
||
Attempting to factor larger values will produce unpredictable results.</p>
|
||
</blockquote>
|
||
<p>The <a href="../judges.html">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 class="leftbar">
|
||
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 class="leftbar">
|
||
Do not fear if you’re not 100% sure of the significance of
|
||
<code>2305567963945518424753102147331756070</code> as it is not of prime importance: or is
|
||
it? :-)
|
||
</p>
|
||
<p class="leftbar">
|
||
We <strong>DISLIKE</strong> the use of ASCII tab characters in markdown files, such as in the required <code>remarks.md</code> file.
|
||
</p>
|
||
<p class="leftbar">
|
||
We don’t mind the use 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 class="leftbar">
|
||
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 class="leftbar">
|
||
<strong>PLEASE</strong> observe our <a href="../markdown.html">IOCCC markdown guidelines</a>
|
||
when forming your submission’s <code>remarks.md</code> file. And if your submission
|
||
contains additional markdown files, please follow those same guidelines for
|
||
those files. See also <a href="rules.html#rule19">Rule 19</a> and our
|
||
FAQ on “<a href="../faq.html#markdown">markdown</a>”.
|
||
</p>
|
||
<p class="leftbar">
|
||
We <strong>LIKE</strong> reading <code>remarks.md</code> files, especially if they contain
|
||
useful, informative, and even humorous content about your submission. Yes, this
|
||
is a <strong>hint</strong>. :-)
|
||
</p>
|
||
<p class="leftbar">
|
||
We <strong>RECOMMEND</strong> you put a reasonable amount effort into the content of the
|
||
<code>remarks.md</code> file: it is a required 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 class="leftbar">
|
||
If you intend to abuse the <a href="rules.html">IOCCC rules</a>,
|
||
indicate so in your <code>remarks.md</code> file. You <strong>MUST</strong> try to justify
|
||
why you consider your rule abuse to be allowed under the
|
||
<a href="rules.html">IOCCC rules</a>. That is, you must plead your case as to why
|
||
your submission is valid. Humor and/or creativity help plead a case.
|
||
As there is no guarantee that you will succeed, you might consider
|
||
submitting an alternate version that conforms to the
|
||
<a href="rules.html">IOCCC rules</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you do bypass the <code>mkiocccentry(1)</code> warnings about <a href="rules.html#rule2a">Rule
|
||
2a</a> and/or about <a href="rules.html#rule2b">Rule 2b</a> 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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
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 class="leftbar">
|
||
During the judging process, a process that spans multiple sessions over
|
||
a few weeks, we post general updates from our <a href="https://fosstodon.org/@ioccc">Mastodon
|
||
account</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
<strong>Make sure you reload the feed</strong> every so often <strong>because unless you
|
||
are mentioned you will NOT get a push notification!</strong>
|
||
</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="rounds">
|
||
<h2 id="judging-rounds">JUDGING ROUNDS:</h2>
|
||
</div>
|
||
<p>Judging consists of a number of elimination rounds. During a round,
|
||
the collection of 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><p class="leftbar">
|
||
Reading <code>prog.c</code>, the C source and reviewing the <code>remarks.md</code> information
|
||
</p></li>
|
||
<li><p class="leftbar">
|
||
Briefly looking at any supplied data files
|
||
</p></li>
|
||
<li>Passing the source thru the C pre-processor skipping over any <code>#include</code>d files</li>
|
||
<li>Performing a number of C beautify/cleanup edits on the source</li>
|
||
<li>Passing the beautified source thru the C pre-processor skipping over any <code>#include</code>d files</li>
|
||
<li>Compiling/building the source</li>
|
||
<li>Running the program</li>
|
||
<li>Doing other things that only <a href="../judges.html">IOCCC judges</a> know about :-)</li>
|
||
</ul>
|
||
<p>In later rounds, other actions are performed including performing
|
||
miscellaneous tests on the source and binary.</p>
|
||
<p class="leftbar">
|
||
This is the very <strong>guideline</strong> that goes, <strong>BING!</strong>
|
||
</p>
|
||
<p class="leftbar">
|
||
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><p class="leftbar">
|
||
<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>”)
|
||
</p></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 class="leftbar">
|
||
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">
|
||
One <strong>should NOT</strong> attempt to <strong>bribe</strong> an <a href="../judges.html">IOCCC
|
||
judge</a>, <strong>unless you are an <a href="../judges.html">IOCCC judge</a></strong>,
|
||
because <strong>bribing</strong> an <a href="../judges.html">IOCCC judge</a> by a non-judge
|
||
has been shown to <strong>NOT</strong> be effective when the <strong>person <em>attempting</em>
|
||
the <em>bribe</em> is made known</strong> to the <a href="../judges.html">IOCCC judges</a>
|
||
(i.e., they are not anonymous) AND/OR the <strong>bribe</strong> is otherwise
|
||
associated with a submission to the <a href="../index.html">IOCCC</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
With the previous guideline in mind: <strong>anonymous</strong> gifts
|
||
for the <a href="../judges.html">IOCCC judges</a> that are <strong>NOT ASSOCIATED
|
||
WITH</strong> a submission to the <a href="../index.html">IOCCC</a> may be sent to the
|
||
<a href="../judges.html">IOCCC judges</a> via the
|
||
<a href="https://www.amazon.com/hz/wishlist/ls/3HSNTEL8RQ1M0?ref_=wl_share">IOCCC Amazon wishlist</a>.
|
||
It has been shown that receiving <strong>anonymous</strong> gifts provides the
|
||
<a href="../judges.html">IOCCC judges</a> with a nice
|
||
<a href="https://en.wikipedia.org/wiki/Dopamine">dopamine</a> boost, and happy
|
||
<a href="../judges.html">IOCCC judges</a> help make the <a href="../index.html">IOCCC</a> better for everyone. :-)
|
||
</p>
|
||
<p class="leftbar">
|
||
See the
|
||
FAQ on “<a href="../faq.html#support">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 class="leftbar">
|
||
Nevertheless, see <a href="rules.html#rule12">Rule 12</a>.
|
||
</p>
|
||
<p>In the end, we traditionally pick one submission as ‘<strong>best</strong>’. Sometimes such
|
||
a submission simply far exceeds any of the other 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 class="leftbar">
|
||
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 class="leftbar">
|
||
We recommend that you follow us on mastodon but <strong>please make sure to
|
||
refresh the feed</strong> every so often (if not more often) because unless you are
|
||
mentioned or someone boosts your post you will not get a push notification.
|
||
</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="winners">
|
||
<h2 id="how-the-new-ioccc-winners-will-be-announced">How the new IOCCC winners will be announced</h2>
|
||
</div>
|
||
<p class="leftbar">
|
||
The <a href="../status.html">current status of the IOCCC</a> will change from
|
||
<strong><a href="../faq.html#judging">judging</a></strong> to <strong><a href="../faq.html#closed">closed</a></strong> .
|
||
</p>
|
||
<p class="leftbar">
|
||
The <strong>contest_status</strong> in the <a href="../status.json">status.json</a> file will change
|
||
from <strong>judging</strong> to <strong>closed</strong> as well.
|
||
</p>
|
||
<p class="leftbar">
|
||
When the above happens, the winning entries have been selected by the <a href="../judges.html">IOCCC
|
||
judges</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
The <a href="../judges.html">IOCCC judges</a> will begin to prepare to release the source
|
||
code of the new IOCCC winners.
|
||
</p>
|
||
<p class="leftbar">
|
||
The <a href="../judges.html">IOCCC judges</a> will commit the winning source to the
|
||
<a href="https://github.com/ioccc-src/winner">IOCCC winner repo</a> which will update the
|
||
<a href="https://www.ioccc.org/index.html">Official IOCCC website</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
The <a href="../news.html">IOCCC news</a> will also contain an announcement of the winners.
|
||
</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="mastodon">
|
||
<h2 id="an-important-update-to-how-winners-are-announced">An important update to how winners are announced</h2>
|
||
</div>
|
||
<p class="leftbar">
|
||
The IOCCC no longer uses twitter. 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 class="leftbar">
|
||
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 class="leftbar">
|
||
It is pointless to ask the <a href="../judges.html">IOCCC judges</a> how many
|
||
submissions we receive. See <a href="../faq.html#how_many">How many submissions do the judges receive for a
|
||
given IOCCC?</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
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 class="leftbar">
|
||
For questions or comments about the contest, see <a href="../contact.html">Contacting the IOCCC</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
<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 class="leftbar">
|
||
<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 class="leftbar">
|
||
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 class="leftbar">
|
||
Check out the <a href="https://www.ioccc.org/index.html">Official IOCCC winner website</a> in general.
|
||
</p>
|
||
<p class="leftbar">
|
||
Consider joining the IOCCC discord community via this link:
|
||
<a href="https://discord.gg/Wa42Qujwnw">https://discord.gg/Wa42Qujwnw</a>
|
||
</p>
|
||
<p class="leftbar">
|
||
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 -->
|