The text was actually already there (as I thought since I had added it some days back).
1840 lines
86 KiB
HTML
1840 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>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 -->
|