Fixed broken links. Restored text that was accidentally removed during the emergency recovery of guidelines some days back. Moved some text that was in the wrong place. The formatting of the markdown files was changed for shorter lines (for those viewing the markdown in a viewer rather than a web browser). Added a <div id> to 2024/index.html so the guidelines (or maybe rules) could link to the important note from the judges in IOCCC28. Restore rewording of rule 2b done by @SirWumpus.
1843 lines
86 KiB
HTML
1843 lines
86 KiB
HTML
<!DOCTYPE html>
|
||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||
<!-- START: two lines up starts content from: inc/top.default.html -->
|
||
|
||
<!-- END: this line ends content from: inc/top.default.html -->
|
||
<!-- START: this line starts content from: inc/head.default.html -->
|
||
|
||
<head>
|
||
<link rel="stylesheet" href="../ioccc.css">
|
||
<link href="https://fonts.googleapis.com/css2?family=Outfit:wght@100..900&display=swap" rel="stylesheet">
|
||
<meta charset="utf-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
|
||
<title>The International Obfuscated C Code Contest</title>
|
||
<link rel="icon" type="image/x-icon" href="../favicon.ico">
|
||
<meta name="description" content="IOCCC Guidelines">
|
||
<meta name="keywords" content="IOCCC, guidelines, Guidelines">
|
||
</head>
|
||
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
|
||
<!-- END: this line ends content from: inc/head.default.html -->
|
||
|
||
<!-- -->
|
||
<!-- This web page was formed via the tool: bin/gen-top-html.sh -->
|
||
<!-- The content of main section of this web page came from: next/guidelines.md -->
|
||
<!-- -->
|
||
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: next/guidelines.md !!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: next/guidelines.md !!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: next/guidelines.md !!! -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
|
||
<!-- Markdown content was converted into HTML via the tool: bin/md2html.sh -->
|
||
|
||
<!-- START: this line starts content from: inc/body.default.html -->
|
||
|
||
<body>
|
||
|
||
<!-- END: this line ends content from: inc/body.default.html -->
|
||
<!-- START: this line starts content from: inc/topbar.default.html -->
|
||
|
||
<div class="theader">
|
||
<nav class="topbar">
|
||
<div class="container">
|
||
<div class="logo">
|
||
<a href="../index.html" class="logo-link">
|
||
IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="topbar-items">
|
||
<div class="item">
|
||
<span class="item-header">
|
||
Entries
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
|
||
<div class="outfit-font">
|
||
<a href="../years.html" class="sub-item-link">
|
||
Winning entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../authors.html" class="sub-item-link">
|
||
Winning authors
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../location.html" class="sub-item-link">
|
||
Location of authors
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../bugs.html" class="sub-item-link">
|
||
Bugs and (mis)features
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html#fix_an_entry" class="sub-item-link">
|
||
Fixing entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html#fix_author" class="sub-item-link">
|
||
Updating author info
|
||
</a>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
Status
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
|
||
<div class="outfit-font">
|
||
<a href="../news.html" class="sub-item-link">
|
||
News
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../status.html" class="sub-item-link">
|
||
Contest status
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../next/rules.html" class="sub-item-link">
|
||
IOCCC rules
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../next/guidelines.html" class="sub-item-link">
|
||
IOCCC guidelines
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../markdown.html" class="sub-item-link">
|
||
Markdown guidelines
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../SECURITY.html" class="sub-item-link">
|
||
Security policy
|
||
</a>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
FAQ
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html" class="sub-item-link">
|
||
Frequently asked questions
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../quick-start.html#enter" class="sub-item-link">
|
||
Enter the IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html#compiling" class="sub-item-link">
|
||
Compiling entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html#running_entries" class="sub-item-link">
|
||
Running entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../faq.html#help" class="sub-item-link">
|
||
How to help
|
||
</a>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
About
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
|
||
<div class="outfit-font">
|
||
<a href="../index.html" class="sub-item-link">
|
||
Home page
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../social.html" class="sub-item-link">
|
||
IOCCC social media
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../about.html" class="sub-item-link">
|
||
About the IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../judges.html" class="sub-item-link">
|
||
The judges
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../thanks-for-help.html" class="sub-item-link">
|
||
Thanks for the help
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../contact.html" class="sub-item-link">
|
||
Contact us
|
||
</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</nav>
|
||
|
||
<div class="header-mobile-menu">
|
||
<noscript>
|
||
<a href="../nojs-menu.html" class="topbar-js-label">
|
||
Please Enable JavaScript
|
||
</a>
|
||
</noscript>
|
||
|
||
<button id="header-open-menu-button" class="topbar-mobile-menu">
|
||
<img
|
||
src="../png/hamburger-icon-open.png"
|
||
alt="hamburger style menu icon - open state"
|
||
width=48
|
||
height=48>
|
||
</button>
|
||
|
||
<button id="header-close-menu-button" class="hide-content">
|
||
<img
|
||
src="../png/hamburger-icon-closed.png"
|
||
alt="hamburger style menu icon - closed state"
|
||
width=48
|
||
height=48>
|
||
</button>
|
||
|
||
<div id="mobile-menu-panel" class="hide-content">
|
||
<div class="mobile-menu-container">
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
Entries
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../years.html">
|
||
Winning entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../authors.html">
|
||
Winning authors
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../location.html">
|
||
Location of authors
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../bugs.html">
|
||
Bugs and (mis)features
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html#fix_an_entry">
|
||
Fixing entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html#fix_author">
|
||
Updating author info
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../thanks-for-help.html">
|
||
Thanks for the help
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
|
||
<div class="mobile-menu-item">
|
||
Status
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../news.html">
|
||
News
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../status.html">
|
||
Contest status
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../next/rules.html">
|
||
IOCCC rules
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../next/guidelines.html">
|
||
IOCCC guidelines
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../markdown.html">
|
||
Markdown guidelines
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../SECURITY.html">
|
||
Security policy
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
FAQ
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html">
|
||
Frequently asked questions
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../quick-start.html#enter">
|
||
Enter the IOCCC
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html#compiling">
|
||
Compiling entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html#running_entries">
|
||
Running entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../faq.html#help">
|
||
How to help
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
About
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../index.html">
|
||
Home page
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../social.html">
|
||
IOCCC social media
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../about.html">
|
||
About the IOCCC
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../judges.html">
|
||
The judges
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../contact.html">
|
||
Contact us
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
</div>
|
||
|
||
<script>
|
||
var headerOpenMenuButton = document.getElementById("header-open-menu-button");
|
||
var headerCloseMenuButton = document.getElementById("header-close-menu-button");
|
||
var mobileMenuPanel = document.getElementById("mobile-menu-panel");
|
||
|
||
headerOpenMenuButton.addEventListener("click", () => {
|
||
headerOpenMenuButton.classList.remove("topbar-mobile-menu");
|
||
headerOpenMenuButton.classList.add("hide-content");
|
||
|
||
headerCloseMenuButton.classList.remove("hide-content");
|
||
headerCloseMenuButton.classList.add("topbar-mobile-menu");
|
||
|
||
mobileMenuPanel.classList.remove("hide-content");
|
||
mobileMenuPanel.classList.add("topbar-mobile-panel");
|
||
});
|
||
|
||
headerCloseMenuButton.addEventListener("click", () => {
|
||
headerCloseMenuButton.classList.remove("topbar-mobile-menu");
|
||
headerCloseMenuButton.classList.add("hide-content");
|
||
|
||
mobileMenuPanel.classList.add("hide-content");
|
||
mobileMenuPanel.classList.remove("topbar-mobile-panel");
|
||
|
||
headerOpenMenuButton.classList.add("topbar-mobile-menu");
|
||
headerOpenMenuButton.classList.remove("hide-content");
|
||
});
|
||
</script>
|
||
|
||
<!-- END: this line ends content from: inc/topbar.default.html -->
|
||
<!-- START: this line starts content from: inc/header.default.html -->
|
||
|
||
<div class="header">
|
||
<a href="../2011/zucker/index.html">
|
||
<img src="../png/ioccc.png"
|
||
alt="IOCCC image by Matt Zucker"
|
||
width=300
|
||
height=110>
|
||
</a>
|
||
<h1>The International Obfuscated C Code Contest</h1>
|
||
<h2>IOCCC Guidelines</h2>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/header.default.html -->
|
||
<!-- START: this line starts content from: inc/navbar.empty.html -->
|
||
|
||
<div class="navbar">
|
||
<a class="Right" href="https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.ioccc.org%2Fnext%2Fguidelines.html">✓</a>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/navbar.empty.html -->
|
||
<!-- START: this line starts content from: inc/before-content.default.html -->
|
||
|
||
<div class="content" id="content">
|
||
|
||
<!-- END: this line ends content from: inc/before-content.default.html -->
|
||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||
|
||
<!-- BEFORE: 1st line of markdown file: next/guidelines.md -->
|
||
<h1 id="th-international-obfuscated-c-code-contest-official-guidelines">29th International Obfuscated C Code Contest Official Guidelines</h1>
|
||
<p class="leftbar">
|
||
Copyright © 2025 Leonid A. Broukhis and Landon Curt Noll.
|
||
</p>
|
||
<p>All Rights Reserved. Permission for personal, education or non-profit
|
||
use is granted provided this copyright and notice are included in its
|
||
entirety and remains unaltered. All other uses must receive prior
|
||
permission in writing by <a href="../contact.html">contacting the Judges</a>.</p>
|
||
<h1 id="guidelines-version">Guidelines Version</h1>
|
||
<p class="leftbar">
|
||
These Guidelines are version <strong>29.07 2025-12-02</strong>.
|
||
</p>
|
||
<p class="leftbar">
|
||
The <span style="font-size:28px;"><b>|</b></span> symbol
|
||
indicates an <strong>change</strong> from the previous IOCCC.
|
||
</p>
|
||
<p class="leftbar">
|
||
Because the <strong>IOCCC29</strong> was a substantial rewrite, only <strong>important
|
||
changes</strong> from <strong>IOCCC28</strong> have been marked.
|
||
</p>
|
||
<p>Be sure to read the <a href="rules.html">Rules</a>.</p>
|
||
<div id="guideline1">
|
||
<div id="guideline1-c">
|
||
<h1 id="guidelines-for-rule-1---c-program">Guidelines for <a href="rules.html#rule1-c">Rule 1 - C program</a></h1>
|
||
</div>
|
||
</div>
|
||
<p class="leftbar">
|
||
While you submission <strong>MUST</strong> be a C program, there is nothing wrong if
|
||
your <code>prog.c</code> file happens to also be a code for another language, say
|
||
an interpreter of JavaScript.
|
||
</p>
|
||
<p class="leftbar">
|
||
We would prefer if you do not use <code>#include</code> statements just to include
|
||
lots of data to circumvent <a href="rules.html#rule2-size">Rule 2 - Size
|
||
restrictions</a> in an excessive way. This is what
|
||
they invented <code>fopen(3)</code> for. :-)
|
||
</p>
|
||
<p class="leftbar">
|
||
We would prefer if you do not require lots and lots of implicit defines
|
||
on the C compiler command line (i.e., lots of <code>-Dfoo</code>, and
|
||
<code>-Dcurds=whey</code> style command line args to the C compiler in the
|
||
Makefile) to get around the <a href="rules.html#rule2-size">Rule 2 - Size
|
||
restrictions</a> in an excessive way.
|
||
</p>
|
||
<p class="leftbar">
|
||
Some use of <code>#include</code> statements (i.e. <code>-include stdio.h</code>) and/or
|
||
implicit <code>#define</code>s (i.e. <code>-Dfoo=bar</code>) on the C compiler command line
|
||
is perfectly reasonable..
|
||
</p>
|
||
<p class="leftbar">
|
||
As a guide, consider the level of <code>#include</code> statements and/or implicit
|
||
defines on the C compiler command line that are found in <a href="https://www.ioccc.org/years.html">winning
|
||
Entries</a>, and try to <strong>NOT</strong> set a
|
||
new record.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you believe you need to significantly abuse <code>#include</code> statements
|
||
and/or implicit defines on the C compiler command line, then try to
|
||
make a case for why in your submission’s <code>remarks.md</code> file: maybe the
|
||
Judges won’t reject your submission.
|
||
</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline2">
|
||
<div id="guideline2-size">
|
||
<h1 id="guidelines-for-rule-2---size-restrictions">Guidelines for <a href="rules.html#rule2-size">Rule 2 - Size restrictions</a></h1>
|
||
</div>
|
||
</div>
|
||
<p class="leftbar">
|
||
You should pay attention to our observations on <a href="../2024/index.html#code-size-and-rule-2">code size and Rule 2
|
||
remarks for IOCCC28</a>.
|
||
</p>
|
||
<p>Your submission must satisfy <strong>BOTH</strong> the
|
||
<a href="rules.html#rule2a-gross-size">Rule 2a - Gross Size</a>
|
||
<strong>AND</strong>
|
||
<a href="rules.html#rule2b-net-size">Rule 2b - Net Size</a> rules.</p>
|
||
<p>To check your code against
|
||
<a href="rules.html#rule2-size">Rule 2 - Size restrictions</a>, use the
|
||
<code>iocccentry(1)</code> tool. For example:</p>
|
||
<pre><code> iocccsize prog.c</code></pre>
|
||
<p>The <code>iocccsize(1)</code> algorithm can be summarized as follows:</p>
|
||
<blockquote>
|
||
<p>The size tool counts most C reserved words (keyword, secondary, and
|
||
selected preprocessor keywords) as 1. The size tool counts all other
|
||
bytes as 1 excluding ASCII whitespace, and excluding any ‘<code>;</code>’, ‘<code>{</code>’
|
||
or ‘<code>}</code>’ followed by ASCII whitespace, and excluding any ‘<code>;</code>’, ‘<code>{</code>’
|
||
or ‘<code>}</code>’ byte immediately before the end of file.</p>
|
||
<p>ASCII whitespace includes ASCII tab, ASCII space, ASCII newline,
|
||
ASCII formfeed, and ASCII carriage return.</p>
|
||
<p>When ‘<code>;</code>’, ‘<code>{</code>’ or ‘<code>}</code>’ are within a C string, they may still not
|
||
be counted by the IOCCC size tool.</p>
|
||
</blockquote>
|
||
<p>In cases where the above summary and the algorithm implemented by
|
||
<code>iocccsize(1)</code> conflict, the algorithm implemented by the minimum
|
||
required version of <code>iocccsize(1)</code> is preferred by the
|
||
<a href="../judges.html">Judges</a>.</p>
|
||
<p>Make sure <code>iocccsize</code> does not flag any issues with your <code>prog.c</code>.</p>
|
||
<p><strong>NOTE</strong>: by default <code>iocccsize</code> will only report the size, unless the
|
||
code surpasses the limit.</p>
|
||
<p>There a much less need to <code>#define</code> C reserved words in an effort to
|
||
get around the size limits of <a href="rules.html#rule2-size">Rule 2 - Size
|
||
restrictions</a> because of the <code>iocccsize(1)</code>
|
||
algorithm.</p>
|
||
<p>Yes Virginia, <strong>the previous guideline sentence is an important hint</strong>!</p>
|
||
<p>Don’t expect the <a href="rules.html#rule2-size">Rule 2 - Size restrictions</a> to
|
||
<a href="../faq.html#size_slow_change">change any time soon</a>.</p>
|
||
<p>See the FAQ on “<a href="../faq.html#size_rule_history">How has the Rule 2 size restrictions rule changed over
|
||
the years?</a>”.</p>
|
||
<p>You would be <strong>WELL ADVISED</strong> to observe our <a href="../2024/index.html#rule2">notes on
|
||
size</a> in the
|
||
<a href="2024/index.html">2024/index.html</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline3">
|
||
<div id="guideline3-register">
|
||
<h1 id="guidelines-for-rule-3---register-for-the-ioccc">Guidelines for <a href="rules.html#rule3-register">Rule 3 - Register for the IOCCC</a></h1>
|
||
</div>
|
||
</div>
|
||
<p class="leftbar">
|
||
If a group of people work on a submission, then they should <a href="../quick-start.html#enter">register
|
||
for the IOCCC</a> using either a valid group
|
||
email address, or an email address for one of the authors.
|
||
</p>
|
||
<p class="leftbar">
|
||
Processing your registration is an activity overseen by a Judge.
|
||
Please be <strong>patient</strong> while a Judge processes your registration.
|
||
</p>
|
||
<p>It can take a few days to process your registration and for the server
|
||
to email your details, therefore make sure to allow yourself ample time
|
||
to register and submit your entries; <strong>DO NOT WAIT UNTIL THE FINAL
|
||
DAYS</strong> to register! The Judges are <strong>NOT</strong> responsible for delayed or
|
||
lost email or for those who wait until the last minute to try to
|
||
register!</p>
|
||
<p class="leftbar">
|
||
If after a few days you believe your registration hasn’t been process,
|
||
then <a href="../contact.html">contact the Judges</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
After your UUID and temporary password are emailed to you, you have up
|
||
to fortnight (<strong>14 days</strong>) to login and change your temporary password.
|
||
If you fail to change your temporary password by that deadline, then
|
||
you’ll need to <a href="../contact.html">contact the Judges</a> by email to
|
||
request a reset.
|
||
</p>
|
||
<p>See the
|
||
FAQ on “<a href="register.html">How to register for the IOCCC</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../quick-start.html#enter">Entering the IOCCC: the bare minimum you need to
|
||
know</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline7">
|
||
<div id="guideline7-original">
|
||
<h1 id="guidelines-for-rule-7---original-work">Guidelines for <a href="rules.html#rule7-original-work">Rule 7 - Original Work</a></h1>
|
||
</div>
|
||
</div>
|
||
<p>While it is <strong>NOT</strong> required, you are allowed to use tools or services
|
||
such as:</p>
|
||
<ul>
|
||
<li>Code generators</li>
|
||
<li>Static and runtime code analysis tools</li>
|
||
<li>Machine learning tools</li>
|
||
<li>Natural language models</li>
|
||
<li>Large language models (LLMs)</li>
|
||
<li>Code copilot tools</li>
|
||
<li>So called “<em>AI services</em>”</li>
|
||
<li>Etc.</li>
|
||
</ul>
|
||
<p>The IOCCC has a rich history of remarkable winning entries created by
|
||
authors who skillfully employed various techniques to develop their
|
||
code. If you do make use of such tools or services, then we
|
||
<strong>ENCOURAGE you to describe how you used such tools</strong> in your
|
||
<code>remarks.md</code> file.</p>
|
||
<p class="leftbar">
|
||
In short: you created it, you own it, its an original work <strong>OR</strong> you have
|
||
explicit permission to the work that you document in your remarks.
|
||
</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#ai">May I use AI, LLM, Virtual coding assistants, or similar tools
|
||
to write my submission?</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline8">
|
||
<div id="guideline8-submitting">
|
||
<h1 id="guidelines-for-rule-8---submitting-requirements">Guidelines for <a href="rules.html#rule8-submitting-requirements">Rule 8 - Submitting requirements</a></h1>
|
||
</div>
|
||
</div>
|
||
<p>Do <strong>NOT</strong> register more than one account just to try and get around
|
||
the limit on the number of submission slots.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline9">
|
||
<div id="guideline9-no-interactive-compiling-allowed">
|
||
<div id="guideline9-no-interactive">
|
||
<h1 id="guidelines-for-rule-9---no-interactive-compiling-allowed">Guidelines for <a href="rules.html#rule9-no-interactive">Rule 9 - No interactive compiling allowed</a></h1>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<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>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline11">
|
||
<div id="guideline11-abuse">
|
||
<h1 id="guidelines-for-rule-11---legal-rule-abuse">Guidelines for <a href="rules.html#rule11-legal-rule-abuse">Rule 11 - Legal rule abuse</a></h1>
|
||
</div>
|
||
</div>
|
||
<p>We do realize that there are holes in the <a href="rules.html">Rules</a>, and
|
||
invite submitters to attempt to apply creative rule interpretation. A
|
||
rule abuse though, even if not rewarded, may result in a subsequent
|
||
rule change for future contests.</p>
|
||
<p>We sometime award ‘<strong>Best abuse of the rules</strong>’ or ‘<strong>Worst abuse of
|
||
the rules</strong>’, or some variation, to a submission that creatively
|
||
attempts to exploit a holes in the <a href="rules.html">Rules</a>.</p>
|
||
<p>When we do need to plug a hole in the <a href="rules.html">Rules</a> or
|
||
<a href="guidelines.html">Guidelines</a>, we will attempt to use a very small
|
||
plug, if not smaller.</p>
|
||
<p>Or, maybe not. :-)</p>
|
||
<p>Legal rule abuse may involve, but is not limited to, doing things that
|
||
are technically allowed by the <a href="rules.html">Rules</a> and yet do not fit
|
||
the spirit of what we intended to be submitted.</p>
|
||
<p>Legal abuse of the <a href="rules.html">Rules</a> is <strong>NOT</strong> an invitation to
|
||
violate the <a href="rules.html">Rules</a> (especially <a href="./rules.html#rule17-mkiocccentry">Rule 17 - Use
|
||
mkiocccentry</a>). A submission that
|
||
violates the <a href="rules.html">rules</a> in the opinion of the
|
||
<a href="../judges.html">Judges</a>, <strong>WILL</strong> be disqualified. <strong><em>RULE ABUSE
|
||
CARRIES A CERTAIN LEVEL OF RISK!</em></strong></p>
|
||
<p>If you intend to abuse the <a href="rules.html">Rules</a>, indicate so in your
|
||
<code>remarks.md</code> file. You <strong>MUST</strong> try to justify, plead, beg, why you
|
||
consider your rule abuse to be allowed under the <a href="rules.html">Rules</a>.
|
||
Humor or creativity help plead a case.</p>
|
||
<p>As there is no guarantee that you will succeed, you might consider
|
||
submitting an alternate version that conforms to the
|
||
<a href="rules.html">Rules</a>, if it might otherwise be interesting; one that
|
||
does not abuse the <a href="rules.html">Rules</a> and one that does, making sure
|
||
to note in the one that does not abuse the rules that this is another
|
||
version, so that the Judges do not assume you uploaded it by mistake.</p>
|
||
<p>If you do bypass the <code>mkiocccentry(1)</code> warnings about
|
||
<a href="rules.html#rule2a-gross-size">Rule 2a - Gross Size</a>
|
||
and/or about
|
||
<a href="rules.html#rule2b-net-size">Rule 2b - Net Size</a>
|
||
<strong>or any other
|
||
rule</strong> and submit it anyway, you <strong>MUST</strong> try to justify why the
|
||
<a href="../judges.html">Judges</a> should not reject your submission due to a rule
|
||
violation, and <strong>you would be wise</strong> to do this towards the top of your
|
||
<code>remarks.md</code> file so as not to be overlooked.</p>
|
||
<p>We are often asked why the contest <a href="rules.html">Rules</a> and
|
||
<a href="guidelines.html">Guidelines</a> seem strange or contain mistakes, flaws,
|
||
or grammatical errors. One reason is that we sometimes make genuine
|
||
mistakes, but in many cases such problems, flaws or areas of confusion
|
||
are deliberate.</p>
|
||
<p>Changes to <a href="rules.html">Rules</a> and <a href="guidelines.html">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 and
|
||
“drive a truck through the holes” in the <a href="rules.html">Rules</a> and
|
||
<a href="guidelines.html">Guidelines</a>.</p>
|
||
<p>At the risk of stating the obvious, this contest is a parody of the
|
||
software development process. The <a href="rules.html">Rules</a> and
|
||
<a href="guidelines.html">Guidelines</a> are only part of the overall contest.
|
||
Even so, one might think the contest <a href="rules.html">Rules</a> and
|
||
<a href="guidelines.html">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, ballooning 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">Rules</a> and <a href="guidelines.html">Guidelines</a> are written in
|
||
obfuscated form.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline12">
|
||
<div id="guideline12-utf8">
|
||
<h1 id="guidelines-for-rule-12---utf-8">Guidelines for <a href="rules.html#rule12-utf8">Rule 12 - UTF-8</a></h1>
|
||
</div>
|
||
</div>
|
||
<p>The IOCCC no longer discourages the use of multibyte UTF-8 characters
|
||
in <code>C</code> code.</p>
|
||
<div id="guideline13">
|
||
<div id="guideline13-nocr">
|
||
<h1 id="guidelines-for-rule-13---no-carriage-returns-in-prog.c">Guidelines for <a href="rules.html#rule13-nocr">Rule 13 - No carriage returns in prog.c</a></h1>
|
||
</div>
|
||
</div>
|
||
<p>We <strong>DISLIKE</strong> C code with trailing control-M’s (<code>\r</code> or <code>\015</code>) that
|
||
results in compilation failures.</p>
|
||
<p>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 class="leftbar">
|
||
If your <code>prog.c</code> is near the <a href="rules.html#rule2a-gross-size">Rule 2a Gross
|
||
Size</a> and/or <a href="rules.html#rule2b-net-size">Rule 2b Net
|
||
Size</a> limit, you are permitted to <strong>NOT</strong>
|
||
end source with a newline. If you need to do this, please document
|
||
that in your <code>remarks.md</code> file.
|
||
</p>
|
||
<p class="leftbar">
|
||
If your compiler complains about about not ending in a newline, please
|
||
note this in your <code>remarks.md</code> file, and if possible add an appropriate
|
||
<code>-Wno-</code> to the <code>CSILENCE</code> variable in your Makefile.
|
||
</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline15">
|
||
<div id="guideline15-gnu-makefile">
|
||
<h1 id="guidelines-for-rule-15---gnu-makefile">Guidelines for <a href="rules.html#rule15-gnu-makefile">Rule 15 - GNU Makefile</a></h1>
|
||
</div>
|
||
</div>
|
||
<p>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 GNU <code>make(1)</code> tool, your <code>Makefile</code>, as well as tools
|
||
found in the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>
|
||
(UNIX-like) environments, and commonly found on systems that reasonably
|
||
conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>
|
||
in the building and compiling of your submission.
|
||
</p>
|
||
<p class="leftbar">
|
||
Your <code>Makefile</code> <strong>MUST</strong> be compatible with GNU <code>make</code> and we suggest
|
||
you use <a href="Makefile.example">Makefile.example</a> as a template, renamed as
|
||
<code>Makefile</code> of course.
|
||
</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#makefile_details">What are the detailed recommendations for a submission
|
||
Makefile?</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="guideline17">
|
||
<div id="guideline17-mkiocccentry">
|
||
<h1 id="guidelines-for-rule-17---use-mkiocccentry">Guidelines for <a href="rules.html#rule17-mkiocccentry">Rule 17 - Use mkiocccentry</a></h1>
|
||
</div>
|
||
</div>
|
||
<p class="leftbar">
|
||
We <strong>STRONGLY</strong> recommend you <strong>do</strong> install the most recent release of
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
|
||
because use of older versions of the mkiocccentry toolkit are <strong>HIGHLY
|
||
LIKELY</strong> to be <strong>REJECTED</strong>!
|
||
</p>
|
||
<p class="leftbar">
|
||
If you submit your own JSON files (<strong>OTHER THAN</strong> <code>.auth.json</code> and
|
||
<code>.info.json</code>!) then they do <strong>NOT</strong> have to be valid JSON.
|
||
</p>
|
||
<p class="leftbar">
|
||
However, if you do provide invalid JSON files, <strong>PLEASE</strong> document and
|
||
<strong>clearly explain</strong> this in your <code>remarks.md</code> file.
|
||
</p>
|
||
<p class="leftbar">
|
||
An <em>extra file</em> is defined as a file that is not <code>prog.c</code>,
|
||
<code>prog.alt.c</code>, <code>try.sh</code>, <code>try.alt.sh</code>, <code>remarks.md</code>, <code>Makefile</code>,
|
||
<code>.auth.json</code> and <code>.info.json</code>: unless it’s not in the top level
|
||
directory, in which case it <strong>IS</strong> an <em>extra file</em>.
|
||
</p>
|
||
<p class="leftbar">
|
||
The <strong>non</strong>-extra files are considered <em>free files</em>, and do not count
|
||
towards the <a href="rules.html#rule17-mkiocccentry">Rule 17 - Use
|
||
mkiocccentry</a> limit of <strong>31</strong> <em>extra
|
||
files</em>.
|
||
</p>
|
||
<p 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.
|
||
</p>
|
||
<p class="leftbar">
|
||
The <code>mkiocccentry</code> generated tarball does <strong>NOT</strong> reveal who you are!
|
||
For this reason, the tarball <strong>MUST</strong> be a <strong>v7 format</strong> tarball.
|
||
</p>
|
||
<p class="leftbar">
|
||
You should NOT use a tarball as an <em>extra file</em> for a test-suite unless
|
||
you have a very good reason for this: if you do include a tarball as an
|
||
<em>extra file</em>, then you <strong>MUST</strong> specify why in your <code>remarks.md</code> file.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you <strong>DO</strong> include a tarball as an <em>extra file</em>, and the build
|
||
process or the program extracts said tarball(s), the make <code>clobber</code>
|
||
rule <strong>MUST</strong> remove the extracted files.
|
||
</p>
|
||
<p class="leftbar">
|
||
Instead of including a large test-suite that requires a lot of files as
|
||
part of your submission, if your submission doesn’t require the
|
||
test-suite to be available to run, then in your <code>remarks.md</code> you could
|
||
include URL where such a test-suite may be downloaded from and how to
|
||
use the test-suite to test your submission, assuming it does not reveal
|
||
who you are, i.e. <strong>DO NOT</strong> use a GitHub URL which contains your
|
||
username, in case the judges know who you are. See <a href="rules.html#rule16-anonymous-judging">Rule 16 - Anonymous
|
||
judging</a>.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you <strong>DO</strong> include a tarball then make sure it uses the v7 format.
|
||
This is because it will not reveal who you are.
|
||
</p>
|
||
<p class="leftbar">
|
||
See the FAQ on “<a href="../faq.html#extra-files">extra files</a>” for details on
|
||
how to make a v7 tarball.
|
||
</p>
|
||
<p class="leftbar">
|
||
We recommend that all markdown files in your submission observe our
|
||
<a href="../markdown.html">IOCCC markdown guidelines</a>.
|
||
</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#try_scripts">What should I do with the <code>try.sh</code> and <code>try.alt.sh</code>
|
||
scripts?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#auth_json">What is a <code>.auth.json</code> file?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#info_json">What is a <code>.info.json</code> file?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#chksubmit">How can I validate my submission
|
||
directory?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#file_perms">What permissions may my files be and what if I need different
|
||
permissions?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#makefile_details">What are the detailed recommendations for a submission
|
||
Makefile?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#rule17">What are the details behind Rule 17 - Use
|
||
mkiocccentry?</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="general">
|
||
<h1 id="general-guidelines">General Guidelines</h1>
|
||
</div>
|
||
<div id="general-overall-guidelines">
|
||
<h2 id="overall-guidelines">Overall Guidelines</h2>
|
||
</div>
|
||
<p>These <a href="guidelines.html">Guidelines</a> are <strong>hints</strong> and <strong>suggestions</strong>,
|
||
<strong>NOT</strong> <a href="rules.html">Rules</a>.</p>
|
||
<p>While submissions that violate the <a href="guidelines.html">Guidelines</a> are
|
||
allowed, submissions that remain within the
|
||
<a href="guidelines.html">Guidelines</a> are preferred.</p>
|
||
<p>You are encouraged to review the following <a href="../faq.html">FAQs</a>:</p>
|
||
<ul>
|
||
<li><p><a href="../quick-start.html#enter">How to enter the IOCCC</a></p></li>
|
||
<li><p><a href="../faq.html#mkiocccentry">Obtaining and compiling the most recent mkiocccentry
|
||
toolkit</a></p></li>
|
||
<li><p><a href="./submit.html">How to upload your submission</a></p></li>
|
||
</ul>
|
||
<p>While the contest is <strong><a href="../faq.html#open">open</a></strong>, you may modify your
|
||
previously uploaded submission by rebuilding your submission with the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>, and
|
||
then re-uploading it to <strong>the same slot number</strong> on the <a href="https://submit.ioccc.org">submit
|
||
server</a>.</p>
|
||
<p class="leftbar">
|
||
The <strong>official locale</strong> of the <strong>IOCCC</strong> is <strong>C</strong>.
|
||
</p>
|
||
<p>You are <strong>encouraged</strong> to examine the <a href="../years.html">winners of previous
|
||
contests</a>.</p>
|
||
<p>Because the <a href="rules.html">Rules</a> change from year to year, some <a href="../years.html">past
|
||
winning entries</a> may be rejected this year. What was
|
||
<em>was</em> unique and novel one year <em>might be ‘old’ the next year</em>.</p>
|
||
<p>A submission is usually examined in a number of ways. We typically
|
||
apply a number of tests to a submission:</p>
|
||
<ul>
|
||
<li>look at the original source</li>
|
||
<li>C pre-process the source ignoring <code>#include</code> lines</li>
|
||
<li>C pre-process the source ignoring <code>#define</code> <em>and</em> <code>#include</code> lines</li>
|
||
<li>run it through a C beautifier (such as <code>clang-format(1)</code>)</li>
|
||
<li>examine the algorithm</li>
|
||
<li>compile it (with flags to enable all warnings)</li>
|
||
<li>execute it</li>
|
||
</ul>
|
||
<p>You should consider how your submission looks in each of the above
|
||
tests. You should ask yourself if your submission remains obscure
|
||
after it has been ‘<em>cleaned up</em>’ by the C pre-processor and a C
|
||
beautifier.</p>
|
||
<p>Your submission need not pass all of the above tests as in certain
|
||
cases, a test is not important.</p>
|
||
<p>Submissions that compete for the ‘<strong>strangest/most creative source
|
||
layout</strong>’ need not do as well as others in terms of their algorithm.</p>
|
||
<p>Given two submissions, we are more inclined to pick the submission that
|
||
does something interesting when it’s executed.</p>
|
||
<p><strong>IMPORTANT:</strong> Be sure that <strong>your submission works</strong> as documented in
|
||
your <code>remarks.md</code> file.</p>
|
||
<p>We sometimes make an effort to debug a submission that has a slight
|
||
problem, particularly in or near the final round. On the other hand,
|
||
we have seen some otherwise excellent submissions fall down because
|
||
they didn’t work as documented.</p>
|
||
<p>If you submission has bugs and/or mis-features, you are <strong>MUCH BETTER</strong>
|
||
off documenting such bugs and/or mis-features in your <code>remarks.md</code>
|
||
file.</p>
|
||
<p>Consider an example of a <a href="https://en.wikipedia.org/wiki/Prime_number">prime
|
||
number</a> printing program
|
||
that claims that 16 is a prime number. Noting such a bug in your
|
||
<code>remarks.md</code> file could save your submission:</p>
|
||
<blockquote>
|
||
<p>“<em>this submission sometimes prints the 4th power of a prime by mistake</em>”</p>
|
||
</blockquote>
|
||
<p>Sometimes a strange bug or (mis-)feature can even help the submission!
|
||
Of course, a correctly working submission might be better.</p>
|
||
<p>We tend to look down on a <a href="https://en.wikipedia.org/wiki/Prime_number">prime
|
||
number</a> printer that claims
|
||
that 16 is a prime number. Clever people will note that 16 might be
|
||
prime under certain conditions. ;-) Wise people, when submitting
|
||
something clever will <strong>fully explain such cleverness</strong> in their
|
||
submission’s <code>remarks.md</code> file.</p>
|
||
<p>People who are considering to just use some complex mathematical
|
||
function or state machine to spell out something such as “<em>hello,
|
||
world!</em>” <strong>really really, <em>and we do mean REALLY</em>, do need to be more
|
||
creative</strong>.</p>
|
||
<p>Consider using misleading or subtle tricks layered on top of or under
|
||
an appropriate level of obfuscation.</p>
|
||
<p>A clean looking program with misleading comments and variable names
|
||
might be a <strong>VERY GOOD START</strong> to a great submission!</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="likes">
|
||
<div id="dislikes">
|
||
<h2 id="our-likes-and-dislikes">Our Likes and Dislikes</h2>
|
||
</div>
|
||
</div>
|
||
<p>We <strong>VERY MUCH LIKE</strong> submissions that use an edited variant of the
|
||
example <code>Makefile</code>, as described and linked to in the
|
||
FAQ on “<a href="../faq.html#makefile_details">What are the detailed recommendations for a submission
|
||
Makefile?</a>,
|
||
renamed as <code>Makefile</code> of course.</p>
|
||
<p>This makes it easier for the <a href="../judges.html">Judges</a> to test your
|
||
submission. And if your submissions wins, it makes it easier to
|
||
integrate it into the <a href="https://www.ioccc.org/index.html">Official IOCCC winner
|
||
website</a>.</p>
|
||
<p>We <strong>VERY MUCH LIKE</strong> submissions that have some educational value.
|
||
This does <strong>NOT</strong> mean that your submission should not be obfuscated
|
||
but rather that the IOCCC has moved away from the idea of “spoilers”.
|
||
You should not encrypt or rot13 content in your <code>remarks.md</code> file.</p>
|
||
<p>The above statement does not mean encryption/decryption tools will not
|
||
win, nor does it mean that if you have such a submission that you could
|
||
not encrypt some remarks (such as obfuscation details), but if you do
|
||
so please put them in a separate file and indicate how to decipher it.
|
||
Please do <strong>NOT</strong> use any cipher to encrypt your <code>remarks.md</code>.</p>
|
||
<p>It is <strong>VERY MUCH</strong> appreciated if your remarks or <code>prog.c</code> have some
|
||
educational value. And although educational value is not required, it
|
||
is an <strong>EXCELLENT</strong> bonus.</p>
|
||
<p>We <strong>LIKE</strong> submissions that use an edited version of the <code>try.sh</code>
|
||
example script (and if you have alternate code, the same applies with
|
||
the <code>try.alt.sh</code> script):</p>
|
||
<ul>
|
||
<li><p><a href="https://github.com/ioccc-src/winner/blob/master/next/try.sh">view example try.sh</a></p></li>
|
||
<li><p><a href="try.sh">download example try.sh</a></p></li>
|
||
<li><p><a href="https://github.com/ioccc-src/winner/blob/master/next/try.alt.sh">view example try.alt.sh</a></p></li>
|
||
<li><p><a href="try.alt.sh">download example try.alt.sh</a></p></li>
|
||
</ul>
|
||
<p>Of course, it is quite possible that only one invocation is possible,
|
||
so it is not necessarily detrimental to your submission if you do not
|
||
include one, though we do like interesting and creative uses of
|
||
submissions. See also the FAQ on “<a href="../faq.html#try_scripts">submitting try.sh and try.alt.sh
|
||
scripts</a>”.</p>
|
||
<p class="leftbar">
|
||
Even if it only has one invocation we still <strong>LIKE</strong> the try scripts
|
||
because we use them during judging and in publishing the winning
|
||
entries.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you do include a <code>try.sh</code> then <strong>PLEASE</strong> remove the <code>try</code> rule in
|
||
the Makefile.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you do include a <code>try.alt.sh</code> then <strong>PLEASE</strong> remove the <code>try.alt</code>
|
||
rule in the Makefile.
|
||
</p>
|
||
<p class="leftbar">
|
||
If you don’t have a prog.alt.c, then <strong>PLEASE</strong> remove the <code>try.alt</code>
|
||
rule as well.
|
||
</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="about-cpp">
|
||
<h3 id="about-c-preprocessor">About C preprocessor</h3>
|
||
</div>
|
||
<p>Doing masses of <code>#define</code>s to obscure the source has become ‘old’. We
|
||
tend to ‘see thru’ masses of <code>#define</code>s due to our pre-processor tests
|
||
that we apply. Simply abusing <code>#define</code>s or <code>-Dfoo=bar</code> won’t go as
|
||
far as a program that is more well rounded in confusion.</p>
|
||
<p><strong>Many</strong> C compilers <strong>DISLIKE</strong> the following code, and so do we:</p>
|
||
<pre><code> #define d define
|
||
#d foo /* <-- don't expect this to turn into #define foo */</code></pre>
|
||
<p>In other words, it is a compilation error, and in order to get older
|
||
IOCCC winning entries that did this to compile, we had to update them
|
||
to not do this.</p>
|
||
<p>When declaring local or global variables, you should declare the type:</p>
|
||
<pre><code> int this_is_fine;</code></pre>
|
||
<p>and <strong>NOT</strong> like this:</p>
|
||
<pre><code> this_is_not; /* <-- Try to avoid implicit type declarations */</code></pre>
|
||
<p>We really <strong>DISLIKE</strong> submissions that make blatant use of <code>#include</code>
|
||
of large data files to get around the source code size limit. This does
|
||
not mean <code>#include</code> of standard header files, just data files you
|
||
provide.</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>
|
||
<h3 id="about-compilers">About compilers</h3>
|
||
<p>We tend to <strong>like <em>less</em></strong> a submission that requires either <code>gcc</code>
|
||
<strong>OR</strong> <code>clang</code>. <strong>We <em>prefer</em> submissions</strong> that can compile under
|
||
<strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>. <strong>Hint!</strong></p>
|
||
<p>We <strong>RECOMMEND</strong> that the compiler flags you use in your submission’s
|
||
<code>Makefile</code> are supported by <strong>BOTH</strong> <code>gcc</code> <strong>AND</strong> <code>clang</code>.</p>
|
||
<p>We <strong>DISLIKE</strong> the use of obscure compiler flags, especially if <code>gcc</code>
|
||
and/or <code>clang</code> do not support it. We <strong>suggest</strong> that you not use any
|
||
really obscure compiler flags if you can help it.</p>
|
||
<div id="about-nested-functions">
|
||
<div id="nested-functions">
|
||
<h3 id="about-nested-functions">About nested functions</h3>
|
||
</div>
|
||
</div>
|
||
<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">Judges</a> rescinded the
|
||
encouragement of nested functions. Such constructions, while
|
||
interesting and sometimes amusing, will have to wait until they are
|
||
required by a C standard that are actually implemented in <strong>BOTH</strong>
|
||
<code>gcc</code> <strong>AND</strong> <code>clang</code>.</p>
|
||
<p>We <strong>DISLIKE</strong> submissions that require the use of
|
||
<code>-fnested-functions</code>.</p>
|
||
<h3 id="about-variadic-functions">About variadic functions</h3>
|
||
<p>If your submission uses functions that have a variable number of
|
||
arguments, <strong>be careful</strong>. Systems implement <code>va_list</code> in a wide
|
||
variety of ways. Because of this, a number of operations using
|
||
<code>va_list</code> <strong>are not portable and <em>must not</em> be used</strong>:</p>
|
||
<ul>
|
||
<li>assigning a non-<code>va_list</code> variable to/from a <code>va_list</code> variable</li>
|
||
<li>casting a non-<code>va_list</code> variable into/from a <code>va_list</code> variable</li>
|
||
<li>passing a <code>va_list</code> variable to a function expecting a non-<code>va_list</code> arg</li>
|
||
<li>passing a non-<code>va_list</code> variable to a function expecting a <code>va_list</code> arg</li>
|
||
<li>performing arithmetic on <code>va_list</code> variables</li>
|
||
<li>using <code>va_list</code> as a structure or union</li>
|
||
</ul>
|
||
<p>In particular, do not treat <code>va_list</code> variables as if they were a <code>char **</code>.</p>
|
||
<p>We <strong>DISLIKE</strong> the use of <code>varargs.h</code>. Use <code>stdarg.h</code> instead.</p>
|
||
<div id="about-io">
|
||
<h3 id="about-io-functions">About I/O functions</h3>
|
||
</div>
|
||
<p>We <strong>DISLIKE</strong> the use of <code>gets(3)</code>. Use <code>fgets(3)</code> instead.</p>
|
||
<h3 id="about-tarballs">About tarballs</h3>
|
||
<p>We tend to <strong>DISLIKE</strong> the blatant use of tarballs in an attempt to
|
||
simply get around the extra file number limit. We realize there may be
|
||
cases where a tarball containing a number of extra files may be needed.
|
||
Such a need for a tarball <strong>MUST</strong> be explained in the <code>remarks.md</code>
|
||
file.</p>
|
||
<div id="gotos">
|
||
<div id="goto">
|
||
<p class="leftbar">
|
||
Using a mass of <code>goto</code>s to obfuscate your code has become ‘old’ and is
|
||
unlikely to make it through the final rounds, if it even gets that far.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
<div id="about-stdib">
|
||
<div id="about-exit">
|
||
<h3 id="about-exit3">About <code>exit(3)</code></h3>
|
||
</div>
|
||
</div>
|
||
<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>
|
||
<div id="small">
|
||
<h3 id="what-it-means-to-be-small">What it means to be small</h3>
|
||
</div>
|
||
<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>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>
|
||
<div id="one-liner">
|
||
<h3 id="what-a-one-liner-means">What a one-liner means</h3>
|
||
</div>
|
||
<p>One line programs should be short one line programs: say around <strong>80</strong>
|
||
to <strong>132</strong> bytes long. Going well beyond <strong>132</strong> bytes is a bit too
|
||
long to be called a one-liner in our vague opinion.
|
||
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>
|
||
<div id="blobs">
|
||
<h3 id="about-blobs-of-code">About blobs of code</h3>
|
||
</div>
|
||
<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>Unless you are cramped for space, or unless you are entering the
|
||
‘<strong>Best one liner</strong>’ category, we suggest that you format your program
|
||
in a more creative way than simply forming excessively long lines.</p>
|
||
<p>The <code>Makefile</code> should not be used to try and get around the size limit.
|
||
It is one thing to make use of a several <code>-D</code>s on the compile line to
|
||
help out, but it is quite another to use many bytes of <code>-D</code>s in order
|
||
to try and squeeze the source under the size limit.</p>
|
||
<p>Please do not use things like <code>gzip(1)</code> to get around the size limit.
|
||
This was done years ago; please try to be much more creative.</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>
|
||
<h3 id="about-environment">About environment</h3>
|
||
<p>We tend to <strong>DISLIKE</strong> programs that:</p>
|
||
<ul>
|
||
<li>are very hardware specific</li>
|
||
<li>are very OS version specific (<code>index(3)</code>/<code>strchr(3)</code> differences are
|
||
OK, but sockets/streams specific code is likely not to be)</li>
|
||
<li>dump core or have compiler warnings (it is OK only if
|
||
you warn us in your <code>remarks.md</code> file)</li>
|
||
<li>won’t compile or run in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>
|
||
(UNIX-like) environment</li>
|
||
<li>depend on a utility or application not normally found
|
||
in systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a></li>
|
||
<li>abuse the build file to get around the size limit</li>
|
||
<li>obfuscate by use of ANSI trigraphs</li>
|
||
<li>obfuscate by use of digraphs</li>
|
||
<li>are larger than they need to be</li>
|
||
<li>have more lines than they need to have</li>
|
||
<li>are “blob-ier” (just a pile of unformatted C code) than they need to be</li>
|
||
<li>are rather similar to <strong><a href="../years.html">previous winners</a></strong> :-(</li>
|
||
<li>are <strong>identical</strong> to <strong><a href="https://en.wikipedia.org/wiki/Null_device">previous losers</a></strong> :-)</li>
|
||
<li>that mandate the exclusive use of a specific Integrated Development Environment (IDE)</li>
|
||
</ul>
|
||
<p>In order to encourage submission portability, we <strong>DISLIKE</strong>
|
||
submissions that fail to build unless one is using an IDE. For example,
|
||
do not mandate that one must use Microsoft Visual Studio to compile
|
||
your submission.</p>
|
||
<p>The program must compile and link cleanly in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>
|
||
(UNIX-like) 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 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>
|
||
(UNIX-like) environments and systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>.
|
||
</p>
|
||
<p>You may compile and use your own programs. If you do, try to build and
|
||
execute from the current directory. This restriction is not a hard and
|
||
absolute one. The intent is to ensure that the building of your
|
||
program is reasonably portable.</p>
|
||
<p>We prefer programs that are portable across a wide variety of UNIX-like
|
||
operating systems (e.g., Linux, GNU Hurd, BSD, UNIX, macOS, etc.).</p>
|
||
<p>Try to avoid submissions that play music that some people believe is
|
||
copyrighted music.</p>
|
||
<p>Did we remember to indicate that programs that blatantly use some
|
||
complex state machine to do something simple, are boring? We think we
|
||
did. :-)</p>
|
||
<p>Given two versions of the same program, one that is a compact blob of
|
||
code, and the other that is formatted more like a typical C program, we
|
||
tend to favor the second version. Of course, a third version of the
|
||
same program that is formatted in an interesting and/or obfuscated way,
|
||
would definitely win over the first two!</p>
|
||
<p>Remember, you can submit more than one submission. See the
|
||
<a href="rules.html">Rules</a> for details (in particular, <a href="rules.html#rule8-submitting-requirements">Rule 8 - Submitting
|
||
requirements</a>).</p>
|
||
<p>Please note that the C source below, besides lacking in obfuscation, is
|
||
<strong>NOT</strong> the smallest C source file that when compiled and run, dumps
|
||
core:</p>
|
||
<pre><code> main;</code></pre>
|
||
<p>Unless you specify <code>-fwritable-strings</code> (see <code>COTHER</code> in the example
|
||
Makefile, described in the
|
||
FAQ on “<a href="../faq.html#makefile_details">What are the detailed recommendations for a submission
|
||
Makefile</a>”), do not
|
||
assume this sort of code will work:</p>
|
||
<pre><code> char *T = "So many primes, so little time!";
|
||
...
|
||
T[14] = ';'; /* modifying a string requires: -fwritable-strings */</code></pre>
|
||
<p>Even so, one should probably not assume that this is universally
|
||
accepted.</p>
|
||
<p>Initialized char arrays are OK to write over. For instance, this is
|
||
OK:</p>
|
||
<pre><code> char b[] = "Is this OK";
|
||
b[9] = 'k'; /* modifying an initialized char array is OK */</code></pre>
|
||
<p>We prefer code that can run on either a 64-bit or 32-bit processor.
|
||
However, it is <strong>UNWISE </strong>to assume it will run on an some Intel-like
|
||
x86 architecture**.</p>
|
||
<p>While programs that only run in a specific word size are OK, if you
|
||
have to pick, choose a 64-bit word size.</p>
|
||
<p>If your submission <strong>MUST</strong> run only on a 64-bit or 32-bit
|
||
architecture, then you <strong>MUST</strong> specify the <code>-arch</code> on your command
|
||
line (see <code>ARCH</code> in the example Makefile, described in the FAQ on
|
||
“<a href="../faq.html#makefile_details">What are the detailed recommendations for a submission
|
||
Makefile?</a>.</p>
|
||
<p>Do not assume a processor word size without specifying <code>-arch</code>. For
|
||
example:</p>
|
||
<pre><code> ARCH= -m64</code></pre>
|
||
<p>Note, however, that some platforms will not necessarily support some
|
||
architectures. For instance, more recent versions of <code>macOS</code> do <strong>NOT</strong>
|
||
support 32-bit, and more than zero Judges use it!</p>
|
||
<h3 id="about-x">About X</h3>
|
||
<p>X client submissions should be as portable as possible. Submissions
|
||
that adapt to a wide collection of environments will be favored. For
|
||
example, don’t depend on a particular type or size of display. Don’t
|
||
assume the use of a particular browser. Instead assume a generic
|
||
browser that forms to a widely used <a href="https://www.w3.org/standards/">W3C
|
||
standard</a>. Don’t assume a particular
|
||
sound sub-system or video driver is installed in the OS. Instead, make
|
||
use of a well known and widely available open source program (one that
|
||
actually works) to display audio/visual data.</p>
|
||
<p>X client submissions should avoid using X related libraries and
|
||
software that are not in wide spread use.</p>
|
||
<p>As of Red Hat RHEL9.0, the X.org server is deprecated. See the FAQ on
|
||
“<a href="../faq.html#Xorg_deprecated">Xorg deprecation”</a>” for more details.
|
||
This does not mean that a submission using this will necessarily be
|
||
rejected, but it would be better if it can support Wayland in some way
|
||
or another.</p>
|
||
<p>We <strong>DISLIKE</strong> submissions that use proprietary toolkits such as the
|
||
<code>M*tif</code>, <code>Xv*ew</code>, or <code>OpenL*ok</code> toolkits, since not everyone has them.
|
||
Use an open source toolkit that is widely and freely available instead.</p>
|
||
<p>X client submissions should try to not to depend on particular items in
|
||
<code>.Xdefaults</code>. If you must do so, be sure to note the required lines in
|
||
the your <code>remarks.md</code> file. They should also not depend on any
|
||
particular window manager.</p>
|
||
<div id="about-curses">
|
||
<h3 id="about-libcurses">About libcurses</h3>
|
||
</div>
|
||
<p>One should restrict libcurses to portable features found on both BSD
|
||
and Linux curses.</p>
|
||
<p class="leftbar">
|
||
If you do <code>#include <curses.h></code> make <strong>CERTAIN</strong> you link in curses
|
||
(i.e. <code>-lcurses</code>) and not ncurses (i.e. <code>-lncurses</code>).
|
||
</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="about_tab">
|
||
<h3 id="about-ascii-tab">About ASCII TAB</h3>
|
||
</div>
|
||
<p>We <strong>DISLIKE</strong> the use of ASCII tab characters in markdown files, such
|
||
as in the required <code>remarks.md</code> file.</p>
|
||
<p>We don’t mind the use of ASCII tab characters in your C code. Feel
|
||
free to use ASCII tab characters if that suits your obfuscation needs.
|
||
If is perfectly <strong>OK</strong> to use tab characters elsewhere in your
|
||
submission, just not in markdown files as this tends annoy us when it
|
||
comes time to rendering your markdown content as it complicates the
|
||
process.</p>
|
||
<p>If you do use ASCII tab characters in your non-markdown files, be aware
|
||
that some people may use a tab stop that is different than the common 8
|
||
character tab stop.</p>
|
||
<p><strong>PLEASE</strong> observe our <a href="../markdown.html">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.</p>
|
||
<p>See also <a href="rules.html#rule4-required-files">Rule 4 - Required files</a>,
|
||
and the FAQ on “<a href="../faq.html#markdown">markdown</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="remarks">
|
||
<h3 id="about-remarks.md">About remarks.md</h3>
|
||
</div>
|
||
<p>You are better off explaining what your submission does in your
|
||
<code>remarks.md</code> file section rather than leaving it obscure for the
|
||
<a href="../judges.html">Judges</a> as we might miss something and/or be too tired
|
||
to notice.</p>
|
||
<p>We freely admit that interesting, creative or humorous comments in your
|
||
<code>remarks.md</code> file help your chances of winning. If you had to read so
|
||
many twisted submissions, you too would enjoy a good laugh or two. We
|
||
think the readers of the contest winners do as well. We do read your
|
||
<code>remarks.md</code> content during the judging process, so it is worth your
|
||
while to write a remarkable <code>remarks.md</code> file.</p>
|
||
<p>It is a very good idea to, in your <code>remarks.md</code> file, tell us why you
|
||
think your submission is obfuscated. This is particularly true if your
|
||
submission has some very subtle obfuscations that we might otherwise
|
||
overlook. <strong><<– Hint!</strong></p>
|
||
<p>Anyone can format their code into a dense blob. A really clever author
|
||
will try format their submission using a “normal” formatting style such
|
||
that at first glance (if you squint and don’t look at the details) the
|
||
code might pass for non-obfuscated C. Deceptive comments, and
|
||
misleading formatting, in some cases, may be a plus. On the other
|
||
hand, a misleading code style requires more source bytes.</p>
|
||
<p>If you do elect to use misleading formatting and comments, we suggest
|
||
you remark on this point in your <code>remarks.md</code> where you talk about why
|
||
you think your submission is obfuscated. On the other hand, if you are
|
||
pushing up against the size limits, you may be forced into creating a
|
||
dense blob. Such are the trade-offs that obfuscators face!</p>
|
||
<p>We <strong>LIKE</strong> reading <code>remarks.md</code> files, especially if they contain
|
||
useful, informative, and even humorous content about your submission.
|
||
Yes, this is a <strong>hint</strong>. :-)</p>
|
||
<p>We <strong>RECOMMEND</strong> you put a reasonable amount effort into the content of
|
||
the <code>remarks.md</code> file: it is a required file for a reason. :-)</p>
|
||
<p>Try to be even more creative!</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<h3 id="miscellaneous">Miscellaneous</h3>
|
||
<p>While we recognize that UNIX is not a universal operating system, the
|
||
contest does have a bias towards such systems. In an effort to expand
|
||
the scope of the contest, we phrase our bias to favor the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
|
||
Specification</a>
|
||
(UNIX-like).</p>
|
||
<p>You are <strong>well advised</strong> to submit code that conforms to the <a href="https://unix.org/version4/overview.html">Single
|
||
UNIX Specification Version 4</a>.</p>
|
||
<p>To quote the <a href="../judges.html">Judges</a>:</p>
|
||
<p>We <strong>LIKE</strong> programs that:</p>
|
||
<ul>
|
||
<li>are as concise and small as they need to be</li>
|
||
<li>do something at least quasi-interesting</li>
|
||
<li>are portable</li>
|
||
<li>are unique or novel in their obfuscation style</li>
|
||
<li>make use of a <strong>NUMBER OF DIFFERENT TYPES OF OBFUSCATIONS!</strong> <strong><== HINT!!</strong></li>
|
||
<li>make us laugh and/or throw up :-) (humor really helps!)</li>
|
||
<li>make us want to eat good chocolate</li>
|
||
</ul>
|
||
<p>Some types of programs can’t excel (anti-tm) in some areas. Your
|
||
program doesn’t have to excel in all areas, but doing well in several
|
||
areas really does help.</p>
|
||
<p>If there are limitations in your submission, you are highly encouraged
|
||
to note such limitations in your <code>remarks.md</code> file. For example if
|
||
your submission factors values up to a certain size, you might want to
|
||
state:</p>
|
||
<blockquote>
|
||
<p>This submission factors values up
|
||
<code>2305567963945518424753102147331756070</code>. Attempting to factor larger
|
||
values will produce unpredictable results.</p>
|
||
</blockquote>
|
||
<p>The <a href="../judges.html">Judges</a> might try to factor the value -5, so you
|
||
want to might state:</p>
|
||
<blockquote>
|
||
<p>This submission factors positive values up
|
||
<code>2305567963945518424753102147331756070</code>. Attempting to factor large
|
||
values will produce unpredictable results.</p>
|
||
</blockquote>
|
||
<p>However the <a href="../judges.html">Judges</a> might try to also factor 0, so you
|
||
might want to state:</p>
|
||
<blockquote>
|
||
<p>This submission factors values between 1 and
|
||
<code>2305567963945518424753102147331756070</code>. Attempting to factor values
|
||
outside that range will produce unpredictable results.</p>
|
||
</blockquote>
|
||
<p>Moreover they might try to also factor 3.5 or 0x7, or Fred, so you want
|
||
to might state:</p>
|
||
<blockquote>
|
||
<p>This submission factors integers between 1 and
|
||
<code>2305567963945518424753102147331756070</code>. Attempting to factor anything
|
||
else will produce unpredictable results.</p>
|
||
</blockquote>
|
||
<p>You submission might be better off catching the attempt to factor bogus
|
||
values and doing something interesting. So you might want to code
|
||
accordingly and state:</p>
|
||
<blockquote>
|
||
<p>This submission factors integers between 1 and
|
||
<code>2305567963945518424753102147331756070</code>. Attempting to factor anything
|
||
else will cause the program to insult your pet fish Eric.</p>
|
||
</blockquote>
|
||
<p>The <a href="../judges.html">Judges</a> might not have a pet fish named Eric, so
|
||
you might want to state:</p>
|
||
<blockquote>
|
||
<p>This submission factors integers between 1 and
|
||
<code>2305567963945518424753102147331756070</code>. Attempting to factor anything
|
||
else will cause the program to insult your pet fish Eric, or in the
|
||
case that you lack such a pet, will insult the pet that you do not
|
||
have.</p>
|
||
</blockquote>
|
||
<p>When all other things are equal, a submission with fewer limitations
|
||
will be judged better than a submission with lots of limitations. So
|
||
you might want to code accordingly and state:</p>
|
||
<blockquote>
|
||
<p>This submission attempts to a factor value of any size provided
|
||
that the program is given enough time and memory. If the value is not
|
||
a proper integer, the program might insult a fish named Eric.</p>
|
||
</blockquote>
|
||
<p>Do not fear if you’re not 100% sure of the significance of
|
||
<code>2305567963945518424753102147331756070</code> as it is not of prime
|
||
importance: or is it? :-)</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="mkiocccentry">
|
||
<div id="mkiocccentry_toolkit">
|
||
<h2 id="guidelines-for-the-mkiocccentry-toolkit">Guidelines for the mkiocccentry toolkit</h2>
|
||
</div>
|
||
</div>
|
||
<p>The <a href="https://submit.ioccc.org">IOCCC submit server</a>, and related
|
||
services use the <strong>most recent version</strong> of the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||
toolkit</a>: submissions that
|
||
package using older versions of the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||
toolkit</a> are <strong>LIKELY</strong> to
|
||
be <strong>REJECTED</strong>!</p>
|
||
<p>You <strong>REALLY SHOULD</strong> use the latest <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||
toolkit</a> to package your
|
||
submission as submissions that use an older version are <strong>WILL</strong>
|
||
be <strong>REJECTED</strong>!</p>
|
||
<p>The <code>mkiocccentry(1)</code> tool runs a number of checks by way of these
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
|
||
tools:</p>
|
||
<ul>
|
||
<li>iocccsize(1)</li>
|
||
<li>txzchk(1)</li>
|
||
<li>fnamchk(1)</li>
|
||
<li>chksubmit(1)</li>
|
||
<li>chkentry(1)</li>
|
||
</ul>
|
||
<p>Do <strong>NOT</strong> use <code>txzchk(1)</code> or <code>fnamchk(1)</code> command line options that
|
||
are labelled “<strong>for TESTING purposes</strong>” in their respective man pages.</p>
|
||
<p>Do <strong>NOT</strong> use <code>fnamchk(1)</code> command line options that are labelled
|
||
“<strong>for TESTING purposes</strong>” in the <code>fnamchk(1)</code> man page.</p>
|
||
<p>Do <strong>NOT</strong> use <code>chksubmit(1)</code> command line options that are labelled
|
||
“<strong>for the use by the Judges only</strong>” in the <code>chksubmit(1)</code> man page.</p>
|
||
<p>Similarly do <strong>NOT</strong> use <code>chkentry(1)</code> command line options marked
|
||
“<strong>for the use by the Judges only</strong>” in the <code>chkentry(1)</code> man page.</p>
|
||
<p>To view <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||
toolkit</a> man pages, while
|
||
your current directory is the top of the source tree:</p>
|
||
<pre><code> man soup/man/man1/mkiocccentry.1
|
||
man soup/man/man1/iocccsize.1
|
||
man soup/man/man1/txzchk.1
|
||
man test_ioccc/man/man1/fnamchk.1
|
||
man soup/man/man1/chksubmit.1
|
||
man soup/man/man1/chkentry.1</code></pre>
|
||
<p>The above <code>man(1)</code> commands will show the toolkit man pages without
|
||
having to install them first.</p>
|
||
<p>So that you do not have to repeatedly answer all the <code>mkiocccentry(1)</code>
|
||
questions, use <code>mkiocccentry -a answers ...</code> to create a file
|
||
containing the answers you first give, so later enter <code>mkiocccentry -i answers ...</code> to reuse those same answers.</p>
|
||
<p>The <code>mkiocccentry -A answers ...</code> does the same thing except that the
|
||
<strong>answers file will be overwritten</strong>.</p>
|
||
<p>The <code>mkiocccentry -i answers ...</code> will still be required to confirm
|
||
“<em>Yes/No</em>” questions.</p>
|
||
<p>Use <code>mkiocccentry -Y -i answers ..</code> to force a yes answers with <strong>great
|
||
caution</strong> because it might force a yes answer to something you do
|
||
<strong>NOT</strong> want, such as a change in your code that violates a detected
|
||
rule.</p>
|
||
<p>The <code>mkiocccentry -i answers ..</code> will still be required to confirm
|
||
“<em>Yes/No</em>” questions. While <code>mkiocccentry -Y -i answers ..</code> will force
|
||
yes answers, use with <strong>great caution</strong>, because it might force a yes
|
||
answer to something you do <strong>NOT</strong> want.</p>
|
||
<p>To help with not having to repeatedly enter a UUID, put your UUID into
|
||
a file and use <code>mkiocccentry -u uuidfile ...</code>, or use <code>mkiocccentry -U UUID ...</code> to give the <code>UUID</code> on the command line.</p>
|
||
<p>If you wish to <strong>test</strong> that your submission passes the
|
||
<code>mkiocccentry(1)</code> tests without having to type in answers each time,
|
||
you can use the <code>-d</code> or <code>-s seed</code> option to <code>mkiocccentry</code> for the tool
|
||
to pseudo-randomly create answers for you. For example:</p>
|
||
<pre><code> mkiocccentry -d workdir topdir</code></pre>
|
||
<p class="leftbar">
|
||
Do <strong>NOT</strong> submit a tarball formed by <code>mkiocccentry -d ...</code> <strong>OR</strong> by
|
||
<code>mkiocccentry -s seed ...</code> <strong>OR</strong> by using the <code>test</code> UUID.
|
||
</p>
|
||
<p class="leftbar">
|
||
The <code>mkiocccentry(1)</code> tool creates an <code>xz(1)</code> compressed <strong>v7 format</strong>
|
||
tarball using a <code>tar(1)</code> command of the form:
|
||
</p>
|
||
<pre><code> cd workdir/UUID-slot_num && tar --format=v7 -cJf submit.UUID-slot_num.timestamp.txz UUID-slot_num</code></pre>
|
||
<p>In many places the <code>mkiocccentry(1)</code> tool will prompt you to verify
|
||
what you input, allowing you to correct details as you go along.</p>
|
||
<p class="leftbar">
|
||
Pressing the “<em>enter key</em>” at the <code>mkiocccentry(1)</code> tool prompts will
|
||
allow you to proceed with a default, however make sure the default is
|
||
the <strong>CORRECT</strong> answer.
|
||
</p>
|
||
<p>The <code>mkiocccentry(1)</code> tool will use code from <code>iocccsize(1)</code> which
|
||
detects a number of issues (such as <a href="rules.html#rule2-size">Rule 2 - Size
|
||
restrictions</a>) that you may ignore, however
|
||
ignoring such issues <strong>comes with a SIGNIFICANT level of risk!</strong></p>
|
||
<p>Once the tarball is packaged it will run <code>txzchk(1)</code>, which will also
|
||
run <code>fnamchk(1)</code>, as part of its algorithm.</p>
|
||
<p class="leftbar">
|
||
The use of <code>mkiocccentry -W ...</code> is <strong>highly discouraged</strong> as this may
|
||
ignore warnings about a problem that may cause your submission to be
|
||
<strong>REJECTED!</strong>.
|
||
</p>
|
||
<p class="leftbar">
|
||
The same can be said of <code>mkiocccentry -Y ...</code> , and to a lesser extent
|
||
<code>mkiocccentry -y ...</code>: the <code>-y</code> is mostly for the test script and the
|
||
<code>-Y</code> is like <code>-y</code> but even more aggressive.
|
||
</p>
|
||
<p>If <code>mkiocccentry</code> encounters an <strong>error</strong>, the program will exit and
|
||
the xz compressed tarball <strong>will NOT be generated</strong>: this is a
|
||
<strong>feature, not a bug</strong>!</p>
|
||
<p>If you encounter a <strong>bug</strong> with the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||
toolkit</a> <strong>PLEASE run the
|
||
<code>bug_report.sh</code> script to help us out here!</strong></p>
|
||
<p class="leftbar">
|
||
While you don’t have to install the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||
toolkit</a>, if you don’t, in
|
||
order to run a tool outside the repo directory you will have to specify
|
||
<code>mkiocccentry(1)</code> command line options to locate required tools such as
|
||
<code>chkentry(1)</code> (<code>mkiocccentry -C chkentry ...</code>), <code>txzchk(1)</code>
|
||
(<code>mkiocccentry -T txzchk ...</code>), and <code>fnamchk(1)</code> (<code>mkiocccentry -F fnamchk ...</code>).
|
||
</p>
|
||
<p class="leftbar">
|
||
The <code>mkiocccentry(1)</code> tool will ignore any filename or directory that
|
||
begins with a period (<code>.</code>).
|
||
</p>
|
||
<p class="leftbar">
|
||
The <code>mkiocccentry(1)</code> tool will ignore all files that begin with
|
||
<code>COPYING</code>, <code>COPYRIGHT</code>, and <code>LICENSE</code>, regardless of filename case.
|
||
</p>
|
||
<p class="leftbar">
|
||
The <code>mkiocccentry(1)</code> tool will reject any of the following files if
|
||
they are found directly under the top level directory (<code>topdir</code>):
|
||
</p>
|
||
<p class="leftbar">
|
||
<ul>
|
||
<li>README.md</li>
|
||
<li>index.html</li>
|
||
<li>prog</li>
|
||
<li>prog.alt</li>
|
||
<li>prog.alt.o</li>
|
||
<li>prog.orig.c</li>
|
||
<li>filenames matching the <code>[0-9][0-9][0-9][0-9]_*.tar.bz2</code> file glob</li>
|
||
</ul>
|
||
</p>
|
||
<p class="leftbar">
|
||
The files listed in the above list are allowed to exist in
|
||
sub-directories: just <strong>NOT</strong> directly under the top level directory
|
||
(<code>topdir</code>).
|
||
</p>
|
||
<p class="leftbar">
|
||
The <code>mkiocccentry(1)</code> tool evaluates all filenames and directory names
|
||
in a case independent way: thus <code>FOO</code>, <code>Foo</code>, and <code>foo</code> are considered
|
||
the <strong>SAME</strong> file even if your filesystem doesn’t do the same.
|
||
</p>
|
||
<p class="leftbar">
|
||
Having two or more filenames that differ only by case <strong>WILL</strong> lead to
|
||
problems because of the previous statement.
|
||
</p>
|
||
<p class="leftbar">
|
||
When the <code>mkiocccentry(1)</code> tool ignores a file, that file is <strong>NOT</strong>
|
||
included as part of your submission.
|
||
</p>
|
||
<p class="leftbar">
|
||
When the <code>mkiocccentry(1)</code> tool ignores a directory, that directory,
|
||
and everything under that directory is <strong>NOT</strong> included as part of your
|
||
submission.
|
||
</p>
|
||
<p class="leftbar">
|
||
The <code>mkiocccentry(1)</code> tool will ignore all symlinks.
|
||
</p>
|
||
<p class="leftbar">
|
||
Creating a directory directly under the top level directory (<code>topdir</code>)
|
||
that is normally considered to be a regular file, such as a directory
|
||
named <code>Makefile</code>, <code>prog.alt.c</code>, <code>prog.c</code>, <code>remarks.md</code>, <code>try.alt.sh</code>,
|
||
or <code>try.sh</code> is <strong>NOT</strong> a good idea and will likely cause the
|
||
<code>mkiocccentry(1)</code> tool to abort with a <strong>fatal error</strong>.
|
||
</p>
|
||
<p class="leftbar">
|
||
The required <code>Makefile</code> and <code>remarks.md</code> files may <strong>NOT</strong> be empty.
|
||
This does not mean just 0 bytes but also that it <strong>MUST</strong> have
|
||
<strong>content</strong>, and content that is relevant (e.g. a Makefile with just
|
||
comments is <strong>NOT</strong> allowed). However, with the exception of the
|
||
<code>Makefile</code>, the <code>mkiocccentry(1)</code> tool will <strong>ONLY</strong> check file size.
|
||
</p>
|
||
<p class="leftbar">
|
||
If the optional file <code>try.alt.sh</code>, or <code>try.sh</code> exists and is an empty
|
||
file, the <code>mkiocccentry(1)</code> tool will abort with a <strong>fatal error</strong>.
|
||
</p>
|
||
<p class="leftbar">
|
||
If the <code>mkiocccentry(1)</code> tool encounters anything that isn’t a file,
|
||
isn’t a directory, and isn’t a symlink (which the tool ignores), the
|
||
<code>mkiocccentry(1)</code> tool to abort with a <strong>fatal error</strong>.
|
||
</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#mkiocccentry_bugs">How do I report bugs in an <code>mkiocccentry</code>
|
||
tool?</a>”.</p>
|
||
<p>See <a href="rules.html#rule11-legal-rule-abuse">Rule 11 - Legal rule abuse</a>
|
||
for warnings about ignoring <code>mkiocccentry(1)</code> tool warnings.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#fnamchk">What is the <code>fnamchk</code> tool?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#about_mkiocccentry">What is mkiocccentry in simple
|
||
terms?</a>”.</p>
|
||
<p>See the
|
||
FAQ on “<a href="../faq.html#mkiocccentry">What is the mkiocccentry tool, how do I obtain it and how do I
|
||
use it</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="fun">
|
||
<h2 id="fundamental-guidelines">Fun😄damental Guidelines</h2>
|
||
</div>
|
||
<p>The reason for the times of day are so that key IOCCC events are
|
||
<strong>calculated</strong> to be a <strong>fun</strong>ctional UTC time. :-)</p>
|
||
<p>At least 2 of several reasons for selecting the prime, 2503, for <a href="rules.html#rule2b-net-size">Rule
|
||
2b - Net Size</a> may be found on the
|
||
<a href="https://t5k.org/curios/page.php/2503.html">“Curios!” about 2503</a>.</p>
|
||
<p>The 2503 value for <a href="rules.html#rule2b-net-size">Rule 2b - Net Size</a> is
|
||
a decimal anagram of the number of the kernel disk pack of one of the
|
||
judge’s <a href="https://en.wikipedia.org/wiki/BESM-6">BESM-6</a>.</p>
|
||
<p class="leftbar">
|
||
There may or may not be fewer than 2^7+1 reasons why these
|
||
<a href="guidelines.html">Guidelines</a> seem obfuscated.
|
||
</p>
|
||
<p class="leftbar">
|
||
Excessively “<em>dotty”</em> use of the <code>chksubmit(1)</code> or <code>chkentry(1)</code>
|
||
commands suggests that either you like silly things, or that you
|
||
<a href="https://en.wikipedia.org/wiki/RTFM">RTFS</a> with some level of care.
|
||
</p>
|
||
<p>Some people might question what actually constitutes a valid JSON file,
|
||
given the state of the “<em>so-called</em>” JSON spec. :-)</p>
|
||
<p>We prefer programs that do not require a fish license: crayons and cat
|
||
detector vans not withstanding.</p>
|
||
<p class="leftbar">
|
||
This <em>guideline</em> has a change mark at the very start of this line.
|
||
</p>
|
||
<p>While those who are used to temperatures found on <a href="https://science.nasa.gov/dwarf-planets/">dwarf
|
||
planets</a> (<strong>yes Virginia,
|
||
dwarf planets <em>ARE</em> planets!</strong>), such as
|
||
<a href="https://science.nasa.gov/dwarf-planets/pluto/">Pluto</a>, might be able
|
||
to explain to the Walrus why our seas are boiling hot, the question of
|
||
whether pigs have wings is likely to remain a debatable point to most.</p>
|
||
<p>At least one judge prefers to maintain the use of the
|
||
<a href="https://en.wikipedia.org/wiki/Leap_second">leap-second</a> as part of the
|
||
world’s time standard. If your code prints time with seconds, we
|
||
prefer that your code be capable of printing the time of day during a
|
||
leap-second where the value in seconds after the minute mark is <strong>60</strong>.</p>
|
||
<p>Other windows, on the other hand, might be OK: especially where “<strong>X
|
||
marks the spot</strong>”. Yet on the third hand, windows are best when they
|
||
are “unseen” (i.e., not dirty). :-)</p>
|
||
<p>The <a href="../judges.html">Judges</a>, as a group, have a history giving wide
|
||
degree of latitude to reasonable submissions. And recently they have
|
||
had as much longitudinal variation as it is possible to have on
|
||
<a href="https://science.nasa.gov/earth/">Earth</a>. :-) Other windows, on the
|
||
other hand, might be OK: especially where “<strong>X marks the spot</strong>”. Yet
|
||
on the third hand, windows are best when they are “unseen” (i.e., not
|
||
dirty). :-)</p>
|
||
<p>The <a href="../judges.html">Judges</a>, as a group, have a history giving wide
|
||
degree of latitude to reasonable submissions. And recently they have
|
||
had as much longitudinal variation as it is possible to have on
|
||
<a href="https://science.nasa.gov/earth/">Earth</a>. :-)</p>
|
||
<blockquote>
|
||
<p>You are in a maze of twisty <em>guidelines</em>, all different.</p>
|
||
</blockquote>
|
||
<p>There are at least zero <a href="../judges.html">Judges</a> who think that
|
||
<a href="https://en.wikipedia.org/wiki/Fideism">Fideism</a> has little or nothing
|
||
to do with the Judging process.</p>
|
||
<blockquote>
|
||
<p>All generalizations are false, including this one. – <strong>Mark Twain</strong></p>
|
||
</blockquote>
|
||
<p class="leftbar">
|
||
There are more than about 1 typos in this very sentence.
|
||
</p>
|
||
<p>This could be the only <em>guideline</em> that contains the word
|
||
<a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>.</p>
|
||
<p>However, do you know how to play
|
||
<a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>?
|
||
You do?!? (Except on Tuesday?)</p>
|
||
<p>OK, there are actually 2 <em>guidelines</em> that contain the word
|
||
<a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>,
|
||
unless you count this one, in which case there are 3. :-)</p>
|
||
<p><strong>NOTE</strong>: The previous <em>guideline</em> in this spot has been replaced by
|
||
this <em>guideline</em>:</p>
|
||
<p class="leftbar">
|
||
You very well might not be completely prohibited from failing to not
|
||
partly misunderstand this particular <em>guideline</em>, but of course, we
|
||
could not possibly comment! Nevertheless, you are neither prohibited,
|
||
nor are you fully or partly required to determine that this or the
|
||
previous sentence is either false and/or perhaps misleading.
|
||
Therefore, it might be wise for you to not fail to consider to not do
|
||
so, accordingly. Thank you very much (allegedly).
|
||
</p>
|
||
<p>Any complaints about the above <em>guideline</em> could be addressed to the
|
||
Speaker of the House of Commons, or to the speaker of your national
|
||
parliament should you have one.</p>
|
||
<p class="leftbar">
|
||
Please try to avoid this specific individual <em>guideline</em>, if it is at
|
||
all possible.
|
||
</p>
|
||
<p>We believe that Mark Twain’s quote:</p>
|
||
<blockquote>
|
||
<p>Get your facts first, then you can distort them as you please.</p>
|
||
</blockquote>
|
||
<p>… is a good motto for those writing code for the IOCCC.</p>
|
||
<p class="leftbar">
|
||
We do not recommend submitting <a href="https://systemd.io">systemd</a> source
|
||
code to the IOCCC, if nothing else because that code is likely to
|
||
exceed <a href="rules.html#rule2-size">Rule 2 - Size restrictions</a>. This isn’t
|
||
to say that another highly compact and obfuscated replacement of
|
||
<code>init(8)</code> would not be an interesting submission.
|
||
</p>
|
||
<p class="leftbar">
|
||
The IOCCC size tool
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">iocccsize</a>
|
||
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.
|
||
:-)
|
||
</p>
|
||
<p class="leftbar">
|
||
The IOCCC tarball validator
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c">txzchk</a>
|
||
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. :-)
|
||
</p>
|
||
<p class="leftbar">
|
||
Even so, those tools exceed the <a href="rules.html#rule2-size">Rule 2 - Size
|
||
restrictions</a> so they wouldn’t qualify for the
|
||
contest anyway.
|
||
</p>
|
||
<p class="leftbar">
|
||
If the <a href="../judges.html">IOCCC judges</a> are feeling like it, they 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">
|
||
With respect to <a href="#nested-functions">nested functions</a>, try <code>chkentry -b</code>.
|
||
</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="more-information">
|
||
<div id="information">
|
||
<h1 id="further-reading">Further Reading</h1>
|
||
</div>
|
||
</div>
|
||
<p>See the <a href="../news.html">Official IOCCC website news</a> for additional
|
||
information.</p>
|
||
<p>For questions or comments about the contest, see <a href="../contact.html">Contacting the
|
||
IOCCC</a>.</p>
|
||
<p><strong>Be SURE</strong> to review the current <a href="index.html">IOCCC Rules and
|
||
Guidelines</a> as they often change year to year. Especially
|
||
prior to submitting to the contest.</p>
|
||
<p>For the latest IOCCC news, 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.</p>
|
||
<p>Also consider joining the <a href="https://discord.com/invite/Wa42Qujwnw">IOCCC Discord
|
||
Server</a> for the latest news,
|
||
discussions about The Rules, questions for the Judges, and <code>C</code> in
|
||
general.</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 -->
|