The FAQ now notes that there can be times where the jparse repo (https://github.com/xexyl/jparse/) is different from the mkiocccentry repo's subdirectory jparse. This is one of the reasons the tools in the mkiocccentry and the jparse repo show the jparse API with the -V (version) option. I believe that this is all that's needed for the jparse repo in the FAQ but time will tell on that.
5485 lines
316 KiB
HTML
5485 lines
316 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 FAQ">
|
||
<meta name="keywords" content="IOCCC, FAQ, questions, answers, Frequently Asked Questions">
|
||
</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: faq.md -->
|
||
<!-- -->
|
||
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: faq.md !!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: faq.md !!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: faq.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 winning authors
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="./bugs.html" class="sub-item-link">
|
||
Bugs and (mis)features
|
||
</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">
|
||
IOCCC 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/index.html" class="sub-item-link">
|
||
Rules and Guidelines
|
||
</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">
|
||
FAQ
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="./faq.html#submit" class="sub-item-link">
|
||
How to enter the IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="./faq.html#fix_an_entry" class="sub-item-link">
|
||
Fixing IOCCC entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="./faq.html#fix_web_site" class="sub-item-link">
|
||
Fixing the website
|
||
</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">
|
||
About
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
<div class="outfit-font">
|
||
<a href="./index.html" class="sub-item-link">
|
||
IOCCC Home
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="./judges.html" class="sub-item-link">
|
||
The IOCCC Judges
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="./contact.html" class="sub-item-link">
|
||
Contacting the IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="./SECURITY.html" class="sub-item-link">
|
||
IOCCC Security Policy
|
||
</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="./markdown.html" class="sub-item-link">
|
||
IOCCC markdown guidelines
|
||
</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">
|
||
Authors of winning IOCCC entries
|
||
</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>
|
||
|
||
</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="./status.html">
|
||
Contest status
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="./next/index.html">
|
||
Rules and Guidelines
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="./news.html">
|
||
IOCCC News
|
||
</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="./faq.html#submit">
|
||
How to enter the IOCCC
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="./faq.html#fix_an_entry">
|
||
Fixing IOCCC entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="./faq.html#fix_web_site">
|
||
Fixing the website
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="./faq.html#fix_author">
|
||
Fixing author info
|
||
</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">
|
||
IOCCC Home
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="./judges.html">
|
||
The IOCCC Judges
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="./contact.html">
|
||
Contacting the IOCCC
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="./thanks-for-help.html">
|
||
Thanks for the help
|
||
</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>Frequently Asked Questions</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%2Fioccc-src.github.io%2Ftemp-test-ioccc%2Ffaq.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: faq.md -->
|
||
<h1 id="faq-table-of-contents">FAQ Table of Contents</h1>
|
||
<p>This is FAQ version <strong>28.0.4 2024-08-24</strong>.</p>
|
||
<h2 id="section-0---submitting-to-a-new-ioccc">Section 0 - <a href="#faq0">Submitting to a new IOCCC</a></h2>
|
||
<ul>
|
||
<li><a class="normal" href="#faq0_0">0.0 - How may I enter the IOCCC?</a></li>
|
||
<li><a class="normal" href="#faq0_1">0.1 - What types of entries have been frequently submitted to the IOCCC?</a></li>
|
||
<li><a class="normal" href="#faq0_2">0.2 - What should I put in my submission’s Makefile?</a></li>
|
||
<li><a class="normal" href="#faq0_3">0.3 - May I use a different source or compiled filename than prog.c or prog?</a></li>
|
||
<li><a class="normal" href="#faq0_4">0.4 - What platform should I assume for my submission?</a></li>
|
||
<li><a class="normal" href="#faq0_5">0.5 - How may I comment or make a suggestion on IOCCC rules, guidelines and tools?</a></li>
|
||
<li><a class="normal" href="#faq0_6">0.6 - What is the best way to ask a question about the IOCCC rules, guideline and tools?</a></li>
|
||
<li><a class="normal" href="#faq0_7">0.7 - What are the IOCCC best practices for using markdown?</a></li>
|
||
<li><a class="normal" href="#faq0_8">0.8 - How do I report bugs in a <code>mkiocccentry</code> tool?</a></li>
|
||
<li><a class="normal" href="#faq0_9">0.9 - What is a <code>.auth.json</code> file?</a></li>
|
||
<li><a class="normal" href="#faq0_10">0.10 - What is a <code>.info.json</code> file?</a></li>
|
||
<li><a class="normal" href="#faq0_11">0.11 - How can I validate any JSON document?</a></li>
|
||
<li><a class="normal" href="#faq0_12">0.12 - How can I validate my <code>.auth.json</code> and/or <code>.info.json</code> files?</a></li>
|
||
<li><a class="normal" href="#faq0_13">0.13 - How can I validate my submission tarball?</a></li>
|
||
<li><a class="normal" href="#faq0_14">0.14 - What is the <code>fnamchk</code> tool?</a></li>
|
||
<li><a class="normal" href="#faq0_15">0.15 - What is the <code>mkiocccentry</code> tool and how do I use it?</a></li>
|
||
<li><a class="normal" href="#faq0_16">0.16 - How do I compile <code>mkiocccentry</code> and related tools?</a></li>
|
||
</ul>
|
||
<h2 id="section-1---history-of-the-ioccc">Section 1 - <a href="#faq1">History of the IOCCC</a></h2>
|
||
<ul>
|
||
<li><a class="normal" href="#faq1_0">1.0 - How did the IOCCC get started?</a></li>
|
||
<li><a class="normal" href="#faq1_1">1.1 - Why are some years missing IOCCC entries?</a></li>
|
||
<li><a class="normal" href="#faq1_2">1.2 - What is the history of the IOCCC website?</a></li>
|
||
<li><a class="normal" href="#faq1_3">1.3 - How has the IOCCC size limit rule changed over the years?</a></li>
|
||
<li><a class="normal" href="#faq1_4">1.4 - What is the <strong>Great Fork Merge</strong>?</a></li>
|
||
</ul>
|
||
<h2 id="section-2---ioccc-judging-process">Section 2 - <a href="#faq2">IOCCC Judging process</a></h2>
|
||
<ul>
|
||
<li><a class="normal" href="#faq2_0">2.0 - How many submissions do the judges receive for a given IOCCC?</a></li>
|
||
<li><a class="normal" href="#faq2_1">2.1 - What should I put in the remarks.md file of my submission?</a></li>
|
||
<li><a class="normal" href="#faq2_2">2.2 - Why don’t you publish submissions that do not win?</a></li>
|
||
<li><a class="normal" href="#faq2_3">2.3 - How much time does it take to judge the contest?</a></li>
|
||
<li><a class="normal" href="#faq2_4">2.4 - How many judging rounds do you have?</a></li>
|
||
<li><a class="normal" href="#faq2_5">2.5 - Why do some IOCCC entries receive the Grand Prize or Best of Show award?</a></li>
|
||
<li><a class="normal" href="#faq2_6">2.6 - How are IOCCC entries announced?</a></li>
|
||
</ul>
|
||
<h2 id="section-3---compiling-and-running-ioccc-entries">Section 3 - <a href="#faq3">Compiling and running IOCCC entries</a></h2>
|
||
<ul>
|
||
<li><a class="normal" href="#faq3_0">3.0 - What Makefile rules are available to build or clean up IOCCC entries?</a></li>
|
||
<li><a class="normal" href="#faq3_1">3.1 - Why doesn’t an IOCCC entry compile?</a></li>
|
||
<li><a class="normal" href="#faq3_2">3.2 - Why does an IOCCC entry fail on my 64-bit system?</a></li>
|
||
<li><a class="normal" href="#faq3_3">3.3 - Why do some IOCCC entries fail to compile under macOS?</a></li>
|
||
<li><a class="normal" href="#faq3_4">3.4 - Why does clang or gcc fail to compile an IOCCC entry?</a></li>
|
||
<li><a class="normal" href="#faq3_5">3.5 - What is this cb tool that is mentioned in the IOCCC?</a></li>
|
||
<li><a class="normal" href="#faq3_6">3.6 - An IOCCC entry messed up my terminal application, how do I fix this?</a></li>
|
||
<li><a class="normal" href="#faq3_7">3.7 - How do I run an IOCCC entry that requires X11?</a></li>
|
||
<li><a class="normal" href="#faq3_8">3.8 - How do I compile an IOCCC entry that requires SDL1 or SDL2?</a></li>
|
||
<li><a class="normal" href="#faq3_9">3.9 - How do I compile an IOCCC entry that requires (n)curses?</a></li>
|
||
<li><a class="normal" href="#faq3_10">3.10 - How do I compile and use an IOCCC entry that requires sound?</a></li>
|
||
<li><a class="normal" href="#faq3_11">3.11 - Why do Makefiles use -Weverything with clang?</a></li>
|
||
<li><a class="normal" href="#faq3_12">3.12 - How do I find out how to send interrupt/EOF etc. for entries that require it?</a></li>
|
||
<li><a class="normal" href="#faq3_13">3.13 - Why does an IOCCC entry fail to compile and/or fail to run?</a></li>
|
||
<li><a class="normal" href="#faq3_14">3.14 - How do I compile and install tcpserver for entries that require it?</a></li>
|
||
<li><a class="normal" href="#faq3_15">3.15 - How do I compile and install netpbm for entries that require it?</a></li>
|
||
<li><a class="normal" href="#faq3_16">3.16 - How do I compile and install libjpeg-turbo for entries that require it?</a></li>
|
||
<li><a class="normal" href="#faq3_17">3.17 - How do I compile and install ImageMagick for entries that require it?</a></li>
|
||
<li><a class="normal" href="#faq3_18">3.18 - How do I compile and install OpenGL for entries that require it?</a></li>
|
||
<li><a class="normal" href="#faq3_19">3.19 - What kind of make(1) compatibility does the IOCCC support and will it support other kinds?</a></li>
|
||
<li><a class="normal" href="#faq3_20">3.20 - How do I download individual winning entries or all winning entries of a given year?</a></li>
|
||
<li><a class="normal" href="#faq3_21">3.21 - What are <code>try.sh</code> and <code>try.alt.sh</code> scripts and why should I use them?</a></li>
|
||
<li><a class="normal" href="#faq3_22">3.22 - Are there any compiler warnings that I should not worry about?</a></li>
|
||
</ul>
|
||
<h2 id="section-4---changes-made-to-ioccc-entries">Section 4 - <a href="#faq4">Changes made to IOCCC entries</a></h2>
|
||
<ul>
|
||
<li><a class="normal" href="#faq4_0">4.0 - Why are some winning author remarks incongruent with the winning IOCCC code?</a></li>
|
||
<li><a class="normal" href="#faq4_1">4.1 - Why were some calls to the libc function gets(3) changed to use fgets(3)?</a></li>
|
||
<li><a class="normal" href="#faq4_2">4.2 - What was changed in an IOCCC entry source code?</a></li>
|
||
<li><a class="normal" href="#faq4_3">4.3 - Why do author remarks sometimes not match the source and/or why are there
|
||
other inconsistencies with the original entry?</a></li>
|
||
<li><a class="normal" href="#faq4_4">4.4 - What is the meaning of the file ending in .orig.c in IOCCC entries?</a></li>
|
||
<li><a class="normal" href="#faq4_5">4.5 - What are alternate versions and why were alternate versions added to some entries when the original entry worked fine and well?</a></li>
|
||
<li><a class="normal" href="#faq4_6">4.6 - Why was arg count and/or type changed in main() in some older entries?</a></li>
|
||
<li><a class="normal" href="#faq4_7">4.7 - Why were some filenames changed?</a></li>
|
||
<li><a class="normal" href="#faq4_8">4.8 - Why were files added or removed from some entries?</a></li>
|
||
<li><a class="normal" href="#faq4_9">4.9 - What is the original source file?</a></li>
|
||
</ul>
|
||
<h2 id="section-5---helping-the-ioccc">Section 5 - <a href="#faq5">Helping the IOCCC</a></h2>
|
||
<ul>
|
||
<li><a class="normal" href="#faq5_0">5.0 - How may I help the IOCCC?</a></li>
|
||
<li><a class="normal" href="#faq5_1">5.1 - How do I report a bug in an IOCCC entry?</a></li>
|
||
<li><a class="normal" href="#faq5_2">5.2 - How may I submit a fix to an IOCCC entry?</a></li>
|
||
<li><a class="normal" href="#faq5_3">5.3 - How may I report an IOCCC website problem?</a></li>
|
||
<li><a class="normal" href="#faq5_4">5.4 - How may I submit a fix to the IOCCC website?</a></li>
|
||
<li><a class="normal" href="#faq5_5">5.5 - How may I correct or update IOCCC author information?</a></li>
|
||
<li><a class="normal" href="#faq5_6">5.6 - What should I do if I find a broken or wrong web link?</a></li>
|
||
<li><a class="normal" href="#faq5_7">5.7 - How may I support the IOCCC?</a></li>
|
||
<li><a class="normal" href="#faq5_8">5.8 - I deobfuscated some entry code, may I contribute the source?</a></li>
|
||
</ul>
|
||
<h2 id="section-6---miscellaneous-ioccc">Section 6 - <a href="#faq6">Miscellaneous IOCCC</a></h2>
|
||
<ul>
|
||
<li><a class="normal" href="#faq6_0">6.0 - How did an entry that breaks the size rule 2 win the IOCCC?</a></li>
|
||
<li><a class="normal" href="#faq6_1">6.1 - Is there a list of known bugs and (mis)features of IOCCC entries?</a></li>
|
||
<li><a class="normal" href="#faq6_2">6.2 - May I mirror the IOCCC website?</a></li>
|
||
<li><a class="normal" href="#faq6_3">6.3 - May I use parts of the IOCCC in an article, book, newsletter, or instructional material?</a></li>
|
||
<li><a class="normal" href="#faq6_4">6.4 - Why do you sometimes use the first person plural?</a></li>
|
||
<li><a class="normal" href="#faq6_5">6.5 - What is an <code>author handle</code>?</a></li>
|
||
<li><a class="normal" href="#faq6_6">6.6 - What is an <code>author_handle.json</code> file and how are they used?</a></li>
|
||
<li><a class="normal" href="#faq6_7">6.7 - What is an <code>entry_id</code>?</a></li>
|
||
<li><a class="normal" href="#faq6_8">6.8 - What is the purpose of the .top, .allyear, .year and .path files?</a></li>
|
||
<li><a class="normal" href="#faq6_9">6.9 - What is the current meaning of the IOCCC terms Author, Entry, and Submission?</a></li>
|
||
<li><a class="normal" href="#faq6_10">6.10 - How does someone make a change to a file and submit that change as a GitHub pull request?</a></li>
|
||
<li><a class="normal" href="#faq6_11">6.11 - Am I allowed to use IOCCC content?</a></li>
|
||
<li><a class="normal" href="#faq6_12">6.12 - What is Mastodon and why does IOCCC use it?</a></li>
|
||
<li><a class="normal" href="#faq6_13">6.13 - How may I find my author handle?</a></li>
|
||
<li><a class="normal" href="#faq6_14">6.14 - How do I set certain tabstops for viewing source code in vi(m)?</a></li>
|
||
<li><a class="normal" href="#faq6_15">6.15 - How do the menus on the website work and what can I do if they don’t work?</a></li>
|
||
<li><a class="normal" href="#faq6_16">6.16 - How do I find more information about a winning author of an entry?</a></li>
|
||
<li><a class="normal" href="#faq6_17">6.17 - What is a <code>.entry.json</code> file and how is it used?</a></li>
|
||
<li><a class="normal" href="#faq6_18">6.18 - I do not understand the IOCCC, can you explain it to me?</a></li>
|
||
</ul>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<h1 id="the-ioccc-faq">The IOCCC FAQ</h1>
|
||
<div id="faq0">
|
||
<h2 id="section-0-submitting-entries-to-a-new-ioccc">Section 0: Submitting entries to a new IOCCC</h2>
|
||
</div>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_0">
|
||
<div id="submit">
|
||
<div id="register">
|
||
<h3 id="faq-0.0-how-may-i-enter-the-ioccc">FAQ 0.0: How may I enter the IOCCC?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>To submit your code to the IOCCC, you <strong>MUST</strong> follow these steps:</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<h4 id="verify-that-the-ioccc-is-open-for-submissions">0. Verify that the IOCCC is open for submissions</h4>
|
||
<p>Check the <a href="status.html">current status of the IOCCC</a> see of the IOCCC is open.</p>
|
||
<p>You may <strong>only register for the IOCCC when the IOCCC is OPEN</strong>.</p>
|
||
<p>You may <strong>only submit your entries to the IOCCC when the IOCCC is OPEN</strong>.</p>
|
||
<p>See also the <a href="news.html#news">IOCCC news</a> for more information.</p>
|
||
<h4 id="read-the-latest-ioccc-rules-and-review-the-ioccc-guidelines">1. Read the latest IOCCC rules and review the IOCCC guidelines</h4>
|
||
<p>Please pay close attention to the <a href="next/rules.html">official IOCCC rules</a>.</p>
|
||
<p>You are also <strong>highly encouraged</strong> to review the
|
||
<a href="next/guidelines.html">official IOCCC guidelines</a> as they contain important
|
||
suggestions, useful hints, and IOCCC humor. :-)</p>
|
||
<h4 id="register-for-the-ioccc">2. Register for the IOCCC</h4>
|
||
<p>The <strong>IOCCC registration procedure</strong> is still being designed.
|
||
<!--XXX--> As such, we do not yet have instructions on how to
|
||
use the <strong>IOCCC registration procedure</strong>. Once <strong>IOCCC
|
||
registration procedure</strong> is ready, we will update this section
|
||
with the proper instructions. Watch the <a href="news.html">IOCCC news</a>
|
||
for an announcement about the <strong>IOCCC registration procedure</strong>.</p>
|
||
<p>Once you have been registered, you will receive an email message for how to
|
||
prepare your entries for submission, and how to upload the compressed tarballs
|
||
to our submission portal.</p>
|
||
<h4 id="obtain-the-latest-mkiocccentry-toolkit">3. Obtain the latest mkiocccentry toolkit</h4>
|
||
<p>If you do not have an mkiocccentry tool directory:</p>
|
||
<div class="sourceCode" id="cb1"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a> <span class="bu">cd</span> some_directory</span>
|
||
<span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a> <span class="fu">git</span> clone git@github.com:ioccc-src/mkiocccentry.git</span>
|
||
<span id="cb1-3"><a href="#cb1-3" aria-hidden="true" tabindex="-1"></a> <span class="bu">cd</span> mkiocccentry</span></code></pre></div>
|
||
<p>If you already have an mkiocccentry tool directory:</p>
|
||
<div class="sourceCode" id="cb2"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a> <span class="bu">cd</span> mkiocccentry</span>
|
||
<span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a> <span class="fu">git</span> fetch</span>
|
||
<span id="cb2-3"><a href="#cb2-3" aria-hidden="true" tabindex="-1"></a> <span class="fu">git</span> rebase</span></code></pre></div>
|
||
<h4 id="make-the-mkiocccentry-toolkit">4. Make the mkiocccentry toolkit</h4>
|
||
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a> <span class="fu">make</span> clobber all</span></code></pre></div>
|
||
<h4 id="run-the-mkiocccentry-tool-to-form-your-submission-tarball">5. Run the mkiocccentry tool to form your submission tarball</h4>
|
||
<div class="sourceCode" id="cb4"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a> <span class="ex">mkiocccentry</span> work_dir prog.c Makefile remarks.md [file ...]</span></code></pre></div>
|
||
<p>where:</p>
|
||
<ul>
|
||
<li><p>work_dir</p>
|
||
<p>directory where the entry directory and tarball are formed</p></li>
|
||
<li><p>prog.c</p>
|
||
<p>path to the C source for your entry</p></li>
|
||
<li><p>Makefile</p>
|
||
<p>Makefile to build (make all) and cleanup (make clean & make clobber)</p></li>
|
||
<li><p>remarks.md</p>
|
||
<p>Remarks about your entry in markdown format: see the
|
||
FAQ on “<a href="#remarks_md">remarks.md</a>”
|
||
for more info.</p></li>
|
||
<li><p>[file …]</p>
|
||
<p>Optional extra data files to include with your entry</p></li>
|
||
</ul>
|
||
<p><strong>NOTE</strong>: Please see our <a href="markdown.html">IOCCC markdown guide</a> for <strong>important information</strong> on using markdown in the IOCCC.</p>
|
||
<p><strong>NOTE</strong>: It is <em>NOT</em> necessary to install the tools to use them as you can run
|
||
the tools from the top of the <code>mkiocccentry</code> repo directory just fine. However,
|
||
installing it will make it easier for you as you can run it from your
|
||
submission’s directory.</p>
|
||
<p>If the <code>mkiocccentry</code> tool indicates that there is a problem with your entry,
|
||
especially if it identifies a <a href="next/rules.html#rule2">Rule 2</a> related problem,
|
||
you are <strong>strongly</strong> encouraged to revise and correct your entry and
|
||
then re-run the <code>mkiocccentry</code> tool.</p>
|
||
<p>If you choose to risk violating rules, be sure an explain your reason
|
||
for doing so in your <code>remarks.md</code> file.</p>
|
||
<p>See also <a href="next/rules.html#rule17">Rule 17</a>!</p>
|
||
<h4 id="upload-your-entry-to-the-ioccc-submit-server">6. Upload your entry to the IOCCC submit server</h4>
|
||
<p>The <strong>IOCCC submit server</strong> is still being written.
|
||
<!--XXX--> As such, we do not yet have instructions
|
||
on how upload your entry to the <strong>IOCCC submit server</strong>. Once
|
||
<strong>IOCCC submit server</strong> is ready, we will update this section
|
||
with the proper instructions. Watch the <a href="news.html">IOCCC news</a>
|
||
for an announcement of the availability of the <strong>IOCCC submit server</strong>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_1">
|
||
<div id="frequent-themes">
|
||
<h3 id="faq-0.1-what-types-of-entries-have-been-frequently-submitted-to-the-ioccc">FAQ 0.1: What types of entries have been frequently submitted to the IOCCC?</h3>
|
||
</div>
|
||
</div>
|
||
<p>There are types of entries that are frequently submitted to the IOCCC.
|
||
While we <strong>do not wish to prevent</strong> people from sending
|
||
a submission to the IOCCC on a frequently submitted theme,
|
||
we do wish to provide a <strong>fair warning</strong> to those who do.</p>
|
||
<h4 id="fair-warnings-on-frequently-submitted-themes">Fair warnings on frequently submitted themes:</h4>
|
||
<p><strong>IMPORTANT HINT</strong>: It is <strong>not fatal</strong> to send in those types of
|
||
entries, it is just <strong>HARDER to win</strong> with such a submission. A
|
||
submission on a frequently submitted theme will have to do something
|
||
in a <strong>really unique AND interesting way</strong> to even make it into the
|
||
final judging rounds. It will have to compete with previous IOCCC
|
||
winners based on the same theme.</p>
|
||
<p><strong>IMPORTANT HINT</strong>: If you really wish send in a submission on a
|
||
frequently submitted theme, be sure that it is obfuscated in several
|
||
new and novel ways.</p>
|
||
<p><strong>IMPORTANT HINT</strong>: Be sure to <strong>clearly explain</strong> near the beginning
|
||
of your <code>remarks.md</code> file, see the
|
||
FAQ on “<a href="#remarks_md">remarks.md</a>”,
|
||
<strong>why you are submitting a entry based on a frequently
|
||
submitted theme</strong> and <strong>how compares with previous IOCCC winners</strong>
|
||
of the same theme.</p>
|
||
<h4 id="examples-of-frequently-submitted-themes">Examples of frequently submitted themes</h4>
|
||
<h5 id="maze-generator">Maze generator</h5>
|
||
<ul>
|
||
<li><a href="1985/shapiro/index.html">1985/shapiro</a></li>
|
||
<li><a href="1991/buzzard/index.html">1991/buzzard</a></li>
|
||
<li><a href="1995/cdua/index.html">1995/cdua</a></li>
|
||
<li><a href="1995/dodsond2/index.html">1995/dodsond2</a></li>
|
||
<li><a href="1998/bas1/index.html">1998/bas1</a></li>
|
||
</ul>
|
||
<h5 id="tic-tac-toenoughts-and-crossesxs-and-os-game">Tic-Tac-Toe/Noughts and Crosses/Xs and Os game</h5>
|
||
<ul>
|
||
<li><a href="1991/westley/index.html">1991/westley</a></li>
|
||
<li><a href="1996/jonth/index.html">1996/jonth</a></li>
|
||
<li><a href="2020/carlini/index.html">2020/carlini</a></li>
|
||
</ul>
|
||
<h5 id="solitaireothello-game">Solitaire/Othello game</h5>
|
||
<ul>
|
||
<li><a href="1987/lievaart/index.html">1987/lievaart</a></li>
|
||
<li><a href="1994/dodsond1/index.html">1994/dodsond1</a></li>
|
||
</ul>
|
||
<h5 id="generating-small-primes-below-is-the-list-of-all-prime-related-winning-entries">Generating small primes (below is the list of all prime related winning entries)</h5>
|
||
<ul>
|
||
<li><a href="1985/august/index.html">1985/august</a></li>
|
||
<li><a href="1988/applin/index.html">1988/applin</a></li>
|
||
<li><a href="1994/weisberg/index.html">1994/weisberg</a></li>
|
||
<li><a href="1995/makarios/index.html">1995/makarios</a></li>
|
||
<li><a href="1996/dalbec/index.html">1996/dalbec</a></li>
|
||
<li><a href="2000/bellard/index.html">2000/bellard</a></li>
|
||
</ul>
|
||
<h5 id="self-reproducing-program">Self-reproducing program</h5>
|
||
<ul>
|
||
<li><a href="1990/scjones/index.html">1990/scjones</a></li>
|
||
<li><a href="1994/smr/index.html">1994/smr</a> - <em>do not claim your program is the smallest without seeing this entry</em>!</li>
|
||
<li><a href="2000/dhyang/index.html">2000/dhyang</a> - <em>this entry set a high bar for entries of this theme</em></li>
|
||
</ul>
|
||
<h5 id="entries-that-just-print-hello-world">Entries that just print “Hello, world!”</h5>
|
||
<ul>
|
||
<li><a href="1984/anonymous/index.html">1984/anonymous</a></li>
|
||
<li><a href="1985/applin/index.html">1985/applin</a></li>
|
||
<li><a href="1986/applin/index.html">1986/applin</a></li>
|
||
<li><a href="1986/holloway/index.html">1986/holloway</a></li>
|
||
<li><a href="1989/jar.1/index.html">1989/jar.1</a></li>
|
||
<li><a href="1992/lush/index.html">1992/lush</a></li>
|
||
<li><a href="2000/tomx/index.html">2000/tomx</a></li>
|
||
</ul>
|
||
<h5 id="entries-that-use-some-complex-state-machinetable-to-print-something">Entries that use some complex state machine/table to print something</h5>
|
||
<ul>
|
||
<li><a href="1988/isaak/index.html">1988/isaak</a></li>
|
||
<li><a href="1988/phillipps/index.html">1988/phillipps</a></li>
|
||
<li><a href="2018/ciura/index.html">2018/ciura</a></li>
|
||
<li><a href="2018/giles/index.html">2018/giles</a></li>
|
||
</ul>
|
||
<h5 id="rot13">ROT13</h5>
|
||
<ul>
|
||
<li><a href="1985/sicherman/index.html">1985/sicherman</a></li>
|
||
<li><a href="1989/westley/index.html">1989/westley</a></li>
|
||
<li><a href="1990/dg/index.html">1990/dg</a></li>
|
||
<li><a href="1991/fine/index.html">1991/fine</a></li>
|
||
</ul>
|
||
<h5 id="pi-or-e-computation"><strong>pi</strong> or <strong>e</strong> computation</h5>
|
||
<ul>
|
||
<li><a href="1986/august/index.html">1986/august</a></li>
|
||
<li><a href="1988/robison/index.html">1988/robison</a></li>
|
||
<li><a href="1988/westley/index.html">1988/westley</a></li>
|
||
<li><a href="1989/roemer/index.html">1989/roemer</a></li>
|
||
</ul>
|
||
<h4 id="the-above-list-of-frequently-submitted-themes-is-not-exhaustive">The above list of frequently submitted themes is not exhaustive</h4>
|
||
<h4 id="some-final-thoughts-on-frequently-used-themes">Some final thoughts on frequently used themes</h4>
|
||
<p>While it is possible to win a new IOCCC with one of these
|
||
<strong>frequently submitted</strong> types of entries, level of the competition from
|
||
previous IOCCC entries make it more challenging to be successful.</p>
|
||
<p>It is also important to note that the <a href="next/guidelines.html">guidelines</a> often
|
||
state something along the lines of:</p>
|
||
<pre><code> We tend to dislike programs that: are similar to previous winning entries.</code></pre>
|
||
<p><strong>FAIR WARNING</strong>: Be sure to <strong>clearly explain</strong> near the beginning
|
||
of your <code>remarks.md</code> file, see the
|
||
FAQ on “<a href="#remarks_md">remarks.md</a>”,
|
||
<strong>why you are submitting a entry based on a frequently
|
||
submitted theme</strong> and <strong>how compares with previous IOCCC winners</strong>
|
||
of the same theme.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_2">
|
||
<div id="makefile">
|
||
<div id="submission_makefile">
|
||
<h3 id="faq-0.2-what-should-i-put-in-my-submissions-makefile">FAQ 0.2: What should I put in my submission’s Makefile?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>We recommend starting with the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example">sample
|
||
Makefile</a>
|
||
as found in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry GitHub repo</a>,
|
||
(renamed as <code>Makefile</code> of course) as a starting point for your
|
||
entry’s <code>Makefile</code>.</p>
|
||
<p>The <code>Makefile</code> is a file used by the <code>make(1)</code> command that contains
|
||
rules and UNIX shell-style commands.</p>
|
||
<p>The first and default rule should be the <code>all</code> rule and should build your entry’s executable file.</p>
|
||
<p>If your entry depends on a particular source file name during compilation or execution,
|
||
your <code>Makefile</code> should copy <code>prog.c</code> into the desired filename. For example:</p>
|
||
<p>If you are not familiar <code>Makefile</code>s, you might consider the following tutorials:</p>
|
||
<ul>
|
||
<li><a href="https://www.gnu.org/software/make/manual/make.html#Introduction">GNU make</a></li>
|
||
<li><a href="https://opensource.com/article/18/8/what-how-makefile">What is a Makefile and how does it work?</a></li>
|
||
<li><a href="https://makefiletutorial.com">Learn Makefiles</a></li>
|
||
</ul>
|
||
<p>For the <code>make(1)</code> <em>connoisseur</em>: As of 2023, IOCCC judges use <a href="https://www.gnu.org/software/make/">GNU
|
||
make compatible</a> <code>make(1)</code>
|
||
command that is compatible with GNU Make version 3.81.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_3">
|
||
<div id="prog">
|
||
<h3 id="faq-0.3-may-i-use-a-different-source-or-compiled-filename-than-prog.c-or-prog">FAQ 0.3: May I use a different source or compiled filename than prog.c or prog?</h3>
|
||
</div>
|
||
</div>
|
||
<p>While your entry’s source filename, as submitted, must be <code>prog.c</code>, your entry’s <code>Makefile</code>
|
||
may copy <code>prog.c</code> to a different filename as part of the compiling/building process. For example:</p>
|
||
<pre><code> ... Makefile continues above ...
|
||
|
||
all: desired_name
|
||
|
||
desired_name: desired_name.c
|
||
rm -f $@
|
||
cc desired_name.c -o $@
|
||
|
||
desired_name.c: prog.c
|
||
rm -f $@
|
||
cp -f prog.c $@
|
||
|
||
clean:
|
||
rm -f desired_name.o
|
||
|
||
clobber: clean
|
||
rm -f desired_name.c desired_name
|
||
|
||
... Makefile continues below ...</code></pre>
|
||
<p>We recommend that the <code>make clobber</code> rule remove files that your entry
|
||
creates as part of the compiling/building process.</p>
|
||
<p>You may also copy the compiled <code>prog</code> into a different file as part of compiling process.
|
||
For example:</p>
|
||
<pre><code> ... Makefile continues above ...
|
||
|
||
all: desired_name
|
||
|
||
different_name: prog
|
||
rm -f $@
|
||
cp -f prog $@
|
||
|
||
clean:
|
||
rm -f prog.o
|
||
|
||
clobber: clean
|
||
rm -f desired_name
|
||
|
||
... Makefile continues below ...</code></pre>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_4">
|
||
<div id="SUS">
|
||
<div id="platform">
|
||
<div id="portability">
|
||
<h3 id="faq-0.4-what-platform-should-i-assume-for-my-submission">FAQ 0.4: What platform should I assume for my submission?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>Your entry must compile with <strong>clang</strong> or <strong>gcc</strong> and run under at least one flavor of a UNIX
|
||
system that conforms to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">SUS</a>,
|
||
otherwise known as the <a href="https://unix.org/version4/">The Single UNIX Specification Version 4</a>
|
||
or <a href="https://unix.org/online.html">later SUS</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_5">
|
||
<div id="feedback">
|
||
<div id="comments">
|
||
<h3 id="faq-0.5-how-may-i-comment-or-make-a-suggestion-on-ioccc-rules-guidelines-and-tools">FAQ 0.5: How may I comment or make a suggestion on IOCCC rules, guidelines and tools?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>The <a href="judges.html">IOCCC judges</a> to welcome feedback on the <a href="next/rules.html">IOCCC
|
||
rules</a>, <a href="next/guidelines.html">IOCCC guidelines</a>
|
||
and on the <a href="https://github.com/ioccc-src/mkiocccentry">IOCCC mkiocccentry tools</a>.</p>
|
||
<p>To comment on the <a href="next/rules.html">IOCCC rules</a> or the
|
||
<a href="next/guidelines.html">IOCCC guidelines</a> please view the
|
||
<a href="https://github.com/ioccc-src/winner/discussions">GitHub discussions for this repo</a>.
|
||
If there is an on-going discussion that seems relevant to what you
|
||
have to say, consider adding comments to that particular discussion.
|
||
Otherwise consider opening a <a href="https://github.com/ioccc-src/winner/discussions/new/choose">new IOCCC repo
|
||
discussion</a>.</p>
|
||
<p>To comment on <a href="https://github.com/ioccc-src/mkiocccentry">IOCCC mkiocccentry tools</a>,
|
||
please view the <a href="https://github.com/ioccc-src/mkiocccentry/discussions">mkiocccentry repo discussions</a>.
|
||
If there is an on-going discussion that seems relevant to what you
|
||
have to say, consider adding comments to that particular discussion.
|
||
Otherwise consider opening a <a href="https://github.com/ioccc-src/mkiocccentry/discussions/new/choose">new mkiocccentry
|
||
discussion</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_6">
|
||
<div id="question">
|
||
<div id="questions">
|
||
<h3 id="faq-0.6-what-is-the-best-way-to-ask-a-question-about-the-ioccc-rules-guideline-and-tools">FAQ 0.6: What is the best way to ask a question about the IOCCC rules, guideline and tools?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>We realise that the <a href="next/rules.html">IOCCC rules</a>, <a href="next/guidelines.html">IOCCC guidelines</a>
|
||
and the <a href="https://github.com/ioccc-src/mkiocccentry">IOCCC mkiocccentry tools</a>
|
||
can be confusing or even seem overwhelming to some people.</p>
|
||
<p>The <a href="judges.html">IOCCC judges</a> to welcomes questions about the IOCCC
|
||
and will be <strong>happy to help</strong>.</p>
|
||
<p>Chances are, if you have a question, there are a number of other people who
|
||
have similar questions. So we recommend first view the
|
||
<a href="https://github.com/ioccc-src/winner/discussions">GitHub discussions for this repo</a>
|
||
so see if someone else asked already. Feel free to join in on such a discussion,
|
||
even if to just say:</p>
|
||
<blockquote>
|
||
<p>I have this question too.</p>
|
||
</blockquote>
|
||
<p>Feel free to provide additional feedback in the existing discussion as needed.</p>
|
||
<p><strong>BTW</strong>: If your question just about the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">IOCCC mkiocccentry tools</a>, please
|
||
view the <a href="https://github.com/ioccc-src/mkiocccentry/discussions">mkiocccentry repo discussions</a>
|
||
instead.</p>
|
||
<p>If you do not find an suitable open discussion, please consider opening a
|
||
<a href="https://github.com/ioccc-src/winner/discussions/new/choose">new IOCCC repo discussion</a> with
|
||
your question. Doing this may be of help to others with a question similar to yours.</p>
|
||
<p><strong>BTW</strong>: If your question just about the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/discussions">IOCCC mkiocccentry tools</a>, please
|
||
and suitable open discussion over there, then please consider opening a
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/discussions/new/choose">new mkiocccentry discussion</a>
|
||
over there.</p>
|
||
<p>If you do not feel, for some reason, comfortable asking your question in public
|
||
(although we hope you consider asking it in public for the benefit of others),
|
||
then use the <a href="contact.html">How to contact the IOCCC</a> information to ask
|
||
a private question.</p>
|
||
<p><strong>IMPORTANT</strong>: When you ask your question (in public or as a private question)
|
||
<strong>PLEASE</strong> try to <strong>NOT</strong> discuss detailed information about any pending submission.
|
||
Try to ask for question in a more generic way as this will help others
|
||
with a similar question and this will not <strong>give away</strong> what you might be doing
|
||
with your submission. If the <a href="judges.html">IOCCC judges</a> truly need more
|
||
information, they will ask (either in public or suggest a private conversation).</p>
|
||
<p>Again, <strong>please</strong> don’t hesitate to ask: Your question may be something that
|
||
others are wondering about as well!</p>
|
||
<p>See also the
|
||
FAQ on “<a href="#feedback">rules, guidelines, tools feedback</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_7">
|
||
<div id="markdown">
|
||
<div id="md">
|
||
<h3 id="faq-0.7---what-are-the-ioccc-best-practices-for-using-markdown">FAQ 0.7: - What are the IOCCC best practices for using markdown?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>The IOCCC makes extensive use of <a href="https://daringfireball.net/projects/markdown/">markdown</a>.
|
||
For example, we <a href="#submit">submitting to the IOCCC</a>, we have people
|
||
to submit remarks about entry in markdown format. Every
|
||
<a href="years.html">winning IOCCC entry</a> uses a <code>README.md</code> markdown file
|
||
as the basis for forming the <code>index.html</code> web page for that entry.
|
||
All generated HTML pages on the <a href="https://www.ioccc.org/index.html">Official IOCCC website</a>
|
||
start with some markdown content.</p>
|
||
<p><strong>IMPORTANT</strong>: Please read the <a href="markdown.html">IOCCC markdown best practices</a> guide
|
||
as it lists things you <strong>should not use</strong> in markdown files.</p>
|
||
<p>See the <a href="https://www.markdownguide.org/basic-syntax">markdown syntax</a> guide.
|
||
See also <a href="https://spec.commonmark.org/current/">CommonMark Spec</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_8">
|
||
<div id="mkiocccentry_bugs">
|
||
<h3 id="faq-0.8-how-do-i-report-bugs-in-a-mkiocccentry-tool">FAQ 0.8: How do I report bugs in a <code>mkiocccentry</code> tool?</h3>
|
||
</div>
|
||
</div>
|
||
<p>As the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a> is
|
||
crucial in the contest, both for submitters and the judges, if you find a bug
|
||
(or you think you find a bug) we would be grateful if you were to report it at
|
||
the <a href="https://github.com/ioccc-src/mkiocccentry/issues">mkiocccentry issues
|
||
page</a>.</p>
|
||
<p>Please see the
|
||
FAQ on “<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/FAQ.md#bugs">reporting bugs and other issues in the mkiocccentry repo</a>”
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_9">
|
||
<div id="auth_json">
|
||
<h3 id="faq-0.9-what-is-a-.auth.json-file">FAQ 0.9: What is a <code>.auth.json</code> file?</h3>
|
||
</div>
|
||
</div>
|
||
<p>This file is constructed by the <code>mkiocccentry(1)</code> <strong>prior to</strong> forming the xz
|
||
compressed tarball of your submission. The <code>.auth.json</code> file contains
|
||
information about the author or authors of the submission, in JSON format.</p>
|
||
<p>In order of the file’s contents we describe each required field, below:</p>
|
||
<ul>
|
||
<li><code>no_comment</code> (double quoted string)
|
||
<ul>
|
||
<li>We can provide <code>no comment</code> about <code>no_comment</code> other than to state that unless
|
||
<code>no_comment</code> matches this quote:</li>
|
||
</ul></li>
|
||
</ul>
|
||
<blockquote>
|
||
<p>“mandatory comment: because comments were removed from the original JSON spec”</p>
|
||
</blockquote>
|
||
<p>your submission <strong>WILL BE</strong> rejected!</p>
|
||
<p>Are we suggesting that removing comments from the JSON spec was a mistake?</p>
|
||
<blockquote>
|
||
<p>“You might very well think that; but of course I couldn’t possibly comment.” – Francis Urquhart</p>
|
||
</blockquote>
|
||
<ul>
|
||
<li><p><code>IOCCC_auth_version</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The current version of the <code>.auth.json</code> file.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s <code>.auth.json</code> version, defined as
|
||
<code>AUTH_VERSION</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/version.h">soup/version.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>IOCCC_contest</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>Which contest number this is (e.g. 1 for 1984, 2 for 1985, 27 for 2020).</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s contest value, defined as
|
||
<code>IOCCC_CONTEST</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>IOCCC_year</code> (number)</p>
|
||
<ul>
|
||
<li>The year this contest was run in.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> sometimes an IOCCC year runs into another year and the contest year
|
||
might not match when it ends.</p>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s contest, defined as
|
||
<code>IOCCC_YEAR</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>mkiocccentry_version</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The version of <code>mkiocccentry</code> that formed this <code>.auth.json</code> file.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s <code>mkiocccentry</code> version,
|
||
defined as <code>MKIOCCCENTRY_VERSION</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/version.h">soup/version.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>chkentry_version</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The version of <code>chkentry</code> that was used to validate this <code>.auth.json</code>,
|
||
assuming that it was created by <code>mkiocccentry</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s <code>chkentry</code> version, defined
|
||
as <code>CHKENTRY_VERSION</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/version.h">soup/version.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>fnamchk_version</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The version of <code>fnamchk</code> that <code>txzchk</code> uses to validate the filename of
|
||
the xz compressed tarball.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s <code>fnamchk</code> version in order for it
|
||
to be valid. If this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>IOCCC_contest_id</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The IOCCC contestant ID used as a username in the form of <strong>in the form of
|
||
a UUID</strong> and submission number; see the <a href="next/rules.html">Rules</a> for more details
|
||
on this, and in particular <a href="next/rules.html#rule17">Rule 17</a>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if the contest ID is <strong>NOT</strong> in this format then <code>fnamchk</code> will
|
||
report it as an <strong>error</strong> and your submission <strong>WILL BE</strong> rejected for
|
||
violating <a href="next/rules.html#rule17">Rule 17</a>!</p></li>
|
||
<li><p><code>tarball</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The xz compressed tarball filename.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match the actual tarball’s <strong>filename</strong> in order for
|
||
this to be valid. If there is a mismatch you stand a great risk of having
|
||
your submission rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!
|
||
Moreover, it is possible that <code>txzchk</code> will report a problem through
|
||
<code>fnamchk(1)</code> which also puts you at great risk of violating <a href="next/rules.html#rule17">Rule
|
||
17</a>. If <code>txzchk</code> does not detect this, though, it
|
||
does not mean it’s a bug but rather that the directory in the tarball
|
||
matches the filename.</p></li>
|
||
<li><p><code>submit_slot</code> (number)</p>
|
||
<ul>
|
||
<li>The submission number.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> be within the range of 0 <strong>THROUGH</strong>
|
||
<code>MAX_SUBMIT_SLOT</code> (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>). If
|
||
this is not the case you stand a great risk of having your submission
|
||
rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p></li>
|
||
<li><p><code>author_count</code> (number)</p>
|
||
<ul>
|
||
<li>How many authors this submission has.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> be within the range of 1 <strong>THROUGH</strong>
|
||
<code>MAX_AUTHORS</code> (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>). If
|
||
this is not the case you stand a great risk of having your submission
|
||
rejected for violating the <a href="next/rules.html">Rules</a>! Moreover, if the
|
||
<code>author_count</code> is inconsitent with how many authors are in the <code>authors</code>
|
||
array your submission <strong>will be</strong> invalid.</p></li>
|
||
<li><p><code>test_mode</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if the <code>test</code> ID was used to form the tarball, else <code>false</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if <code>true</code> then this may <strong>NOT</strong> be submitted to the contest! Please do
|
||
<strong>NOT</strong> email the <a href="judges.html">Judges</a> your submission!</p></li>
|
||
</ul>
|
||
<p>Next, the JSON <code>authors</code> <strong>array</strong> holds the following information about the
|
||
author(s) of the submission:</p>
|
||
<ul>
|
||
<li><p><code>name</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The <strong>name</strong> of this author.</li>
|
||
</ul></li>
|
||
<li><p><code>location_code</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The <strong>location code</strong> of this author (an ISO 3166-1 2 character code).
|
||
See
|
||
<a href="https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Officially_assigned_code_elements" class="uri">https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Officially_assigned_code_elements</a>
|
||
for a list of valid codes.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> in <code>mkiocccentry</code> use <code>XX</code> if you want your location to be anonymous.</p></li>
|
||
<li><p><code>email</code> (<code>null</code> or double quoted string)</p>
|
||
<ul>
|
||
<li>The <strong>email</strong> of this author in the form of <code>x@y</code>, or <code>null</code> if not provided.</li>
|
||
</ul></li>
|
||
<li><p><code>url</code> (<code>null</code> or double quoted string)</p>
|
||
<ul>
|
||
<li>The primary <strong>URL</strong> of this author, or <code>null</code> if not provided.</li>
|
||
</ul></li>
|
||
<li><p><code>alt_url</code> (<code>null</code> or double quoted string)</p>
|
||
<ul>
|
||
<li>The <strong>alt URL</strong> of this author, or <code>null</code> if not provided.</li>
|
||
</ul></li>
|
||
<li><p><code>mastodon</code> (<code>null</code> or double quoted string)</p>
|
||
<ul>
|
||
<li>The Mastodon handle of this author in the form of <code>@user@domain</code>, or
|
||
<code>null</code> if not provided. See the
|
||
FAQ on “<a href="#try_mastodon">Mastodon</a>”
|
||
for more information.</li>
|
||
</ul></li>
|
||
<li><p><code>github</code> (<code>null</code> or double quoted string)</p>
|
||
<ul>
|
||
<li>The <strong><a href="https://github.com">GitHub</a> account</strong> of this author in the form of <code>@user</code>, or <code>null</code> if not
|
||
provided.</li>
|
||
</ul></li>
|
||
<li><p><code>affiliation</code> (<code>null</code> or double quoted string)</p>
|
||
<ul>
|
||
<li>This author’s <strong>affiliation</strong>, if any, or <code>null</code> if not provided.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if provided, the length of the <strong>affiliation</strong> <strong>MUST</strong> be within
|
||
the range of 1 <strong>THROUGH</strong> <code>MAX_AFFILIATION_LEN</code> (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>). If
|
||
this is not the case you stand a great risk of having your submission
|
||
rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p>
|
||
<p><strong>NOTE:</strong> an <strong>affiliation</strong> does <strong>NOT</strong> have any affect on whether you will win or not.</p></li>
|
||
<li><p><code>past_winning_author</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if this author claims to have won a past IOCCC, <code>false</code> if this
|
||
author has <strong>NOT</strong> won before.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this has <strong>NO</strong> effect on whether you will win or not.</p></li>
|
||
<li><p><code>default_handle</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if this default handle was accepted, <code>false</code> if one is provided
|
||
by this author.</li>
|
||
</ul></li>
|
||
<li><p><code>author_handle</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>This author’s handle (custom or default provided).</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if you have won before, we <strong>ENCOURAGE</strong> you to use the same handle of
|
||
your previous winning entries, to help in organising the
|
||
<a href="authors.html">authors.html</a> page and the author JSON file.
|
||
See the
|
||
FAQ on “<a href="#author_handle_faq">author handle</a>”
|
||
and the
|
||
FAQ on “<a href="#author_json">author_handle.json</a>”
|
||
for more information.</p></li>
|
||
<li><p><code>author_number</code> (number)</p>
|
||
<ul>
|
||
<li>This author number in the <code>authors</code> array.</li>
|
||
</ul></li>
|
||
</ul>
|
||
<p>After the <code>authors</code> <strong>array</strong> the remaining of a <code>.auth.json</code> file holds:</p>
|
||
<ul>
|
||
<li><p><code>formed_timestamp</code> (number)</p>
|
||
<ul>
|
||
<li>Seconds since epoch when <code>.auth.json</code> was formed (see <code>gettimeofday(2)</code>). See also the
|
||
FAQ on “<a href="#info_json">.info.json</a>”
|
||
for more information.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> be greater than or equal to <code>MIN_TIMESTAMP</code> (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>). If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected.</p></li>
|
||
<li><p><code>formed_timestamp_usec</code> (number)</p>
|
||
<ul>
|
||
<li>Microseconds since the tstamp (seconds since epoch when <code>.auth.json</code> was
|
||
formed - see <code>gettimeofday(2)</code>) second.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> be within the range <code>MIN_FORMED_TIMESTAMP_USEC</code>
|
||
<strong>THROUGH</strong> <code>MAX_FORMED_TIMESTAMP_USEC</code> and is validated by
|
||
<code>test_formed_timestamp_usec()</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/entry_util.c">soup/entry_util.c</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case <code>chkentry(1)</code> will report an <strong>error</strong> and your
|
||
submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>timestamp_epoch</code> (double quoted string)</p>
|
||
<ul>
|
||
<li><code>"Thu Jan 01 00:00:00 1970 UTC"</code> (<code>gettimeofday(2)</code> epoch).</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> be <code>"Thu Jan 01 00:00:00 1970 UTC"</code> which is <code>#define</code>d
|
||
as <code>TIMESTAMP_EPOCH</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>min_timestamp</code> (number)</p>
|
||
<ul>
|
||
<li>Minimum number of second since epoch for <strong>this</strong> IOCCC.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> be >= <code>MIN_TIMESTAMP</code> defined in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
</ul>
|
||
<p>This file will be verified with the <code>chkentry(1)</code> tool and if there are any
|
||
problems <strong>it is an error</strong>. If there is an error the tarball will <strong>NOT</strong> be
|
||
formed by <code>mkiocccentry</code>; otherwise the <code>txzchk(1)</code> tool will be executed on the
|
||
tarball.</p>
|
||
<p>This file will <strong>NOT</strong> be looked at unless the submission wins! Nonetheless,
|
||
<code>chkentry(1)</code> <strong>WILL BE</strong> used on the file as part of the judging process.</p>
|
||
<p>At the risk of stating the obvious, if your <code>.auth.json</code> file is invalid JSON or
|
||
is reported invalid by <code>chkentry</code> your submission will almost certainly be
|
||
rejected for violating the <a href="next/rules.html">Rules</a> and in particular <a href="next/rules.html#rule17">Rule
|
||
17</a>.</p>
|
||
<p>An obvious example where <code>chkentry</code> would fail to validate <code>.auth.json</code> is if
|
||
there is a mismatch of type in the JSON file with what is expected, for
|
||
instance, if in <code>.auth.json</code> the <code>no_comment</code> that we chose to not comment on is
|
||
not a string. Another obvious example is when things are out of range (see above
|
||
for list). Two more examples would be if a field is missing or if an unknown
|
||
filed is in the file. In these cases (and any others that must be established as
|
||
valid by <code>chkentry</code>) your submission would be rejected for violating <a href="next/rules.html#rule17">Rule
|
||
17</a> and in particular because <code>chkentry</code> would not
|
||
validate the <code>.auth.json</code> file.</p>
|
||
<p>If you wish to <strong>verify</strong> that your <code>.auth.json</code> file is valid <strong>JSON</strong> then see the
|
||
FAQ on “<a href="#validating_json">validating JSON documents</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_10">
|
||
<div id="info_json">
|
||
<h3 id="faq-0.10-what-is-a-.info.json-file">FAQ 0.10: What is a <code>.info.json</code> file?</h3>
|
||
</div>
|
||
</div>
|
||
<p>This file is constructed by the <code>mkiocccentry(1)</code> <strong>prior to</strong> forming the xz
|
||
compressed tarball of your submission. The <code>.info.json</code> file contains
|
||
information about the submission, in JSON format. The
|
||
JSON <code>manifest</code> array contains information about the files of the submission,
|
||
<strong>including</strong> the <strong>mandatory</strong> <code>.auth.json</code> file,
|
||
the <strong>mandatory</strong> <code>remarks.md</code> file,
|
||
and the <strong>mandatory</strong> C source file.
|
||
See the
|
||
FAQ on “<a href="#auth_json">.auth.json</a>”
|
||
and the
|
||
FAQ on “<a href="#remarks_md">remarks.md</a>”
|
||
for more information.</p>
|
||
<p>In order of the file’s contents we describe each required field, below:</p>
|
||
<ul>
|
||
<li><code>no_comment</code> (double quoted string)
|
||
<ul>
|
||
<li>We can provide <code>no comment</code> about <code>no_comment</code> other than to state that unless
|
||
<code>no_comment</code> matches this quote:</li>
|
||
</ul></li>
|
||
</ul>
|
||
<blockquote>
|
||
<p>“mandatory comment: because comments were removed from the original JSON spec”</p>
|
||
</blockquote>
|
||
<p>your submission <strong>WILL BE</strong> rejected!</p>
|
||
<p>Are we suggesting that removing comments from the JSON spec was a mistake?</p>
|
||
<blockquote>
|
||
<p>“You might very well think that; but of course I couldn’t possibly comment.” – Francis Urquhart</p>
|
||
</blockquote>
|
||
<ul>
|
||
<li><p><code>IOCCC_info_version</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The current version of the <code>.info.json</code> files.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s <code>.info.json</code> version, defined as
|
||
<code>INFO_VERSION</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/version.h">soup/version.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>IOCCC_contest</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>Which contest number this is (e.g. 1 for 1984, 2 for 1985, 27 for 2020).</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s contest value, defined as
|
||
<code>IOCCC_CONTEST</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>IOCCC_year</code> (number)</p>
|
||
<ul>
|
||
<li>The year this contest was run in.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> sometimes an IOCCC year runs into another year and the contest year
|
||
might not match when it ends.</p>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s contest, defined as
|
||
<code>IOCCC_YEAR</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>mkiocccentry_version</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The version of <code>mkiocccentry</code> that formed this <code>.auth.json</code> file.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s <code>mkiocccentry</code> version,
|
||
defined as <code>MKIOCCCENTRY_VERSION</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/version.h">soup/version.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>iocccsize_version</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The version of <code>iocccsize</code> that was used for this <code>.info.json</code> file.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s <code>iocccentry</code> version,
|
||
defined as <code>IOCCCSIZE_VERSION</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/version.h">soup/version.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>chkentry_version</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The version of <code>chkentry</code> that was used to validate this <code>.info.json</code>,
|
||
assuming that it was created by <code>mkiocccentry</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s <code>chkentry</code> version, defined
|
||
as <code>CHKENTRY_VERSION</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/version.h">soup/version.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>fnamchk_version</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The version of <code>fnamchk</code> that <code>txzchk</code> uses to validate the filename of
|
||
the xz compressed tarball.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s <code>fnamchk</code> version, defined
|
||
as <code>FNAMCHK_VERSION</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/version.h">soup/version.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>txzchk_version</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The version of <code>txzchk</code> used to validate the xz compressed tarball.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match <strong>THIS</strong> IOCCC’s <code>txzchk</code> version, defined
|
||
as <code>TXZCHK_VERSION</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/version.h">soup/version.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>IOCCC_contest_id</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The IOCCC contestant ID used as a username in the form of <strong>in the form of
|
||
a UUID</strong> and submission number; see the <a href="next/rules.html">rules</a> for more details
|
||
on this, and in particular <a href="next/rules.html#rule17">Rule 17</a>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if the contest ID is <strong>NOT</strong> in this format then <code>fnamchk</code> will
|
||
report it as an <strong>error</strong> and your submission <strong>WILL BE</strong> rejected for
|
||
violating <a href="next/rules.html#rule17">Rule 17</a>!</p></li>
|
||
<li><p><code>submit_slot</code> (number)</p>
|
||
<ul>
|
||
<li>The submission number.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> be within the range of 0 <strong>THROUGH</strong>
|
||
<code>MAX_SUBMIT_SLOT</code> (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>). If
|
||
this is not the case you stand a great risk of having your submission
|
||
rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p></li>
|
||
<li><p><code>title</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>A short name (length >= 1 <strong>THROUGH</strong> <code>MAX_TITLE_LEN</code>, defined in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>) that
|
||
matches the regexp <code>[a-z0-9][a-z0-9_+-]*</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if this is <strong>NOT</strong> the case you stand a great risk of having your submission
|
||
rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p></li>
|
||
<li><p><code>abstract</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>A one line summary of your submission, with a length of 1 <strong>THROUGH</strong>
|
||
<code>MAX_ABSTRACT_LEN</code>, defined in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>)</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if your abstract is 0 in length or > the maximum abstract length you
|
||
stand a great risk of having your submission rejected for violating <a href="next/rules.html#rule17">Rule
|
||
17</a>!</p></li>
|
||
<li><p><code>tarball</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>The xz compressed tarball filename.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> match the actual tarball’s <strong>filename</strong> in order for
|
||
this to be valid. If there is a mismatch you stand a great risk of having
|
||
your submission rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!
|
||
Moreover, it is possible that <code>txzchk</code> will report a problem through
|
||
<code>fnamchk(1)</code> which also puts you at great risk of violating <a href="next/rules.html#rule17">Rule
|
||
17</a>. If <code>txzchk</code> does not detect this, though, it
|
||
does not mean it’s a bug but rather that the directory in the tarball
|
||
matches the filename.</p></li>
|
||
<li><p><code>rule_2a_size</code> (number)</p>
|
||
<ul>
|
||
<li>The size calculated of <a href="next/rules.html#rule2a">Rule 2a</a>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if this violates <a href="next/rules.html#rule2a">Rule 2a</a> you stand a great
|
||
chance of having your submission rejected for violating the
|
||
<a href="next/rules.html">Rules</a>!</p></li>
|
||
<li><p><code>rule_2b_size</code> (number)</p>
|
||
<ul>
|
||
<li>The size calculated of <a href="next/rules.html#rule2b">Rule 2b</a>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if this violates <a href="next/rules.html#rule2b">Rule 2b</a> you stand a great
|
||
chance of having your submission rejected for violating the
|
||
<a href="next/rules.html">Rules</a>!</p></li>
|
||
<li><p><code>empty_override</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if user override warning of an empty source file, else <code>false</code>.</li>
|
||
</ul></li>
|
||
<li><p><code>rule_2a_override</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if user overrides warning of <a href="next/rules.html#rule2a">Rule 2a</a>
|
||
violation, else <code>false</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if the <a href="next/rules.html#rule2a">Rule 2a</a> calculated size is <strong>NOT</strong>
|
||
violated but this is <code>true</code> then you stand a good chance of having your
|
||
submission rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p></li>
|
||
<li><p><code>rule_2a_mismatch</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if <a href="next/rules.html#rule2a">Rule 2a</a> calculated size is not the
|
||
same as the file size.</li>
|
||
</ul></li>
|
||
<li><p><code>rule_2b_override</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if user overrides warning of <a href="next/rules.html#rule2b">Rule 2b</a>
|
||
violation, else <code>false</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if the <a href="next/rules.html#rule2b">Rule 2b</a> calculated size is <strong>NOT</strong>
|
||
violated but this is <code>true</code> then you stand a good chance of having your
|
||
submission rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p></li>
|
||
<li><p><code>highbit_warning</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if <code>iocccsize</code> detects a high bit (unescaped octets with the high
|
||
bit set - octet value >= 128); see <a href="next/rules.html#rule13">Rule 13</a>, else
|
||
<code>false</code>.</li>
|
||
</ul></li>
|
||
<li><p><code>nul_warning</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if <code>iocccsize</code> detects a NUL character in the <code>prog.c</code>, else
|
||
<code>false</code>.</li>
|
||
</ul></li>
|
||
<li><p><code>trigraph_warning</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if <code>iocccsize</code> detects an unknown or invalid trigraph in
|
||
<code>prog.c</code>, else <code>false</code>.</li>
|
||
</ul></li>
|
||
<li><p><code>wordbuf_warning</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if <code>prog.c</code> triggered a word buffer overflow (see <code>iocccsize</code>),
|
||
else <code>false</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this does <strong>NOT</strong> mean that your code has been checked for buffer
|
||
overflows in general.</p></li>
|
||
<li><p><code>ungetc_warning</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if <code>prog.c</code> triggered an <code>ungetc(3)</code> error, else <code>false</code>.</li>
|
||
</ul></li>
|
||
<li><p><code>Makefile_override</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if the user overrides any warnings about an incomplete/incorrect
|
||
<code>Makefile</code> file, else <code>false</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if the <code>Makefile</code> file has no problems and this is <code>true</code> then
|
||
you stand a good chance of having your submission rejected for violating
|
||
<a href="next/rules.html#rule17">Rule 17</a>!</p>
|
||
<p>See the
|
||
FAQ on “<a href="#makefile">Makefile</a>”
|
||
for more information.</p></li>
|
||
<li><p><code>first_rule_is_all</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if the first rule in the <code>Makefile</code> file is <code>all</code>, else <code>false</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if the <code>Makefile</code> file does <strong>NOT</strong> have an <code>all</code> rule or it is not
|
||
first and this boolean is <code>true</code> then you stand a good chance of having your
|
||
submission rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p>
|
||
<p>See the
|
||
FAQ on “<a href="#makefile">Makefile</a>”
|
||
for more information.</p></li>
|
||
<li><p><code>found_all_rule</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if the <code>Makefile</code> file has an <code>all</code> rule, else <code>false</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if the <code>Makefile</code> file does <strong>NOT</strong> have an <code>all</code> rule and this
|
||
boolean is <code>true</code>, or if it does <strong>NOT</strong> have an <code>all</code> rule but
|
||
<code>first_rule_is_all</code> is <code>true</code> then you stand a good chance of having your
|
||
submission rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p>
|
||
<p>See the
|
||
FAQ on “<a href="#makefile">Makefile</a>”
|
||
for more information.</p></li>
|
||
<li><p><code>found_clean_rule</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if the <code>Makefile</code> file has a <code>clean</code> rule, else <code>false</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if the <code>Makefile</code> file does <strong>NOT</strong> have a <code>clean</code> rule and this
|
||
boolean is <code>true</code> then you stand a good chance of having your submission
|
||
rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p>
|
||
<p>See the
|
||
FAQ on “<a href="#makefile">Makefile</a>”
|
||
for more information.</p></li>
|
||
<li><p><code>found_clobber_rule</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if the <code>Makefile</code> file has a <code>clobber</code> rule, else <code>false</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if the <code>Makefile</code> file does <strong>NOT</strong> have an <code>clobber</code> rule and this
|
||
boolean is <code>true</code> then you stand a good chance of having your submission
|
||
rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p>
|
||
<p>See the
|
||
FAQ on “<a href="#makefile">Makefile</a>”
|
||
for more information.</p></li>
|
||
<li><p><code>found_try_rule</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if the <code>Makefile</code> file has a <code>try</code> rule, else <code>false</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if the <code>Makefile</code> file does <strong>NOT</strong> have an <code>try</code> rule and this
|
||
boolean is <code>true</code> then you stand a good chance of having your submission
|
||
rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p>
|
||
<p>See the
|
||
FAQ on “<a href="#makefile">Makefile</a>”
|
||
for more information.</p></li>
|
||
<li><p><code>test_mode</code> (boolean)</p>
|
||
<ul>
|
||
<li><code>true</code> if the <code>test</code> ID was used to form the tarball, else <code>false</code>.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if this is <code>true</code> then this may <strong>NOT</strong> be submitted to the
|
||
contest! Please do <strong>NOT</strong> email the <a href="judges.html">Judges</a> your submission!</p></li>
|
||
</ul>
|
||
<p>Next comes the <code>manifest</code> <strong>array</strong> which <strong>MUST</strong> have AT LEAST the following.
|
||
The <code>mkiocccentry(1)</code> tool will write it in this order:</p>
|
||
<ul>
|
||
<li><p><code>info_JSON</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>This <code>MUST</code> be <code>".info.json"</code>, defined as <code>INFO_JSON_FILENAME</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/entry_util.h">soup/entry_util.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>, and
|
||
it is the <code>.info.json</code> file that <code>mkiocccentry</code> forms.
|
||
See the
|
||
FAQ on “<a href="#info_json">.info.json</a>”
|
||
for more information.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if this is <strong>NOT</strong> the case you stand a great chance of having your
|
||
submission rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p></li>
|
||
<li><p><code>auth_JSON</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>This <code>MUST</code> be <code>".auth.json"</code>, defined as <code>AUTH_JSON_FILENAME</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/entry_util.h">soup/entry_util.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>, and
|
||
it is the <code>.auth.json</code> file that <code>mkiocccentry</code> forms.
|
||
See the
|
||
FAQ on “<a href="#auth_json">.auth.json</a>”
|
||
for more information.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if this is <strong>NOT</strong> the case you stand a great chance of having your
|
||
submission rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p></li>
|
||
<li><p><code>c_src</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>This <code>MUST</code> be <code>"prog.c"</code>, defined as <code>PROG_C_FILENAME</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/entry_util.h">soup/entry_util.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>, and
|
||
is your submission source code.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if this is <strong>NOT</strong> the case you stand a great chance of having your
|
||
submission rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p>
|
||
<p><strong>NOTE:</strong> if you provide to <code>mkiocccentry</code> a different filename it will be
|
||
copied to <code>prog.c</code>.</p></li>
|
||
<li><p><code>Makefile</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>This <code>MUST</code> be <code>"Makefile"</code>, defined as <code>MAKEFILE_FILENAME</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/entry_util.h">soup/entry_util.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>, and
|
||
is your <code>Makefile</code> file.
|
||
See the
|
||
FAQ on “<a href="#makefile">Makefile</a>”
|
||
for more information.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if this is <strong>NOT</strong> the case you stand a great chance of having your
|
||
submission rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p>
|
||
<p><strong>NOTE:</strong> if you provide to <code>mkiocccentry</code> a different filename it will be
|
||
copied to <code>Makefile</code>.</p></li>
|
||
<li><p><code>remarks</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>This <code>MUST</code> be <code>"remarks.md"</code>, defined as <code>REMARKS_FILENAME</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/entry_util.h">soup/entry_util.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>, and
|
||
is your <code>remarks.md]</code> file.
|
||
See the
|
||
FAQ on “<a href="#remarks_md">remarks.md</a>”
|
||
for more information.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> if this is <strong>NOT</strong> the case you stand a great chance of having your
|
||
submission rejected for violating <a href="next/rules.html#rule17">Rule 17</a>!</p>
|
||
<p><strong>NOTE:</strong> if you provide to <code>mkiocccentry</code> a different filename it will be
|
||
copied to <code>remarks.md</code>.</p></li>
|
||
</ul>
|
||
<p>The <code>manifest</code> <strong>array</strong> also <strong>OPTIONALLY</strong> has one or more of the field:</p>
|
||
<ul>
|
||
<li><p><code>extra_file</code> (double quoted string)</p>
|
||
<ul>
|
||
<li>Any additional file that you need or want to include with your submission.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this MUST <strong>NOT</strong> match a mandatory filename (see above list) and
|
||
<code>chkentry</code> will verify this for you; it is <strong>ALSO</strong> an <strong>error</strong> if the
|
||
filenames are not unique. In these cases you stand a great risk of having
|
||
your submission rejected for violating <a href="next/rules.html#rule17">Rule 17</a>! On
|
||
the other hand, <strong>ONLY</strong> <code>mkiocccentry</code> will verify that the files exist and
|
||
can be read; <code>txzchk(1)</code> will <strong>NOT</strong> do this for you as it only <strong>LISTS</strong>
|
||
the tarball: it does <strong>NOT</strong> extract it. Even so, the <a href="judges.html">Judges</a>
|
||
<strong>WILL</strong> extract the tarball and if a file listed in the manifest does not
|
||
exist your submission will very likely be rejected for not being as
|
||
documented!</p></li>
|
||
</ul>
|
||
<p>Finally, after the <code>manifest</code> <strong>array</strong>, the following fields <strong>MUST</strong> exist:</p>
|
||
<ul>
|
||
<li><p><code>formed_timestamp</code> (number)</p>
|
||
<ul>
|
||
<li>Seconds since epoch when JSON (<code>.auth.json</code> or <code>.info.json</code>) file was formed (see <code>gettimeofday(2)</code>).</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> be greater than or equal to <code>MIN_TIMESTAMP</code> (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>). If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected.</p></li>
|
||
<li><p><code>formed_timestamp_usec</code> (number)</p>
|
||
<ul>
|
||
<li>Microseconds since the tstamp (seconds since epoch when <code>.auth.json</code> was
|
||
formed - see <code>gettimeofday(2)</code>) second.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> be within the range <code>MIN_FORMED_TIMESTAMP_USEC</code>
|
||
<strong>THROUGH</strong> <code>MAX_FORMED_TIMESTAMP_USEC</code> and is validated by
|
||
<code>test_formed_timestamp_usec()</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/entry_util.c">soup/entry_util.c</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case <code>chkentry(1)</code> will report an <strong>error</strong> and your
|
||
submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>timestamp_epoch</code> (double quoted string)</p>
|
||
<ul>
|
||
<li><code>"Thu Jan 01 00:00:00 1970 UTC"</code> (<code>gettimeofday(2)</code> epoch).</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> be <code>"Thu Jan 01 00:00:00 1970 UTC"</code> which is <code>#define</code>d
|
||
as <code>TIMESTAMP_EPOCH</code> in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
<li><p><code>min_timestamp</code> (number)</p>
|
||
<ul>
|
||
<li>Minimum number of second since epoch for <strong>this</strong> IOCCC.</li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> this <strong>MUST</strong> be >= <code>MIN_TIMESTAMP</code> defined in
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">soup/limit_ioccc.h</a>
|
||
in the <a href="https://github.com/ioccc-src/mkiocccentry/">mkiocccentry repo</a>. If
|
||
this is not the case your submission <strong>WILL BE</strong> rejected!</p></li>
|
||
</ul>
|
||
<p>This file will be verified with the <code>chkentry(1)</code> tool and if there are any
|
||
problems <strong>it is an error</strong> and the tarball will <strong>NOT</strong> be formed by
|
||
<code>mkiocccentry</code>; otherwise the <code>txzchk(1)</code> tool will be executed on the tarball.</p>
|
||
<p>The <a href="judges.html">Judges</a> <strong>WILL</strong> use <code>chkentry(1)</code> on this file during the
|
||
judging process and if it does not pass your submission <strong>WILL BE</strong> rejected.</p>
|
||
<p>An obvious example where <code>chkentry</code> would fail to validate <code>.info.json</code> is if
|
||
there is a mismatch of type in the JSON file with what is expected, for
|
||
instance, if in <code>.info.json</code> the <code>no_comment</code> that we chose to not comment on is
|
||
not a string. Another obvious example is when things are out of range (see above
|
||
for list). Two more examples would be if a field is missing or if an unknown
|
||
filed is in the file. In these cases (and any others that must be established as
|
||
valid by <code>chkentry</code>) your submission would be rejected for violating <a href="next/rules.html#rule17">Rule
|
||
17</a> and in particular because <code>chkentry</code> would not
|
||
validate the <code>.info.json</code> file.</p>
|
||
<p>If you wish to <strong>verify</strong> that your <code>.info.json</code> file is valid <strong>JSON</strong> then see the
|
||
FAQ on “<a href="#validating_json">validating JSON documents</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_11">
|
||
<div id="validating_json">
|
||
<div id="jparse">
|
||
<h3 id="faq-0.11-how-can-i-validate-any-json-document">FAQ 0.11: How can I validate any JSON document?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>If you want or need to verify that a JSON document (as a string or file) is
|
||
valid, you can use the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/README.md">jparse</a>
|
||
tool. The IOCCC version of the <code>jparse(1)</code> tool may be installed from the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>.</p>
|
||
<p>The <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/FAQ.md#download">FAQ.md file in the mkiocccentry
|
||
repo</a>
|
||
contains information about how to find and compile the mkiocccentry
|
||
toolkit, which includes the IOCCC version of the <code>jparse(1)</code> tool, located
|
||
under the <code>mkiocccentry</code> directory as <code>jparse/jparse</code>.</p>
|
||
<p>Additionally you may install the <code>jparse(1)</code> tool from the <a href="https://github.com/xexyl/jparse">jparse
|
||
repo</a>:</p>
|
||
<pre class="<!--sh-->"><code> git clone https://github.com/xexyl/jparse.git
|
||
cd jparse
|
||
make clobber all test
|
||
sudo make install</code></pre>
|
||
<p>The syntax of <code>jparse(1)</code> is very simple:</p>
|
||
<pre class="<!--sh-->"><code> jparse foo.json</code></pre>
|
||
<p>If the tool shows <code>valid JSON</code> then the document is valid JSON; otherwise it’ll
|
||
show an error message. If you don’t want to see any output unless it is invalid
|
||
you can specify the <code>-q</code> option to <code>jparse</code>. In that case an exit code of 0
|
||
indicates the JSON is valid.</p>
|
||
<p>If you want to see more information about the parsing you can increase the
|
||
verbosity with the <code>-v</code> option. For instance:</p>
|
||
<pre class="<!--sh-->"><code> jparse -v 3 foo.json</code></pre>
|
||
<p>If the tool is not installed then you will obviously have to specify the path of
|
||
the tool.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_12">
|
||
<div id="validating_auth_info_json">
|
||
<div id="chkentry">
|
||
<h3 id="faq-0.12-how-can-i-validate-my-.auth.json-andor-.info.json-files">FAQ 0.12: How can I validate my <code>.auth.json</code> and/or <code>.info.json</code> files?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>If you want to validate the <code>.auth.json</code> or <code>.info.json</code> files you
|
||
should use <code>chkentry(1)</code> from the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||
repo</a>.</p>
|
||
<p>The <code>chkentry(1)</code> tool uses the IOCCC version of the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/man/man3/jparse.3">jparse
|
||
API</a>
|
||
to perform <strong>additional</strong> checks on these two IOCCC specific JSON files. It is
|
||
<em>possible</em> that this version will at times differ from the <a href="https://github.com/xexyl/jparse/blob/master/man/man3/jparse.3">official jparse
|
||
API</a> at the
|
||
<a href="https://github.com/xexyl/jparse">official jparse repo</a> and this is one of the
|
||
reasons the tools’ <code>-V</code> (version option) show the JSON parser version as well.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#auth_json">.auth.json</a>”
|
||
and
|
||
FAQ on “<a href="#info_json">.info.json</a>”
|
||
for more details on these files.</p>
|
||
<p>The <code>chkentry(1)</code> tool accepts more than one command line form.
|
||
If you pass a single argument, it is expected to be a directory that has both
|
||
<code>.auth.json</code> and <code>.info.json</code> in it. You can also specify a <code>.auth.json</code> and/or
|
||
<code>.info.json</code> file. An argument of “<code>.</code>” will skip that file. For instance:</p>
|
||
<pre><code> # test entry directory test_work:
|
||
chkentry test_work
|
||
|
||
# run checks on .info.json:
|
||
chkentry .info.json .
|
||
|
||
# run checks on .auth.json:
|
||
chkentry . .auth.json
|
||
|
||
# run checks on .info.json and .auth.json:
|
||
chkentry .info.json .auth.json</code></pre>
|
||
<p>If there is a <a href="https://www.json.org/json-en.html">JSON</a> issue detected by
|
||
<code>jparse(3)</code> API, then there is a <a href="https://www.json.org/json-en.html">JSON</a> error and
|
||
<code>chkentry(1)</code> will report it as an <strong>error</strong>. If the parsing is OK (i.e. valid
|
||
JSON) but there is an issue in one or both of the
|
||
<a href="https://www.json.org/json-en.html">JSON</a> files in <strong>the context of the IOCCC</strong>,
|
||
it will report this as an <strong>error</strong>. Thus, if you were to package your
|
||
submission manually then you would be violating <a href="next/rules.html#rule17">Rule
|
||
17</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_13">
|
||
<div id="txzchk">
|
||
<div id="tarball">
|
||
<div id="xz">
|
||
<h3 id="faq-0.13---how-can-i-validate-my-submission-tarball">FAQ 0.13 - How can I validate my submission tarball?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>The tool that validates submission tarballs can be obtained from the <a href="https://github.com/ioccc-src/mkiocccentry">IOCCC
|
||
mkiocccentry repo</a>. The
|
||
<code>mkiocccentry</code> tool itself will run the validator <strong>after</strong> forming the tarball.
|
||
However, you may wish to manually validate the tarball. The tool that does this
|
||
is <code>txzchk</code>.</p>
|
||
<p>If you wish to validate the tarball without running the <code>mkiocccentry(1)</code> tool,
|
||
for instance the tarball
|
||
<code>submit.12345678-1234-4321-abcd-1234567890ab-2.1720636351.txz</code> you can, after
|
||
installing the tools, do:</p>
|
||
<pre><code> txzchk submit.12345678-1234-4321-abcd-1234567890ab-2.1720636351.txz</code></pre>
|
||
<p>Assuming that the tarball exists and is valid, you should see no output.</p>
|
||
<p>If you wish to see the contents, for instance like <code>mkiocccentry(1)</code> does, you
|
||
could do:</p>
|
||
<pre><code> txzchk -v 1 submit.12345678-1234-4321-abcd-1234567890ab-2.1720636351.txz</code></pre>
|
||
<p>As the <a href="next/guidelines.html#txzchk">guidelines state</a>, it is beyond the scope
|
||
of this document to discuss the many tests that <code>txzchk(1)</code> runs; if you must
|
||
know we refer you to the <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c">source
|
||
code</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_14">
|
||
<div id="fnamchk">
|
||
<div id="tarball_filename">
|
||
<h3 id="faq-0.14---what-is-the-fnamchk-tool">FAQ 0.14 - What is the <code>fnamchk</code> tool?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>This tool, which is in the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||
repo</a>, validates the directory name
|
||
of your submission.</p>
|
||
<p>Rather than <code>mkiocccentry</code> running this tool manually, <code>txzchk</code>’s algorithm uses
|
||
the output of this tool. If you wish to validate your tarball filename manually,
|
||
you can do so. For instance:</p>
|
||
<pre><code> fnamchk submit.12345678-1234-4321-abcd-1234567890ab-2.1720636351.txz</code></pre>
|
||
<p>Assuming everything is OK, it would show:</p>
|
||
<blockquote>
|
||
<p><code>12345678-1234-4321-abcd-1234567890ab-2</code></p>
|
||
</blockquote>
|
||
<p>See also the
|
||
FAQ on “<a href="#txzchk">validating your submission tarball</a>”
|
||
for more information.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_15">
|
||
<div id="mkiocccentry">
|
||
<h3 id="faq-0.15---what-is-the-mkiocccentry-tool-and-how-do-i-use-it">FAQ 0.15 - What is the <code>mkiocccentry</code> tool and how do I use it?</h3>
|
||
</div>
|
||
</div>
|
||
<p>This tool also comes from the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry
|
||
repo</a> and it is <strong>required</strong> that you
|
||
use it to package your submission. Not doing so puts you at a great risk of
|
||
violating the <a href="next/rules.html">Rules</a> and in particular <a href="next/rules.html#rule17">Rule
|
||
17</a>. The <code>mkiocccentry</code> tool first gathers your source
|
||
code, your Makefile, your remarks, other information about your submission,
|
||
information about the author (or authors) and then runs a lot of tests before (if
|
||
all is OK) forming your tarball. After this is done it will additionally run the
|
||
<code>txzchk(1)</code> tool (which runs the <code>fnamchk(1)</code> tool) on the submission tarball.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#submit">submitting to the IOCCC</a>”
|
||
for details on how to register for the IOCCC.</p>
|
||
<p>Once you have registered, you will need to package your entry with the
|
||
<code>mkiocccentry</code> tool. The below details discuss this very important tool. As it
|
||
is complicated we will explain how to use this tool.</p>
|
||
<p>As the <a href="next/guidelines.html">Guidelines</a> state, the synopsis is:</p>
|
||
<pre><code> mkiocccentry [options] work_dir prog.c \
|
||
Makefile remarks.md [file ...]</code></pre>
|
||
<p>… where <code>work_dir</code> is a directory that will be used to build the submission
|
||
tarball, <code>prog.c</code> is your submission source code, <code>Makefile</code> is your submission’s
|
||
<code>Makefile</code>, <code>remarks.md</code> are your remarks (that will be the basis of the
|
||
<code>README.md</code> file which will be used to form the <code>index.html</code> file, if your
|
||
submission wins) and the remaining args are the paths to any other files you
|
||
wish to submit.</p>
|
||
<p>The <code>work_dir</code> <strong>MUST</strong> already exist, as a directory, and it is an error if it
|
||
is not a directory that can be written to. In <strong>this</strong> directory your <strong>submission
|
||
directory</strong> will be created, with the name based on your IOCCC registration
|
||
username, which is <strong>in the form of a UUID</strong> and submission number; see the
|
||
<a href="next/rules.html">rules</a> for more details on this, and in particular <a href="next/rules.html#rule17">Rule
|
||
17</a>.</p>
|
||
<p>If the <strong><em>subdirectory</em> in the <em>work directory</em></strong> already exists, you will have to
|
||
move it, remove it or otherwise specify a different work directory (<strong>NOT</strong> the
|
||
subdirectory), as it needs to be empty and the <code>mkiocccentry(1)</code> tool does not
|
||
check this for you as it could not do anything about anyway.</p>
|
||
<p>This <em>subdirectory is where your files will be <strong>copied</strong> to</em>. Your <em>submission
|
||
tarball</em> (which you will upload to the submit server) that <code>txzchk(1)</code> will
|
||
validate <em>will be placed in the <strong>work directory</strong></em>, and <strong>its <em>contents</em> will
|
||
be the <em>subdirectory</em> with your submission’s files</strong>.</p>
|
||
<p>The <code>mkiocccentry(1)</code> tool will ask you for information about your
|
||
submission <em>as well as author details</em> (that will only be looked at if the
|
||
submission wins), run some tests and run a number of other tools, as already
|
||
mentioned and as described below.</p>
|
||
<p>To help you with editing a submission, the <code>mkiocccentry(1)</code> tool has
|
||
some options to write <em>OR</em> read from an answers file so you do not have to input
|
||
the information about the author(s) and the submission itself, after saving the
|
||
answers to a file. To write to <code>answers.txt</code> try:</p>
|
||
<pre><code> mkiocccentry -a answers.txt ...</code></pre>
|
||
<p>Alternatively, if you wish to overwrite a file, you can use the <code>-A</code>
|
||
flag with the same option argument. Be <strong>very careful</strong> that you do not accidentally
|
||
overwrite your <code>prog.c</code> or some other important file!</p>
|
||
<p>To make use of the answers file, use the <code>-i answers</code> option like:</p>
|
||
<pre><code> mkiocccentry -i answers.txt ...</code></pre>
|
||
<div id="mkiocccentry_checks">
|
||
<h4 id="mkiocccentry-checks"><code>mkiocccentry</code> checks</h4>
|
||
</div>
|
||
<p><code>mkiocccentry(1)</code> will check and warn about the following conditions:</p>
|
||
<ul>
|
||
<li>If the files do not exist, are not regular files or cannot be read.</li>
|
||
<li>If <code>prog.c</code> violates <a href="next/rules.html#rule2">Rule 2</a> (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">iocccsize.c</a>).</li>
|
||
<li>If <code>prog.c</code> is empty.</li>
|
||
<li>If <code>prog.c</code> has any high bit char (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">iocccsize.c</a>).</li>
|
||
<li>If <code>prog.c</code> has any NUL char (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">iocccsize.c</a>).</li>
|
||
<li>If <code>prog.c</code> has any unknown or invalid trigraph (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">iocccsize.c</a>).</li>
|
||
<li>If <code>prog.c</code> triggers a word buffer overflow (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">iocccsize.c</a>).</li>
|
||
<li>If <code>prog.c</code> triggers an <code>ungetc(3)</code> error (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c">iocccsize.c</a>).</li>
|
||
<li>If the first rule in the <code>Makefile</code> is not <code>all</code>.</li>
|
||
<li>If the <code>Makefile</code> does not have a <code>clean</code> rule.</li>
|
||
<li>If the <code>Makefile</code> does not have a <code>clobber</code> rule.</li>
|
||
<li>If the <code>Makefile</code> does not have a <code>try</code> rule.</li>
|
||
<li>If the <code>remarks.md</code> is empty.</li>
|
||
</ul>
|
||
<p>Conditions that one must correct, and which <code>mkiocccentry(1)</code> will prompt until
|
||
they are correct, are:</p>
|
||
<ul>
|
||
<li>Your <em>title</em> is not in the range of 1 through <code>MAX_TITLE_LEN</code> chars (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">limit_ioccc.h</a>).</li>
|
||
<li>Your <em>title</em> does not match the regexp <code>^[0-9a-z][0-9a-z._+-]*$</code>.</li>
|
||
<li>Your <em>abstract</em> is not between 1 and <code>MAX_ABSTRACT_LEN</code> chars
|
||
(see <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">limit_ioccc.h</a>).</li>
|
||
<li>the author count is not 1 through <code>MAX_AUTHORS</code> (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">limit_ioccc.h</a>).</li>
|
||
<li>An author <em>name</em> is not 1 through <code>MAX_NAME_LEN</code> chars (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">limit_ioccc.h</a>).</li>
|
||
<li>Duplicate author <em>name</em>.</li>
|
||
<li><em>Country code</em> is invalid (not ISO 3166-1 2 character
|
||
codes).</li>
|
||
<li>An <em>email</em>, if provided, is not in the format of <code>x@y</code> or
|
||
if <code>x</code> or <code>y</code> contain a <code>@</code>, are empty or if the total length is longer than
|
||
<code>MAX_EMAIL_LEN</code> (see <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">limit_ioccc.h</a>).</li>
|
||
<li>A <em>URL</em> or <em>alt URL</em>, if provided, does not start with <code>http://</code>
|
||
or <code>https://</code> or is longer than <code>MAX_URL_LEN</code> chars (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">limit_ioccc.h</a>)
|
||
or does not have anything after the <code>http://</code> or <code>https://</code>.</li>
|
||
<li>A <em>mastodon handle</em>, if provided, is not in the form of
|
||
<code>@user@site</code> (i.e. starts with an <code>@</code>, has text following it and then another
|
||
<code>@</code> followed by more text and has no other <code>@</code>) or is longer than <code>MAX_MASTODON_LEN</code> (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">limit_ioccc.h</a>).</li>
|
||
<li>A <em>GitHub account</em>, if provided, does not start with an <code>@</code>,
|
||
has more than one <code>@</code> or is longer than <code>MAX_GITHUB_LEN</code> (see
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">limit_ioccc.h</a>).</li>
|
||
<li>An <em>affiliation</em>, if provided, is longer than
|
||
<code>MAX_AFFILIATION_LEN</code> (see <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h">limit_ioccc.h</a>).</li>
|
||
<li>An <em>author handle</em>, if the default is not accepted, does
|
||
not match the regexp <code>^[0-9A-Za-z][0-9A-Za-z._+-]*$</code>.</li>
|
||
<li>An <em>author handle</em> is repeated.</li>
|
||
<li>The output of <code>ls</code> on the submission directory is incorrect.</li>
|
||
</ul>
|
||
<p>Although the <code>mkiocccentry(1)</code> tool will verify everything for you, you may wish
|
||
to validate different parts individually with the different tools. As the
|
||
<a href="next/rules.html">rules</a> state, each of these tools has a <code>-h</code> option.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#jparse">jparse</a>”,
|
||
the
|
||
FAQ on “<a href="#auth_json">.auth.json</a>”,
|
||
the
|
||
FAQ on “<a href="#info_json">.info.json</a>”,
|
||
the
|
||
FAQ on “<a href="#chkentry">chkentry</a>”,
|
||
the
|
||
FAQ on “<a href="#txzchk">txzchk</a>”
|
||
and the
|
||
FAQ on “<a href="#fnamchk">fnamchk</a>”
|
||
for more details on the tools that <code>mkiocccentry</code> either executes directly or
|
||
indirectly as part of the packaging process, especially if you wish to run one
|
||
or more of these tools manually.</p>
|
||
<p>See also the <a href="next/guidelines.html">Guidelines</a> and the <a href="next/rules.html">Rules</a>
|
||
(and in particular <a href="next/rules.html#rule17">Rule 17</a>).</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq0_16">
|
||
<div id="mkiocccentry_compile">
|
||
<div id="compile_mkiocccentry">
|
||
<h3 id="faq-0.16---how-do-i-compile-mkiocccentry-and-its-related-tools">FAQ 0.16 - How do I compile <code>mkiocccentry</code> and its related tools?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>After you
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/FAQ.md#download">downloaded the mkiocccentry repo</a></p>
|
||
<p>Quoting from the mkiocccentry repo FAQ:</p>
|
||
<blockquote>
|
||
<p><strong>git clone https://github.com/ioccc-src/mkiocccentry.git</strong></p>
|
||
</blockquote>
|
||
<p>You need to <a href="https://github.com/ioccc-src/mkiocccentry/blob/master/FAQ.md#compiling">compile the mkiocccentry and related tools</a>.</p>
|
||
<p>Quoting from the mkiocccentry repo FAQ:</p>
|
||
<blockquote>
|
||
<p><strong>cd mkiocccentry ; make clobber all</strong></p>
|
||
</blockquote>
|
||
<p>See the
|
||
<a href="https://github.com/ioccc-src/mkiocccentry/blob/master/FAQ.md">mkiocccentry repo FAQ</a>
|
||
for more up to date information on downloading, compiling, and related FAQ information.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq1">
|
||
<h2 id="section-1-history-of-the-ioccc">Section 1: History of the IOCCC</h2>
|
||
</div>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq1_0">
|
||
<div id="ioccc_start">
|
||
<div id="stormy_night">
|
||
<div id="beginning">
|
||
<h3 id="faq-1.0-how-did-the-ioccc-get-started">FAQ 1.0: How did the IOCCC get started?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p><strong>It was a dark and stormy night…</strong></p>
|
||
<p>OK, let’s go back to 1984, not 1830: one day (1984 March 23 to be exact), Larry Bassel
|
||
and I (Landon Curt Noll) were working for National Semiconductor’s Genix porting
|
||
group, and we were both in our offices trying to fix some very broken code.</p>
|
||
<p>Larry had been trying to fix a bug in the classic Bourne shell (C code <code>#define</code>d
|
||
to death to sort of look like Algol) and I had been working on the <code>finger(1)</code>
|
||
program from early BSD (a bug ridden <code>finger</code> implementation to be sure).</p>
|
||
<p>We happened to both wander (at the same time) out to the hallway
|
||
in Building 7C to clear our heads.</p>
|
||
<p>We began to compare notes: ‘<em>You won’t believe the code I am trying to fix</em>’.</p>
|
||
<p>And: ’<em>Well you cannot imagine the brain damage level of the code I’m trying to
|
||
fix’</em>.</p>
|
||
<p>As well as: ’<em>It’s more than bad code, the author really had to try to make it
|
||
this bad!</em></p>
|
||
<p>After a few minutes we wandered back into my office where I posted a
|
||
<a href="http://groups.google.com/groups?q=Obfuscated&hl=en&lr=&ie=UTF-8&as_drrb=b&as_mind=1&as_minm=1&as_miny=1983&as_maxd=18&as_maxm=4&as_maxy=1984&selm=789%40nsc.UUCP&rnum=3&filter=0%22">flame to
|
||
net.lang.c</a>
|
||
inviting people to try and out obfuscate the UN*X source code we had just been working on.</p>
|
||
<p>BTW: I (Landon Curt Noll) had to post this <a href="http://groups.google.com/groups?q=Obfuscated&hl=en&lr=&ie=UTF-8&as_drrb=b&as_mind=1&as_minm=1&as_miny=1983&as_maxd=18&as_maxm=4&as_maxy=1984&selm=795%40nsc.UUCP&rnum=10&filter=0">typo
|
||
correction</a>.
|
||
Thus began the tradition of putting typos in the contest rules and guidelines
|
||
… to make them more obfuscated of course! :-)</p>
|
||
<p>BTW: This posting was made back in the days when AT&T was the evil giant.
|
||
Now, Microsoft makes AT&T look mild and kind in comparison. :-( (IMHO) ).</p>
|
||
<p>BTW: See the story about the ‘<a href="1993/cmills/index.html">Bill Gates</a>’ award. :-)</p>
|
||
<p>OK, back to the story.</p>
|
||
<p>We (Larry and I) received a number of entries by email.
|
||
When we began to receive messages from outside of the US, Larry and I
|
||
decided to include International in the name.</p>
|
||
<p>The
|
||
<a href="http://groups.google.com/groups?q=Obfuscated&hl=en&lr=&ie=UTF-8&as_drrb=b&as_mind=1&as_minm=1&as_miny=1983&as_maxd=18&as_maxm=4&as_maxy=1984&selm=837%40nsc.UUCP&rnum=2&filter=0">1st IOCCC entries</a>
|
||
were posted on 17 April 1984.</p>
|
||
<p>There were 4 entries that won in 1984:</p>
|
||
<ol type="1">
|
||
<li><a href="http://groups.google.com/groups?q=Obfuscated&hl=en&lr=&ie=UTF-8&as_drrb=b&as_mind=1&as_minm=1&as_miny=1983&as_maxd=18&as_maxm=4&as_maxy=1984&selm=842%40nsc.UUCP&rnum=8&filter=0">(dis)honorable mention</a></li>
|
||
<li><a href="http://groups.google.com/groups?q=Obfuscated&hl=en&lr=&ie=UTF-8&as_drrb=b&as_mind=1&as_minm=1&as_miny=1983&as_maxd=18&as_maxm=4&as_maxy=1984&selm=843%40nsc.UUCP&rnum=7&filter=0">3rd place</a></li>
|
||
<li><a href="http://groups.google.com/groups?q=Obfuscated&hl=en&lr=&ie=UTF-8&as_drrb=b&as_mind=1&as_minm=1&as_miny=1983&as_maxd=18&as_maxm=4&as_maxy=1984&selm=844%40nsc.UUCP&rnum=6&filter=0">2nd place</a></li>
|
||
<li><a href="http://groups.google.com/groups?q=Obfuscated&hl=en&lr=&ie=UTF-8&as_drrb=b&as_mind=1&as_minm=1&as_miny=1983&as_maxd=18&as_maxm=4&as_maxy=1984&selm=845%40nsc.UUCP&rnum=5&filter=0">1st place</a></li>
|
||
</ol>
|
||
<p>BTW: The (dis)honorable mention wished to remain anonymous.
|
||
While many have asked who it was, we have continued to follow the
|
||
author’s wish to remain anonymous.</p>
|
||
<p>A few years ago, we asked the author if they still wanted to remain anonymous.
|
||
They said: ‘<em>Yes, I want to keep my anonymity. But you can tell them that I am well known for my connection to the
|
||
C language</em>’. It was not until 2001 that another <a href="2001/anonymous/index.html">anonymous
|
||
entry</a> received an award.</p>
|
||
<p>BTW: The <a href="1984/mullender/index.html">1984/mullender</a> remains one of my (Landon Curt Noll) all time favorites.</p>
|
||
<p>The name used in the posting of the <a href="http://groups.google.com/groups?q=Obfuscated&hl=en&lr=&ie=UTF-8&as_drrb=b&as_mind=1&as_minm=1&as_miny=1983&as_maxd=18&as_maxm=4&as_maxy=1984&selm=837%40nsc.UUCP&rnum=2&filter=0">1st winning IOCCC
|
||
entry</a>
|
||
posting was <strong>I</strong>nternational <strong>O</strong>bfuscated <strong>C</strong> <strong>C</strong>ode <strong>C</strong>ontest or
|
||
<strong>IOCCC</strong> for short.</p>
|
||
<p>The posting said ‘<em>1st annual</em>’, so in 1985 we held the <a href="years.html#1985">2nd IOCCC contest</a>
|
||
and the tradition continues as the longest running contest on the Internet.</p>
|
||
<p>P.S. Part of the inspiration for making the IOCCC a contest goes to the
|
||
<a href="http://www.bulwer-lytton.com/">Bulwer-Lytton fiction contest</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq1_1">
|
||
<div id="missing_years">
|
||
<h3 id="faq-1.1-why-are-some-years-missing-ioccc-entries">FAQ 1.1: Why are some years missing IOCCC entries?</h3>
|
||
</div>
|
||
</div>
|
||
<p>Some years, such as 1997, 1999, 2002-2003, 2007-2010, 2016-2017, 2021-2023, no IOCCC was held.</p>
|
||
<p>While we try to hold the IOCCC every year, sometime the other demands on the IOCCC judges
|
||
do not permit us to hold a new IOCCC.</p>
|
||
<p>The pause during the 2021-2023 period was due to the IOCCC judges developing tools to
|
||
make is much more likely for the IOCCC to be held in a yearly basis later on.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq1_2">
|
||
<div id="website">
|
||
<div id="website_history">
|
||
<h3 id="faq-1.2-what-is-the-history-of-the-ioccc-website">FAQ 1.2: What is the history of the IOCCC website?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<h4 id="in-the-beginning-of-www.ioccc.org">In the beginning of www.ioccc.org</h4>
|
||
<p>The long history of the <a href="https://www.ioccc.org">official IOCCC website</a> can be
|
||
viewed at the <a href="https://web.archive.org">Internet Wayback Machine Wayback Machine</a>.</p>
|
||
<p>One can <a href="https://web.archive.org/web/20230000000000*/www.ioccc.org">view several thousand snapshots showing how the IOCCC website has
|
||
evolved</a> going back
|
||
as far as <a href="https://web.archive.org/web/19981212030016/https://www.ioccc.org/">1998 Dec 12
|
||
www.ioccc.org</a>.</p>
|
||
<p>On 2020 Dec 31, the IOCCC source tree was moved to the <a href="https://web.archive.org/web/20210101211346/https://www.ioccc.org/">IOCCC winner
|
||
repo</a> on
|
||
<a href="https://github.com">GitHub</a>. From this point on, the <a href="https://www.ioccc.org">official IOCCC web
|
||
site</a> became a <a href="https://pages.github.com">GitHub Pages</a>
|
||
website.</p>
|
||
<h4 id="dec-28-bzip2-compressed-tarball-archive">2020 Dec 28 bzip2 compressed tarball archive</h4>
|
||
<p>Furthermore, a bzip2 compressed tarball containing the released
|
||
IOCCC entry source code may be found under the
|
||
<a href="archive/historic/index.html">archive/historic</a> directory. The file
|
||
<a href="archive/historic/archive-all.tar.bz2">archive-all.tar.bz2</a> contains
|
||
all years and the individual years are in the form
|
||
<code>archive/historic/archive-YYYY.tar.bz2</code>.</p>
|
||
<p>These files were obtained from the <a href="https://web.archive.org">Internet Wayback
|
||
Machine</a> from the <a href="https://web.archive.org/web/20201228005211/https://www.ioccc.org/">snapshot of the website
|
||
on 2020 Dec
|
||
28</a>.
|
||
See <a href="archive/historic/index.html">archive/historic/index.html</a> for
|
||
details about these bzip2 compressed tarballs.</p>
|
||
<h4 id="dec-29-official-ioccc-winner-repo">2022 Dec 29 Official IOCCC winner repo</h4>
|
||
<p>The <a href="https://github.com/ioccc-src/winner">Official IOCCC winner repo</a>
|
||
was <a href="https://github.com/ioccc-src/winner/commit/28efc67f5dd692a3544708bf7fa26286adb82dfb">created on 2020 Dec
|
||
29</a>.</p>
|
||
<h4 id="dec-30-ioccc-content-uploaded-to-github">2020 Dec 30 IOCCC content uploaded to GitHub</h4>
|
||
<p>An <a href="https://www.ioccc.org/judges.html">IOCCC judge</a> formed a local
|
||
directory <a href="https://git-scm.com">git</a> repo on <strong>Tue Dec 29 23:48:30
|
||
2020 -0800</strong> via <a href="https://github.com/ioccc-src/winner/commit/28efc67f5dd692a3544708bf7fa26286adb82dfb">commit
|
||
28efc67f5dd692a3544708bf7fa26286adb82dfb</a>
|
||
and then on <strong>Wed Dec 30 16:57:03 2020 -0800</strong> added a preview of
|
||
1984-2019 via <a href="https://github.com/ioccc-src/winner/commit/c0663537cb88d39b74285a930ff1a668c6d5968b">commit
|
||
c0663537cb88d39b74285a930ff1a668c6d5968b</a>.</p>
|
||
<p>On 2020 Dec 30, with <a href="https://github.com/ioccc-src/winner/commit/c0663537cb88d39b74285a930ff1a668c6d5968b">commit
|
||
c0663537cb88d39b74285a930ff1a668c6d5968b</a>,
|
||
the <a href="https://web.archive.org/web/20221231001721/https://www.ioccc.org/">official IOCCC website of 2022 Dec
|
||
29</a> was
|
||
uploaded into the <a href="https://github.com/ioccc-src/winner">Official IOCCC winner
|
||
repo</a>.</p>
|
||
<h4 id="ioccc-winning-entries-released-using-git-via-github">2020 IOCCC winning entries released using git via GitHub</h4>
|
||
<p>The <a href="https://github.com/ioccc-src/winner/commit/9d61fc0fb4a3245afb1435458cfb597fad0e8e6a">winning
|
||
entries</a>
|
||
of the <a href="years.html#2020">IOCCC 2020</a>,
|
||
after a far too long of a delay
|
||
(due in part to a <a href="https://github.com/ioccc-src/winner/commit/c94fc84c35dc83e3eb9900720b95917a15c27afe">former IOCCC judge whose resignation was noted on
|
||
2021 Jan 04</a> commit)
|
||
from their initial <a href="https://web.archive.org/web/20200726232505/http://www.ioccc.org:80/index.html">2020 Jul 25
|
||
announcement</a>,
|
||
were added by an <a href="https://www.ioccc.org/judges.html">IOCCC judge</a>
|
||
to their local <a href="https://git-scm.com">git</a> repository and then were
|
||
merged into the <a href="https://github.com/ioccc-src/winner/commit/b1638ff0012964d79ab1c44aa815d3f824f35b6c">Official IOCCC winner repo on 2020 Dec
|
||
31</a>.</p>
|
||
<p>These <a href="years.html#2020">2020 IOCCC winning entries</a>,
|
||
as shown in the <a href="https://web.archive.org">Internet Wayback Machine</a>
|
||
<a href="https://web.archive.org/web/20210102042216/www.ioccc.org/years.html">snapshot of 2021 Jan 02</a>
|
||
were the first IOCCC entries to have been released via
|
||
<a href="https://git-scm.com">git</a> and <a href="https://github.com">GitHub</a>.</p>
|
||
<h4 id="dec-30-thru-202y-mmm-dd---work-on-the-temp-test-ioccc-github-repo">2020 Dec 30 thru 202y MMM DD - Work on the temp-test-ioccc GitHub repo</h4>
|
||
<p>Starting on <a href="https://github.com/ioccc-src/winner/commit/2f20ae8451ada03f4601ac727d10e1d8630861a8">2020 Dec
|
||
30</a>
|
||
edits to the <a href="https://github.com/ioccc-src/winner">Official IOCCC winner
|
||
repo</a> began.</p>
|
||
<p>The local <a href="https://git-scm.com">git</a> repository of an <a href="https://www.ioccc.org/judges.html">IOCCC
|
||
judge</a> was <a href="https://github.com/ioccc-src/winner/commit/c0663537cb88d39b74285a930ff1a668c6d5968b">edited starting Wed
|
||
Dec 30 16:57:03 2020
|
||
-0800</a>
|
||
and was occasionally committed to the <a href="https://github.com/ioccc-src/winner">Official IOCCC winner
|
||
repo</a>.</p>
|
||
<p>The <a href="https://github.com/ioccc-src/winner/pull/2">first accepted pull request</a> to
|
||
the <a href="https://github.com/ioccc-src/winner">Official IOCCC winner repo</a> was made
|
||
by <a href="https://www.ioccc.org/winners.html#Yusuke_Endoh">Yusuke Endoh</a> on <a href="https://github.com/ioccc-src/winner/commit/84c62c4cbf56ac1351ea91e5019f51103615fda2">2021 Jan
|
||
5</a>.</p>
|
||
<p>Between <a href="https://github.com/ioccc-src/winner/commit/c0663537cb88d39b74285a930ff1a668c6d5968b">Wed Dec 30 16:57:03 2020
|
||
-0800</a>
|
||
and <a href="https://github.com/ioccc-src/winner/commit/098a3e7e04d43e480ecc4b5482c83274e1434002">Sat Jan 29 21:56:53 2022
|
||
-0800</a>,
|
||
an <a href="https://www.ioccc.org/judges.html">IOCCC judge</a> made edits to
|
||
their local repository with occasional pushes to the <a href="https://github.com/ioccc-src/winner">Official IOCCC winner
|
||
repo</a> and the <a href="https://www.ioccc.org/index.html">Official
|
||
www.ioccc.org website</a>. After
|
||
that time and until the <strong>Great Fork Merge</strong>, very few changes
|
||
were made to the <a href="https://github.com/ioccc-src/winner">Official IOCCC winner
|
||
repo</a> and the <a href="https://www.ioccc.org/index.html">Official
|
||
www.ioccc.org website</a> most of
|
||
which were news updates.</p>
|
||
<p>While the <a href="https://github.com/ioccc-src/temp-test-ioccc">temp-test-ioccc
|
||
repo</a> has history
|
||
going back to <a href="https://github.com/ioccc-src/temp-test-ioccc/commit/28efc67f5dd692a3544708bf7fa26286adb82dfb">2020 Dec
|
||
29</a>,
|
||
the repo was forked on <strong>Sun Sep 18 17:30:00 2022 -0700</strong>. The
|
||
first <a href="https://github.com/ioccc-src/temp-test-ioccc/commit/edbc3089e1b755d85a020af7975bbc7df3737a5f">push into the temp-test-ioccc
|
||
repo</a>
|
||
occurred on Sun Sep 18 11:15:49 2022 -0700.</p>
|
||
<p>At this same time, the <a href="https://ioccc-src.github.io/temp-test-ioccc/">temp-test-ioccc website</a> went live.</p>
|
||
<p>Edits were made by an <a href="https://www.ioccc.org/judges.html">IOCCC judge</a>
|
||
to their local <a href="https://git-scm.com">git</a> repository and <a href="https://github.com/ioccc-src/temp-test-ioccc/commit/2f20ae8451ada03f4601ac727d10e1d8630861a8">were pushed into the temp-test-ioccc
|
||
repo</a>
|
||
and to the <a href="https://ioccc-src.github.io/temp-test-ioccc/">temp-test-ioccc website</a>.</p>
|
||
<p>The <a href="https://github.com/ioccc-src/temp-test-ioccc/pull/15">first accepted pull request</a>
|
||
made directly to the <a href="https://github.com/ioccc-src/temp-test-ioccc">temp-test-ioccc
|
||
repo</a> on
|
||
<a href="https://github.com/ioccc-src/temp-test-ioccc/commit/11bb36ac8ce790f32a9a3e5d2131ee12820fb8ec">Wed Feb 22 05:44:55 2023 -0800 with commit
|
||
11bb36ac8ce790f32a9a3e5d2131ee12820fb8ec</a>
|
||
by <a href="https://www.ioccc.org/winners.html#Cody_Boone_Ferguson">Cody Boone
|
||
Ferguson</a>.</p>
|
||
<p>A <a href="https://github.com/ioccc-src/temp-test-ioccc/discussions/1918">decision was made by the
|
||
IOCCC</a> to
|
||
mostly use frequent commits to individual components of the IOCCC,
|
||
rather than to use occasional site wide massive updates in order
|
||
to improve the tractability of changes made to components of the
|
||
IOCCC such as IOCCC entries although occasionally site wide updates
|
||
were performed in order to address an issue common to many IOCCC
|
||
entries. And while some people prefer infrequent updates to a repo
|
||
the <a href="https://www.ioccc.org/judges.html">IOCCC judges</a> believe
|
||
the ability to trace changes with commit messages is important.</p>
|
||
<p>Changes to the IOCCC content included things such as:</p>
|
||
<ul>
|
||
<li>Moving IOCCC entries into their own separate directories.</li>
|
||
<li>Establishing a detailed manifest for an IOCCC winning entries.</li>
|
||
<li>Fixing lots and lots of typos.</li>
|
||
<li>Fixing Makefiles and code to allow for nearly all winning entries to be
|
||
compiled with/in modern systems.</li>
|
||
<li>Fixing Makefiles and code to allow for nearly all winning entries to run
|
||
with/in modern systems.</li>
|
||
<li>Reworking the Makefiles to use a consistent set of rules.</li>
|
||
<li>Reworking the Makefiles specific to the gcc and clang C compilers.</li>
|
||
<li>Replacing the various hint files with a index.html markdown (from README.md
|
||
files) that is more consistent across IOCCC years.</li>
|
||
<li>Generating HTML content from markdown files and JSON data files via a <a href="bin/index.html">set of
|
||
tools and scripts</a>.</li>
|
||
<li>Setting up a system whereby authors of IOCCC entries may update their own
|
||
contact information via a <a href="https://github.com/ioccc-src/winner/pulls">GitHub pull
|
||
request</a>.</li>
|
||
<li>Setting up to generate the top level <a href="years.html">years.html</a> file via the
|
||
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/bin/gen-years.sh">gen-years.sh</a> tool.</li>
|
||
<li>Setting up to generate the top level <a href="authors.html">authors.html file</a>, renamed
|
||
from <code>winners.html</code>, via the <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/bin/gen-authors.sh">gen-authors.sh</a> tool.</li>
|
||
<li>Making use of a new and improved <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/ioccc.css">IOCCC CSS</a> for website consistency</li>
|
||
<li>Etc.</li>
|
||
</ul>
|
||
<div id="great_fork_merge_date">
|
||
<h4 id="y-mm-dd-the-great-fork-merge">202y mm dd The Great Fork Merge <!-- XXX - Fill in the date when Great Fork Merge happens --></h4>
|
||
</div>
|
||
<p>As of 2024 Sep 1 <a href="https://github.com/ioccc-src/temp-test-ioccc">temp-test-ioccc
|
||
repo</a>
|
||
there were <a href="https://github.com/ioccc-src/winner/compare/master...ioccc-src:temp-test-ioccc:master">5858 commits ahead</a>
|
||
of the <a href="https://github.com/ioccc-src/winner">IOCCC winner repo</a>.</p>
|
||
<p>On 202y mm dd, the temporary repo was merged back into the <a href="https://github.com/ioccc-src/winner">IOCCC winner
|
||
repo</a> resulting in many, many substantial improvements
|
||
to the <a href="https://www.ioccc.org">official IOCCC website</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq1_3">
|
||
<div id="size_rule">
|
||
<div id="size_restriction">
|
||
<h3 id="faq-1.3-how-has-the-ioccc-size-limit-rule-changed-over-the-years">FAQ 1.3: How has the IOCCC size limit rule changed over the years?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>The IOCCC size rule has changed over the years.</p>
|
||
<p>In later years, Rule 2 was split into two parts. These two parts of Rule 2 are:</p>
|
||
<ul>
|
||
<li>Rule 2a: Overall size limit of “prog.c”</li>
|
||
<li>Rule 2b: Size of “prog.c”, w/o counting certain types of characters</li>
|
||
</ul>
|
||
<div id="size_rule1984-1985">
|
||
<h4 id="ioccc-1984-1985">IOCCC 1984-1985</h4>
|
||
</div>
|
||
<p>NOTE: The size rule was actually rule 1.</p>
|
||
<ul>
|
||
<li>Rule 2a: 512</li>
|
||
<li>Rule 2b: n/a</li>
|
||
</ul>
|
||
<div id="size_rule1986-1987">
|
||
<h4 id="ioccc-1986-1987">IOCCC 1986-1987</h4>
|
||
</div>
|
||
<p>NOTE: The size rule was actually rule 1.</p>
|
||
<ul>
|
||
<li>Rule 2a: 1024</li>
|
||
<li>Rule 2b: n/a</li>
|
||
</ul>
|
||
<div id="size_rule1988-1991">
|
||
<h4 id="ioccc-1988-1991">IOCCC 1988-1991</h4>
|
||
</div>
|
||
<p>NOTE: The size rule was actually rule 1.</p>
|
||
<ul>
|
||
<li>Rule 2a: 1536</li>
|
||
<li>Rule 2b: n/a</li>
|
||
</ul>
|
||
<div id="size_rule1992-2000">
|
||
<h3 id="ioccc-1992-2000">IOCCC 1992-2000</h3>
|
||
</div>
|
||
<ul>
|
||
<li>Rule 2a: 3217</li>
|
||
<li>Rule 2b: 1536</li>
|
||
</ul>
|
||
<div id="size_rule2001-2012">
|
||
<h3 id="ioccc-2001-2012">IOCCC: 2001-2012</h3>
|
||
</div>
|
||
<ul>
|
||
<li>Rule 2a: 4096</li>
|
||
<li>Rule 2b: 2048</li>
|
||
</ul>
|
||
<div id="size_rule2013-2020">
|
||
<h3 id="ioccc-2013-2020">IOCCC 2013-2020</h3>
|
||
</div>
|
||
<ul>
|
||
<li>Rule 2a: 4096</li>
|
||
<li>Rule 2b: 2053</li>
|
||
</ul>
|
||
<div id="size_rule2024-xxxx">
|
||
<h3 id="ioccc-2024-date">IOCCC 2024-date</h3>
|
||
</div>
|
||
<ul>
|
||
<li>Rule 2a: 4993</li>
|
||
<li>Rule 2b: 2503</li>
|
||
</ul>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq1_4">
|
||
<div id="great_fork_merge">
|
||
<h3 id="faq-1.4-what-is-the-great-fork-merge">FAQ 1.4: What is the <strong>Great Fork Merge</strong>?</h3>
|
||
</div>
|
||
</div>
|
||
<p>The <strong>Great Fork Merge</strong> was when thousands of changes that had been applied to the
|
||
<a href="https://github.com/ioccc-src/temp-test-ioccc">temp-test-ioccc repo</a> was applied
|
||
to the <a href="https://github.com/ioccc-src/winner">Official IOCCC winner repo</a> causing the
|
||
<a href="index.html">Official IOCCC website</a> to be updated into its present form.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#great_fork_merge_date">Great Fork Merge Date</a>”
|
||
for more information.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq2">
|
||
<h2 id="section-2-ioccc-judging-process">Section 2: IOCCC Judging process</h2>
|
||
</div>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq2_0">
|
||
<div id="how_many">
|
||
<h3 id="faq-2.0-how-many-entries-do-the-judges-receive-for-a-given-ioccc">FAQ 2.0: How many entries do the judges receive for a given IOCCC?</h3>
|
||
</div>
|
||
</div>
|
||
<p>By tradition, we do not say.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq2_1">
|
||
<div id="remarks_md">
|
||
<div id="remarks">
|
||
<div id="readme">
|
||
<h3 id="faq-2.1-what-should-i-put-in-the-remarks.md-file-of-my-submission">FAQ 2.1: What should I put in the remarks.md file of my submission?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>First, <strong>PLEASE</strong> read the <a href="markdown.html">IOCCC markdown guidelines</a>.</p>
|
||
<p>Next, while you may put in as much or as little as you wish into your entry’s
|
||
<code>remarks.md</code> file, we do have few important suggestions:</p>
|
||
<p>We recommend that you explain how to use your entry. Explain the
|
||
command line (if any command line options and arguments are used)
|
||
and any input or actions if applicable.</p>
|
||
<p>We highly recommend that you explain why you think your entry is
|
||
well obfuscated.</p>
|
||
<p>For those entries that win the IOCCC, we often use much of text from the
|
||
<code>remarks.md</code> file in the <em>Author’s remarks</em> section of the <code>index.html</code> file.
|
||
For this reason, a well written <code>remarks.md</code> file is considered a plus.</p>
|
||
<p>While not required, consider adding bit of humor to your <code>remarks.md</code>
|
||
as most people who are not humor impaired, as well as the IOCCC judges
|
||
appreciate the opportunity for a fun read as well as a chuckle or two.</p>
|
||
<h4 id="what-helps">What helps:</h4>
|
||
<ul>
|
||
<li>explaining what your entry does</li>
|
||
<li>how to entice it to do what it is supposed to do</li>
|
||
<li>what obfuscations are used</li>
|
||
<li>what are the limitations of your entry in respect of portability and/or input data</li>
|
||
<li>how it works (if you are really condescending)</li>
|
||
</ul>
|
||
<h4 id="what-does-not-help">What does not help:</h4>
|
||
<ul>
|
||
<li>admitting that your entry is not very obfuscated (you see, the contest is
|
||
called the <strong>IOCCC</strong>, not the <strong>INVOCCC</strong> :-) ); but even if you do not admit
|
||
it, not very obfuscated entries have a minuscule chance to win (although
|
||
<a href="2000/tomx/index.html">2000/tomx</a> is a notable counterexample).</li>
|
||
<li>mentioning your name or any identifying information in the remark section (or
|
||
in the C code for that matter) - we like to be unbiased during the judging
|
||
rounds; we look at the author name only if an entry wins. See the guidelines if
|
||
this is not clear!</li>
|
||
<li>leaving the remark section empty.</li>
|
||
</ul>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq2_2">
|
||
<div id="losing_submissions">
|
||
<h3 id="faq-2.2-why-dont-you-publish-submissions-that-do-not-win">FAQ 2.2: Why don’t you publish submissions that do not win?</h3>
|
||
</div>
|
||
</div>
|
||
<p>Because the publication on the IOCCC site <strong><em>IS</em></strong> the award!
|
||
Anyone is free to put their IOCCC hopefuls, lookalikes and/or
|
||
entries that do not win on their web page for everyone to see.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq2_3">
|
||
<div id="judging_time">
|
||
<h3 id="faq-2.3-how-much-time-does-it-take-to-judge-the-contest">FAQ 2.3: How much time does it take to judge the contest?</h3>
|
||
</div>
|
||
</div>
|
||
<p>It takes a fair amount of time to setup, run, respond to messages, process entries,
|
||
review entries, trim down the set entries to a set of winning entries, doing the
|
||
write-up of the entries, announcing the entries, reviewing final edits of the
|
||
winning entry set, posting the winning entries, being flamed :-), tell folks who send in
|
||
late entries to wait until the next contest, etc… It takes a few weekends and
|
||
a number nights of study and work … which is hard given that we are busy with
|
||
many other activities as well.</p>
|
||
<p>Note that we do not contact the author if an entry does not compile or does not
|
||
work as advertised, we might attempt to fix obvious compilation problems or
|
||
incompatibilities, but no more than that - so be sure that your entry does work
|
||
on at least a couple different platforms, at least one of them being UNIX or
|
||
POSIX-conforming.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq2_4">
|
||
<div id="rounds">
|
||
<div id="judging_rounds">
|
||
<h3 id="faq-2.4-how-many-judging-rounds-do-you-have">FAQ 2.4: How many judging rounds do you have?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>Are you trying to trick us? :-)</p>
|
||
<p>By tradition, we do not say how many judging rounds we have in a given IOCCC.</p>
|
||
<p>We often report when the IOCCC judges start the 1st round, and when usually
|
||
report when the IOCCC judges start near final judging rounds, and sometimes we
|
||
also report when we enter what we believe is the final judging round, so you may
|
||
guess that we have at least 3 rounds. :-) The actual number of rounds is
|
||
certainly more than 3.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq2_5">
|
||
<div id="best">
|
||
<div id="best_of_show">
|
||
<div id="grand_prize">
|
||
<h3 id="faq-2.5-why-do-some-ioccc-entries-receive-the-grand-prize-or-best-of-show-award">FAQ 2.5: Why do some IOCCC entries receive the Grand Prize or Best of Show award?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>In some years, the IOCCC judges discover a truly amazing IOCCC entry that
|
||
stands out among all of the other IOCCC entries received that year.
|
||
For such an IOCCC entry, the IOCCC judges award a “Grand Prize”
|
||
or “Best of Show award.</p>
|
||
<p>In 1984-1987, the grand prize winning entries are:</p>
|
||
<ul>
|
||
<li><a href="years.html#1984_mullender">1984/mullender</a></li>
|
||
<li><a href="years.html#1985_shapiro">1985/shapiro</a></li>
|
||
<li><a href="years.html#1986_wall">1986/wall</a></li>
|
||
<li><a href="years.html#1987_lievaart">1987/lievaart</a></li>
|
||
</ul>
|
||
<p>Starting from 1988, the entry we liked the most in that year is called
|
||
“Best of Show”. Here are the “Best of Show” entries:</p>
|
||
<ul>
|
||
<li><a href="years.html#1988_applin">1988/applin</a></li>
|
||
<li><a href="years.html#1989_jar.2">1989/jar.2</a></li>
|
||
<li><a href="years.html#1990_theorem">1990/theorem</a></li>
|
||
<li><a href="years.html#1991_brnstnd">1991/brnstnd</a></li>
|
||
<li><a href="years.html#1992_vern">1992/vern</a></li>
|
||
<li><a href="years.html#1996_august">1996/august</a></li>
|
||
<li><a href="years.html#1998_banks">1998/banks</a></li>
|
||
<li><a href="years.html#2000_jarijyrki">2000/jarijyrki</a></li>
|
||
<li><a href="years.html#2020_carlini">2020/carlini</a></li>
|
||
</ul>
|
||
<p>In 1993, 1994 and 1995 the judges were unable to select a clear overall
|
||
winning entry. So to give a nod to the entry that had the highest approval ranking
|
||
from the judges, they used the following awards:</p>
|
||
<ul>
|
||
<li><a href="years.html#1993_rince">1993/rince</a> - Most Well Rounded</li>
|
||
<li><a href="years.html#1994_shapiro">1994/shapiro</a> - Most Well Rounded</li>
|
||
<li><a href="years.html#1995_leo">1995/leo</a> - Best Use of Obfuscation</li>
|
||
</ul>
|
||
<p>These could be considered the ‘best entry’ for those years with 1 or
|
||
more other entries that came in close behind.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq2_6">
|
||
<div id="announcing_winners">
|
||
<div id="announce">
|
||
<div id="winners">
|
||
<h3 id="faq-2.6-how-are-ioccc-entries-announced">FAQ 2.6: How are IOCCC entries announced?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>Once the <a href="index.html">IOCCC</a> closes, the judges will:</p>
|
||
<ul>
|
||
<li><p>Select the <a href="years.html">winning entries</a> announce them on the <a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span>
|
||
mastodon feed</a>.</p></li>
|
||
<li><p>Notify the authors of entries that won the IOCCC via email using their previously
|
||
registered email address.</p></li>
|
||
<li><p>Announce who are authors of this year’s winning IOCCC entries via the <a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> mastodon
|
||
feed</a>.</p></li>
|
||
<li><p>Upload the winning code to the <a href="https://github.com/ioccc-src/winner">Official IOCCC winner repo</a></p></li>
|
||
<li><p>Update the <a href="index.html">Official IOCCC website</a>, and in particular
|
||
display this year’s winning IOCCC entries at the top of the <a href="years.html">IOCCC
|
||
winning entries page</a>.</p></li>
|
||
<li><p>Update the <a href="news.html">IOCCC news</a> page.</p></li>
|
||
</ul>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3">
|
||
<h2 id="section-3-compiling-and-running-ioccc-entries">Section 3: Compiling and running IOCCC entries</h2>
|
||
</div>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_0">
|
||
<div id="make_rules">
|
||
<div id="makefile_rules">
|
||
<h3 id="faq-3.0-what-makefile-rules-are-available-to-build-or-clean-up-ioccc-entries">FAQ 3.0: What Makefile rules are available to build or clean up IOCCC entries?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>In general the best way to compile everything in an entry directory is to run:</p>
|
||
<pre><code> make clobber all</code></pre>
|
||
<p>If you wish to compile every entry for every year you should go to the top level
|
||
directory and run the same command as above, <code>make clobber all</code>.</p>
|
||
<p>The <code>all</code> rule will build everything necessary except for the alternate
|
||
versions. Every Makefile has an <code>alt</code> rule but it will only do something if an
|
||
alternate version exists. To build all the entries along with any alternate code
|
||
you can do from the top level directory:</p>
|
||
<pre><code> make clobber everything</code></pre>
|
||
<p>If you wish to only build alternate code you can do:</p>
|
||
<pre><code> make clobber alt</code></pre>
|
||
<p>If you wish to not remove the entry binaries and only compile the additional alt
|
||
versions:</p>
|
||
<pre><code> make alt</code></pre>
|
||
<p>The following Makefile rules should be in all Makefiles:</p>
|
||
<ul>
|
||
<li>all: build the entry programs (main program and any supplementary program)</li>
|
||
<li>alt: build alternate code</li>
|
||
<li>clobber: clean up object files and all binary files (except for those that are
|
||
not compiled)</li>
|
||
<li>clean: a simpler version of <code>clobber</code> that only removes object files. <code>make clobber</code> depends on <code>clean</code> so running <code>make clobber</code> will invoke <code>make clean</code>.</li>
|
||
<li>everything: equivalent to <code>make all alt</code>.</li>
|
||
</ul>
|
||
<p>Are there any other rules? You tell us!</p>
|
||
<p>The top level and the year (e.g. <code>1984/Makefile</code>, <code>1985/Makefile</code> etc.)
|
||
<code>Makefile</code>s recurse into the subdirectories for each entry so you can compile
|
||
individual entries, entries of a given year or all entries, based on what you
|
||
wish to do.</p>
|
||
<p>NOTE about the above rules: the Makefile default assumes <code>cc</code> which might be a
|
||
gcc-based compiler, or a clang-based compiler, or some other compiler. Only by
|
||
forcing <code>CC=clang</code> or <code>CC=gcc</code> will one invoke a specific compiler to, say,
|
||
enable or disable additional warnings or flags. Even so different versions or
|
||
compilers might do different things, have different defects or other issues.
|
||
Note that the <code>Makefile</code>s check the <code>CC</code> variable by substrings so that if you
|
||
were to do something like <code>make CC=gcc=mp-12</code> it would register as <code>gcc</code>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_1">
|
||
<div id="compile">
|
||
<div id="compile_errors">
|
||
<h3 id="faq-3.1-why-doesnt-an-ioccc-entry-compile">FAQ 3.1: Why doesn’t an IOCCC entry compile?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>Some entries that won the IOCCC, particularly entries from long ago, no longer compile on more
|
||
modern systems because the C language has evolved (i.e. the modern C compilers
|
||
are much more strict in what they accept as a valid program), or the entry
|
||
depended on operation system and library features that where common back then
|
||
but are different/missing today.</p>
|
||
<p>Please see the other FAQs in this section as they might offer helpful
|
||
hints, especially in cases were something else needs to be installed.</p>
|
||
<p>Please see the <a href="bugs.html">bugs.html</a> file for details about known problems with IOCCC entries. In some cases you may be dealing with a problematic entry. In a few fun cases, the IOCCC does not compile by design!</p>
|
||
<p>If you have a fix that makes a minimal impact to the entry, then
|
||
please consider submitting that change in the form of a pull request.
|
||
Please see
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”.
|
||
See also the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information about pull requests.</p>
|
||
<p>In some cases alternative code has been added that does compile on some or most
|
||
systems. Check the write up for the entry for “alt” code and possible ways to
|
||
compile and run that code. In some cases we replaced the original code (but not
|
||
the <code>.orig.c</code> file!) with code that works for modern systems but one can view
|
||
the original code in the <code>.orig.c</code> files (sometimes the original code is also in
|
||
the directory as a <code>dirname.alt.c</code> or <code>prog.alt.c</code>).</p>
|
||
<p>See the
|
||
FAQ on “<a href="#original_source_code">original source code</a>”
|
||
for more information.</p>
|
||
<p>It might also be worth noting that almost all entries, have been
|
||
fixed so that they can compile in modern systems though just because an entry
|
||
compiles does not mean it will run on your specific system.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_2">
|
||
<div id="64bit">
|
||
<div id="64-bit">
|
||
<h3 id="faq-3.2-why-does-an-ioccc-entry-fail-on-my-64-bit-system">FAQ 3.2: Why does an IOCCC entry fail on my 64-bit system?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>Unfortunately some older entries are non-portable and require 32-bit support or
|
||
32-bit binaries. A problem system here is macOS Catalina (10.15) as as of that
|
||
version macOS no longer supports 32-bit binaries. If the entry acts on a certain
|
||
type of binary, say ELF, then that will also be a problem depending on the
|
||
entry. For example <a href="2001/anonymous/index.html">2001/anonymous</a> requires 32-bit
|
||
ELF binaries.</p>
|
||
<p>There are a few example entries that require 32-bit binaries. We have tried
|
||
to note these in both the respective Makefiles and index.html files but it is
|
||
possible that some were missed. These entries are very likely in the
|
||
<a href="bugs.html">bugs.html</a> file and we welcome any help in making an alternate version
|
||
for 64-bit systems. Many were fixed to work with modern systems but some are
|
||
supposed to only work with 32-bit systems so any updated version of these
|
||
entries should be an alternate version.</p>
|
||
<p>Other entries like <a href="thanks-for-help.html#2001_herrmann2">2001/herrmann2</a>
|
||
now work with 32-bit AND 64-bit systems.</p>
|
||
<p>Please see the <a href="bugs.html">bugs.html</a> file for the problematic entry
|
||
in question to see if the problem is known, and if a fix is wanted,
|
||
consider trying to port the code to a 64-bit system and submitting
|
||
a pull request with that change. Pull requests that fix such code
|
||
while trying to minimize the impact of any changes and preserving
|
||
the spirit of the original code are very welcome! Please see the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”
|
||
for details. See also the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information about pull requests.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_3">
|
||
<div id="macos">
|
||
<div id="macos_errors">
|
||
<h3 id="faq-3.3-why-do-some-ioccc-entries-fail-to-compile-under-macos">FAQ 3.3: Why do some IOCCC entries fail to compile under macOS?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>If the entry requires gcc and you did not explicitly install gcc in macOS you
|
||
will not be able to run or use these entries. This is because macOS gcc is
|
||
actually clang, even <code>/usr/bin/gcc</code>.</p>
|
||
<p>That being said many (if not most) of these entries have been fixed and some
|
||
others will be looked at, when found.</p>
|
||
<p>In some cases the <a href="bugs.html">bugs.html</a> file may note a known macOS problem
|
||
with an entry. Should you manage to port the entry, and assuming your changes
|
||
also attempt to preserve the original intent of the IOCCC entry, we would
|
||
encourage you to submit a pull request with your ported code.
|
||
Please see the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”
|
||
for details.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_4">
|
||
<div id="gcc">
|
||
<div id="clang">
|
||
<h3 id="faq-3.4-why-does-clang-or-gcc-fail-to-compile-an-ioccc-entry">FAQ 3.4: Why does clang or gcc fail to compile an IOCCC entry?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>Although we have fixed numerous entries to work with clang (sometimes in an alt
|
||
version but usually in the program itself) there are some that simply cannot be
|
||
fixed or if they are fixable they have not yet been fixed (we are working on
|
||
this but other things have to be done too and all on free time).</p>
|
||
<p>This is because clang has some defects where the args of main() are required to
|
||
be a specific type and some versions of clang allow only 1, 2 or 3 args, not 4,
|
||
to main(). In the case of types of args many were changed to the right type and
|
||
then what was main() became another function of the original main() type.</p>
|
||
<p>At the same time some entries are not designed to work with clang. There might
|
||
be alternate code added at some point but as above this depends on free time and
|
||
other things that have to be done plus remembering to do it.</p>
|
||
<p>See if the problem is mentioned in <a href="bugs.html">bugs.html</a>. If you have a change
|
||
that fixes the problem (even if it just a change to the <code>Makefile</code>) that doesn’t
|
||
negatively impact the entry too much, consider submitting that change in the
|
||
form of a pull request. Please see the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”.
|
||
See also the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information about pull requests.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_5">
|
||
<div id="cb">
|
||
<h3 id="faq-3.5-what-is-this-cb-tool-that-is-mentioned-in-the-ioccc">FAQ 3.5: What is this cb tool that is mentioned in the IOCCC?</h3>
|
||
</div>
|
||
</div>
|
||
<p>This was a C beautifier for Unix, both AT&T and Berkeley, but it seems to no
|
||
longer be available, code wise, except for Plan 9, but Plan 9 was never used for
|
||
judging the IOCCC. A Unix man page for <code>cb</code>
|
||
<a href="https://www.ibm.com/docs/en/aix/7.3?topic=c-cb-command">still exists</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_6">
|
||
<div id="terminal">
|
||
<div id="sanity">
|
||
<div id="reset">
|
||
<div id="stty">
|
||
<h3 id="faq-3.6-an-ioccc-entry-messed-up-my-terminal-application-how-do-i-fix-this">FAQ 3.6: An IOCCC entry messed up my terminal application, how do I fix this?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>The simplest way to do this is to type <code>reset</code>. If echo was disabled you can get
|
||
usually away with <code>stty echo</code>. Sometimes you can also get away with <code>stty sane</code>.
|
||
<code>reset</code> does the most but note that it will clear the screen (obviously <code>clear</code>
|
||
will too but it won’t reset the terminal).</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_7">
|
||
<div id="X11macOS">
|
||
<div id="X11">
|
||
<h3 id="faq-3.7-how-do-i-run-an-ioccc-entry-that-requires-x11">FAQ 3.7: How do I run an IOCCC entry that requires X11?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div id="X11_general">
|
||
<h4 id="generally-to-compile-and-run-an-ioccc-entry-that-requires-x11">Generally, to compile and run an IOCCC entry that requires X11:</h4>
|
||
</div>
|
||
<p>You must have the X11 related include files and X11 libraries in order to
|
||
compile the IOCCC entry. In order to do this you will need to install Xorg and
|
||
related packages including development related packages. If you have macOS see
|
||
further down for different instructions. Otherwise: in particular you must:</p>
|
||
<ul>
|
||
<li>Install the Xorg server.</li>
|
||
<li>Configure the Xorg server for your graphics environment.</li>
|
||
<li>Install a X11 terminal application.</li>
|
||
<li>Start the Xorg server.</li>
|
||
<li>Launch the X11 terminal application.</li>
|
||
<li>Run the IOCCC entry in the X11 terminal application.</li>
|
||
</ul>
|
||
<p>By X11 terminal application we suggest one of:</p>
|
||
<ul>
|
||
<li><a href="https://www.gnome.org">Gnome</a> terminal application</li>
|
||
<li><a href="https://kde.org">KDE</a> terminal application</li>
|
||
<li><code>xterm(1)</code> terminal application</li>
|
||
</ul>
|
||
<p>See below for various system related hints that may be of help.</p>
|
||
<div id="Xorg_deprecated">
|
||
<h4 id="x.org-server-has-been-deprecated">X.org server has been deprecated</h4>
|
||
</div>
|
||
<p>The Red Hat RHEL9.0 release notes state that <a href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.0_release_notes/deprecated_functionality#deprecated-functionality_graphics-infrastructures">X.org Server is now
|
||
deprecated</a>.</p>
|
||
<p>According to this <a href="https://www.linuxfordevices.com/tutorials/linux/install-xorg-on-linux">Linux for Devices tutorial on
|
||
XOrg</a> as
|
||
of 2023 Mar 25:</p>
|
||
<blockquote>
|
||
<p>Recently, RHEL developers categorized <a href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.0_release_notes/deprecated_functionality">Xorg was put in the ‘deprecated’
|
||
software</a>,
|
||
as its development has mostly halted. Subsequent updates will completely replace
|
||
it with Wayland, a more modern windowing system.. Although Wayland is not fully
|
||
developed yet, many applications do not support it properly yet and screen
|
||
sharing might not work sometime, but it is the future. Fedora, also developed by
|
||
RHEL, has switched to a Wayland session as it’s default windowing system (And it
|
||
works flawlessly on my Laptop).</p>
|
||
</blockquote>
|
||
<p>See the <a href="https://wayland.freedesktop.org">Wayland</a> website for more details.</p>
|
||
<p><strong>IMPORTANT NOTE</strong>: We do <strong>NOT</strong> know if IOCCC entries will run under
|
||
<strong>Wayland</strong>. Some IOCCC entries that use X11 might be OK while other IOCCC
|
||
entries that use X11 in an unusual way might fail under <strong>Wayland</strong>.</p>
|
||
<p>See the <a href="https://wayland.freedesktop.org/faq.html">Wayland FAQ</a> for more
|
||
information.</p>
|
||
<p>If your system uses <strong>Wayland</strong> and not X11, you might give the IOCCC entries
|
||
that use X11 a try. They might work but again we do not know.</p>
|
||
<p><strong>IMPORTANT NOTE</strong>: The <a href="judges.html">IOCCC judges</a> <strong>do not support IOCCC entries</strong>.
|
||
See the
|
||
FAQ on “<a href="#no_support">no entry support</a>”.
|
||
So if an IOCCC entry that uses X11 fails under <strong>Wayland</strong>, and you wish to
|
||
provide a fix to the IOCCC entry so that it will run under <strong>Wayland</strong>,
|
||
then consider submitting a fix so that it will run under <strong>Wayland</strong>.
|
||
See the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”
|
||
for more information.</p>
|
||
<p>Basically: if you discover an entry does not work in Wayland you are welcome to
|
||
provide <strong>alternate code</strong> that works for Wayland. We will happily credit you in
|
||
the <a href="thanks-for-help.html">thanks-for-help.html</a> file.</p>
|
||
<h4 id="red-hat-based-linux">Red Hat based Linux</h4>
|
||
<p>First, see the
|
||
FAQ on “<a href="#X11_general">general X11</a>”.</p>
|
||
<p>Install Xorg and related packages:</p>
|
||
<pre><code> sudo dnf install --skip-broken --best --exclude xorgxrdp --exclude xorgxrdp-glamor '*xorg*' 'libx*' 'libX*' 'fontconfig*'</code></pre>
|
||
<p>See also:</p>
|
||
<ul>
|
||
<li><a href="https://www.wikihow.com/Configure-X11-in-Linux">How to Configure X11 in Linux</a></li>
|
||
</ul>
|
||
<p><strong>IMPORTANT NOTE</strong>: The X.org server has been deprecated.
|
||
See the
|
||
FAQ on “<a href="#Xorg_deprecated">X.org deprecated</a>”
|
||
for more information.</p>
|
||
<h4 id="macos">macOS</h4>
|
||
<p>First, see the
|
||
FAQ on “<a href="#X11_general">general X11</a>”.
|
||
However, for macOS, instead of installing the Xorg server, you need to install and launch
|
||
the <a href="https://www.xquartz.org">most recent XQuartz</a> application
|
||
and then run the IOCCC entry from the <a href="https://en.wikipedia.org/wiki/Xterm">Xterm window
|
||
shell</a>.</p>
|
||
<p>As an example we will use <a href="1993/jonth/index.html">1993/jonth</a> which works
|
||
with macOS 14.2.1 (macOS Sonoma).</p>
|
||
<p>First of all you will need to install the <a href="https://www.xquartz.org">most recent
|
||
XQuartz</a>, preferably on an <a href="https://support.apple.com/macOS">Apple supported version of
|
||
macOS, preferably the most recent version</a>.
|
||
After it is installed, open the “XQuartz” application (usually located in
|
||
<code>/Applications/Utilities/XQuartz.app</code>) by typing at the command line:</p>
|
||
<pre><code> open /Applications/Utilities/XQuartz.app</code></pre>
|
||
<p>With the “XQuartz” application open you will get an <a href="https://www.x.org/wiki/">X Window System
|
||
Manager</a> launched with an <a href="https://en.wikipedia.org/wiki/Xterm">Xterm window
|
||
shell</a> started:</p>
|
||
<p><img alt="xterm-launch in macOS" src="png/xquartz-shell.png"></p>
|
||
<p>At this point you need to cd to the winning directory and compile it. For example:</p>
|
||
<p><img alt="compiling an entry in xterm in macOS" src="png/xquartz-entry-compile.png"></p>
|
||
<p>And then run the program as directed by the <code>index.html</code> file. For example with
|
||
<code>1993/jonth</code>:</p>
|
||
<p><img alt="running 1993/jonth in macOS" src="png/xquartz-1993-jonth.png"></p>
|
||
<p>Note that you can compile the code in your regular terminal prior to opening
|
||
XQuartz, should you wish to. You can even run it from that terminal and it
|
||
should open XQuartz.</p>
|
||
<p><strong>IMPORTANT NOTE</strong>: The X.org server has been deprecated.
|
||
See the
|
||
FAQ on “<a href="#Xorg_deprecated">X.org deprecated</a>”
|
||
for more information.</p>
|
||
<h4 id="debian-based-linux">Debian based Linux</h4>
|
||
<p>First, see the
|
||
FAQ on “<a href="#X11_general">general X11</a>”.</p>
|
||
<p>According to the <a href="https://wiki.debian.org/Xorg">Debian Xorg wiki</a>, installing
|
||
X11 requires:</p>
|
||
<pre><code> sudo apt install xorg</code></pre>
|
||
<p><strong>IMPORTANT NOTE</strong>: The X.org server has been deprecated.
|
||
See the
|
||
FAQ on “<a href="#Xorg_deprecated">X.org deprecated</a>”
|
||
for more information.</p>
|
||
<h4 id="other-linux-distributions">Other Linux distributions</h4>
|
||
<p>First, see the
|
||
FAQ on “<a href="#X11_general">general X11</a>”.</p>
|
||
<p>For general documentation on installing X11, this <a href="https://help.ubuntu.com/community/ServerGUI">ServerGUI for
|
||
Ubuntu</a>, and in particular, these
|
||
may be helpful:</p>
|
||
<ul>
|
||
<li><a href="https://help.ubuntu.com/community/ServerGUI#X11_Client_Installation">X11 Client Installation</a></li>
|
||
<li><a href="https://help.ubuntu.com/community/ServerGUI#X11_Server_Installation">X11 Server Installation</a></li>
|
||
<li><a href="https://help.ubuntu.com/community/ServerGUI#Full_Desktop_Environments">Full Desktop Environments</a></li>
|
||
</ul>
|
||
<p>See also:</p>
|
||
<ul>
|
||
<li><a href="https://www.wikihow.com/Configure-X11-in-Linux">How to Configure X11 in Linux</a></li>
|
||
</ul>
|
||
<p>For systems that have the <code>dnf(1)</code> command:</p>
|
||
<pre><code> sudo dnf install --skip-broken --best --exclude xorgxrdp --exclude xorgxrdp-glamor '*xorg*' 'libx*' 'libX*' 'fontconfig*'</code></pre>
|
||
<p>For systems that have the <code>yum(1)</code> command:</p>
|
||
<pre><code> sudo yum install --skip-broken --best --exclude xorgxrdp --exclude xorgxrdp-glamor '*xorg*' 'libx*' 'libX*' 'fontconfig*'</code></pre>
|
||
<p><strong>IMPORTANT NOTE</strong>: The X.org server has been deprecated.
|
||
See the
|
||
FAQ on “<a href="#Xorg_deprecated">X.org deprecated</a>”
|
||
for more information.</p>
|
||
<h4 id="package-website">Package website</h4>
|
||
<p>First, see the
|
||
FAQ on “<a href="#X11_general">general X11</a>”.</p>
|
||
<p>See the <a href="https://x.org/wiki/">X.org</a> foundation website.</p>
|
||
<p><strong>IMPORTANT NOTE</strong>: The X.org server has been deprecated.
|
||
See the
|
||
FAQ on “<a href="#Xorg_deprecated">X.org deprecated</a>”
|
||
for more information.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_8">
|
||
<div id="SDL">
|
||
<h3 id="faq-3.8-how-do-i-compile-an-ioccc-entry-that-requires-sdl1-or-sdl2">FAQ 3.8: How do I compile an IOCCC entry that requires SDL1 or SDL2?</h3>
|
||
</div>
|
||
</div>
|
||
<p>This depends on your operating system but below are instructions for Linux and
|
||
macOS with alternative methods for macOS and different package managers with Linux.</p>
|
||
<h4 id="red-hat-based-linux-1">Red Hat based Linux</h4>
|
||
<p>Execute the following as root or via sudo:</p>
|
||
<pre><code> dnf install SDL2 SDL2-devel sdl12-compat sdl12-compat-devel</code></pre>
|
||
<p>Older RHEL distributions might have to use “yum” instead of “dnf”
|
||
in the above command.</p>
|
||
<p>In the past it was said that one might need to run <code>make</code> like:</p>
|
||
<pre><code> make ... SDL2_INCLUDE_ROOT=/usr</code></pre>
|
||
<p>or set the following environment variable:</p>
|
||
<pre><code> export SDL2_INCLUDE_ROOT=/usr</code></pre>
|
||
<p>but this might not be necessary in more modern days especially as we use
|
||
<code>sdl-config</code> and <code>sdl2-config</code> which should find the proper paths.</p>
|
||
<div id="X11macos">
|
||
<h4 id="macos-1">macOS</h4>
|
||
</div>
|
||
<p>If you’re using macOS there are at least three ways to obtain it. You can
|
||
use Homebrew or MacPorts. If you do not wish to use either of those
|
||
package managers, you can always try to install via the package website.
|
||
For macOS we do recommend using Homebrew or MacPorts instead of using
|
||
the package website.</p>
|
||
<h5 id="macos-via-homebrew">macOS via Homebrew</h5>
|
||
<p>If you have not already done so, install <a href="https://brew.sh">Homebrew</a>.</p>
|
||
<p>Then to install SDL and SDL2, execute the following command:</p>
|
||
<pre><code> brew install sdl2 sdl12-compat
|
||
eval "$(opt/homebrew/bin/brew shellenv)"</code></pre>
|
||
<h5 id="macos-via-macports">macOS via MacPorts</h5>
|
||
<p>If you haven’t already, install
|
||
<a href="https://www.macports.org/install.php">MacPorts</a>. Then run:</p>
|
||
<pre><code> sudo port install libsdl libsdl2</code></pre>
|
||
<h4 id="debian-based-linux-1">Debian based Linux</h4>
|
||
<p>Execute the following as root or via sudo:</p>
|
||
<pre><code> apt install libsdl1.2debian libsdl1.2-dev libsdl2-dev</code></pre>
|
||
<p>and then try <code>make all</code> again.</p>
|
||
<p>In the past it was said that one might need to run <code>make</code> like:</p>
|
||
<pre><code> make ... SDL2_INCLUDE_ROOT=/usr</code></pre>
|
||
<p>or set the following environment variable:</p>
|
||
<pre><code> export SDL2_INCLUDE_ROOT=/usr</code></pre>
|
||
<p>but this might not be necessary in more modern days especially as we use
|
||
<code>sdl-config</code> and <code>sdl2-config</code> which should find the proper paths.</p>
|
||
<h4 id="other-linux-distributions-1">Other Linux distributions</h4>
|
||
<p>Use your package manager to install the appropriate packages. Try the search
|
||
feature of the package manager to determine which packages you need to install.
|
||
Note that you might have to install both the library and the developmental
|
||
packages: one for compiling and one for linking / running.</p>
|
||
<h4 id="package-website-1">Package website</h4>
|
||
<p>Go to the <a href="https://www.libsdl.org">SDL website</a> and follow their instructions
|
||
for downloading, installing and using SDL.</p>
|
||
<p>We recommend trying a method suitable for your environment first, if possible.</p>
|
||
<h4 id="note-there-might-be-extra-sdl-packages-required">NOTE: there might be extra SDL packages required</h4>
|
||
<p>In the case that some entries do not work even with SDL1/SDL2 installed it might
|
||
be that you need additional SDL libraries. See the entry’s index.html for
|
||
details. If something is not noted you’re welcome to report it as an issue or
|
||
fix it and make a pull request.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information about pull requests.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_9">
|
||
<div id="curses">
|
||
<h3 id="faq-3.9-how-do-i-compile-an-ioccc-entry-that-requires-ncurses">FAQ 3.9: How do I compile an IOCCC entry that requires (n)curses?</h3>
|
||
</div>
|
||
</div>
|
||
<p>This depends on your operating system but below are instructions for Linux and
|
||
macOS with alternative methods for macOS and different package managers with Linux.</p>
|
||
<h4 id="red-hat-based-linux-2">Red Hat based Linux</h4>
|
||
<p>Execute the following as root or via sudo:</p>
|
||
<pre><code> dnf install ncurses ncurses-devel</code></pre>
|
||
<h4 id="macos-2">macOS</h4>
|
||
<p>With macOS it should already be installed. If it is not you might have to do:</p>
|
||
<pre><code> xcode-select --install</code></pre>
|
||
<p>and agree to the terms and conditions and proceed with the install.</p>
|
||
<h5 id="macos-via-homebrew-1">macOS via Homebrew</h5>
|
||
<p>Not applicable, see above.</p>
|
||
<h5 id="macos-via-macports-1">macOS via MacPorts</h5>
|
||
<p>Not applicable, see above.</p>
|
||
<h4 id="debian-based-linux-2">Debian based Linux</h4>
|
||
<p>Execute the following as root or via sudo:</p>
|
||
<pre><code> apt install libncurses6</code></pre>
|
||
<p>and then try <code>make all</code> again.</p>
|
||
<h4 id="other-linux-distributions-2">Other Linux distributions</h4>
|
||
<p>Use your package manager to install the appropriate packages. Try the search
|
||
feature of the package manager to determine which packages you need to install.
|
||
Note that you might have to install both the library and the developmental
|
||
packages: one for compiling and one for linking / running.</p>
|
||
<h4 id="package-website-2">Package website</h4>
|
||
<p>Go to the <a href="https://invisible-island.net/ncurses/">ncurses website</a> and follow their instructions
|
||
for downloading, installing and using ncurses.</p>
|
||
<p>We recommend trying a method suitable for your environment first, if possible.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_10">
|
||
<div id="sox">
|
||
<div id="sound">
|
||
<h3 id="faq-3.10-how-do-i-compile-and-use-an-ioccc-entry-that-requires-sound">FAQ 3.10: How do I compile and use an IOCCC entry that requires sound?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>This might depend on the entry but most likely the Swiss Army Knife of sound
|
||
processing programs, <a href="https://sox.sourceforge.net">SoX</a>, will work. How to
|
||
install depends on your OS.</p>
|
||
<h4 id="red-hat-based-linux-3">Red Hat based Linux</h4>
|
||
<p>As root or via sudo:</p>
|
||
<pre><code> dnf install -y sox sox-devel</code></pre>
|
||
<h4 id="macos-3">macOS</h4>
|
||
<p>For macOS there are two well known options.</p>
|
||
<h5 id="macos-via-homebrew-2">macOS via Homebrew</h5>
|
||
<p>If you have not already done so, install <a href="https://brew.sh">Homebrew</a>.</p>
|
||
<p>Then to install SoX, execute the following command:</p>
|
||
<pre><code> brew install sox
|
||
eval "$(opt/homebrew/bin/brew shellenv)"</code></pre>
|
||
<h5 id="macos-via-macports-2">macOS via MacPorts</h5>
|
||
<p>If you haven’t already, install
|
||
<a href="https://www.macports.org/install.php">MacPorts</a>. Then run:</p>
|
||
<pre><code> sudo port install sox</code></pre>
|
||
<h4 id="debian-based-linux-3">Debian based Linux</h4>
|
||
<p>Usually the index.html file will explain how to use it under Debian so we do not
|
||
include this here, at least for now.</p>
|
||
<h4 id="package-website-3">Package website</h4>
|
||
<p>Not applicable, see above.</p>
|
||
<h4 id="other-linux-distributions-3">Other Linux distributions</h4>
|
||
<p>Usually the index.html file will explain how to use it under Linux so we do not
|
||
include this here, at least for now.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_11">
|
||
<div id="weverything">
|
||
<h3 id="faq-3.11-why-do-makefiles-use--weverything-with-clang">FAQ 3.11: Why do Makefiles use -Weverything with clang?</h3>
|
||
</div>
|
||
</div>
|
||
<p>While we know that use of <code>-Weverything</code> is generally not recommended
|
||
by <code>clang</code> C compiler developers, we do use the <code>-Weverything</code>
|
||
option in a certain case in IOCCC entry <code>Makefile</code>s.</p>
|
||
<p>The use of <code>-Weverything</code> is limited to when one forces <code>CC=clang</code> or more
|
||
generally if the string ‘clang’ is in <code>$(CC)</code>. If <code>$(CC)</code> contains ‘gcc’ the
|
||
‘gcc’ specific options are run instead.</p>
|
||
<p>Users with clang compilers are not required to set <code>CC=clang</code> or equivalent but
|
||
when they do, <code>-Weverything</code> is enabled with all of its challenges, pedantic
|
||
warnings, and sometimes warnings about things that do not matter, some of which
|
||
are frankly frivolous and often downright dubious.</p>
|
||
<p>To enable this feature:</p>
|
||
<pre><code> make clobber all CC=clang</code></pre>
|
||
<p>IOCCC authors who have access to <code>clang</code> might wish to try their
|
||
hand at compiling with <code>-Weverything</code> while using a minimum of <code>-Wno-foo</code>
|
||
statements. Sometimes there is a technical or pedantic issue that
|
||
<code>-Weverything</code> warns about that would merit a change to your C code; often,
|
||
however, it is not even possible to fix let alone is it worth it. Of course
|
||
if you’re running out of bytes due to rule 2[ab] one might not have much choice.
|
||
This is something that obfuscation authors simply sometimes have to deal with!</p>
|
||
<p>If you try to minimize the number of <code>-Wno-foo</code> options needed with
|
||
<code>-Weverything</code>, please mention this in your remarks about the entry, as the
|
||
judges note you attempt to honor it (see also below). In some cases your
|
||
obfuscated code will issue warnings with <code>-Weverything</code> no matter what: the
|
||
<code>-Wno-poison-system-directories</code> is a common example of this but there are
|
||
others as well, sometimes depending on the version of <code>clang</code>.</p>
|
||
<p>If you do try for a compile with <code>clang -Weverything</code>, keep on mind that while <em>your</em>
|
||
compile environment might be warning free, a different clang version or a
|
||
different build environment might still have warnings. For instance the warning
|
||
set is different in macOS (which by default is <code>clang</code>: even when run as <code>gcc</code>!)
|
||
than Linux (due to versions and possibly other things)!</p>
|
||
<p>Given that your entry <strong>MUST</strong> work as documented, you may be safer to
|
||
say that your entry keeps the number of warnings and <code>-Wno-foo</code> options while
|
||
compiling with <code>clang -Weverything</code> at a minimum. You might want to say the
|
||
version number and platform too as an extra safety net. Because if you claim zero
|
||
warnings, and we find a warning situation, this may diminish the value of your
|
||
entry as it is not as documented. Thus it might be wise to point this out and
|
||
if you can test it in multiple platforms (or versions of <code>clang</code>, see
|
||
below note) this would be advisable.</p>
|
||
<p><strong>NOTE</strong>: different versions of <code>clang</code> have other differences as well. For instance
|
||
a defect of <code>clang</code> that required numerous entries to be fixed for clang is that it
|
||
requires that <code>main()</code>’s arguments to be of a specific type. However some
|
||
versions of <code>clang</code> are more strict in the number of args allowed. These reasons
|
||
are part of why numerous entries had to be modified so that <code>main()</code> calls
|
||
another function instead of doing it all in <code>main()</code> (another reason was that
|
||
some entries that recursively called <code>main()</code> caused a crash or otherwise broke
|
||
the entry in modern systems). Some entries do not work in <code>clang</code> (or at least do
|
||
not work completely) due to these defects, for instance
|
||
<a href="1989/westley/index.html">1989/westley</a>; <a href="authors.html#Cody_Boone_Ferguson">Cody Boone
|
||
Ferguson</a> was able to
|
||
get much of it to work and looking at that entry might be of value to your
|
||
submissions, at least if you can figure the code out :-). To see the
|
||
differences, try from <code>1989/westley</code>:</p>
|
||
<pre><code> make diff_orig_prog</code></pre>
|
||
<p>If you have <code>colordiff</code> try:</p>
|
||
<pre><code> make DIFF=colordiff diff_orig_prog</code></pre>
|
||
<p>Alternatively you can try:</p>
|
||
<pre><code> git diff d2a42f42e8f477f29e9d5ed09ce2bb349eaf7397..eb9e69fde657acc8c85a618a8a99af4c2f93b21d westley.c</code></pre>
|
||
<p>As you can see, using <code>clang</code> has some additional problems to work out but if
|
||
you can get your entry to work well in <code>clang</code> it might very well be considered
|
||
better than other entries.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_12">
|
||
<div id="eof">
|
||
<div id="intr">
|
||
<div id="interrupt">
|
||
<h3 id="faq-3.12-how-do-i-find-out-how-to-send-interrupteof-etc.-for-entries-that-require-it">FAQ 3.12: How do I find out how to send interrupt/EOF etc. for entries that require it?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>For some entries one needs to send interrupt or EOF or some other signal/other
|
||
special characters. There are typical defaults like (where <code>^</code> = ctrl):</p>
|
||
<ul>
|
||
<li><code>^D</code> for EOF (<code>eof</code>)</li>
|
||
<li><code>^C</code> for interrupt (<code>intr</code>)</li>
|
||
<li><code>^U</code> for kill (<code>kill</code>)</li>
|
||
</ul>
|
||
<p>and various others. But if you don’t know this you can find out through the
|
||
<code>stty(1)</code> command with the <code>-a</code> option. For instance with macOS you might see:</p>
|
||
<pre><code> $ stty -a
|
||
speed 9600 baud; rows 40; columns 155;
|
||
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; [..snip..]</code></pre>
|
||
<p>If you know the name you can use <code>grep</code> to find the correct line and if your
|
||
implementation of <code>grep(1)</code> has the <code>-o</code> option you can filter it. For instance
|
||
to find what the <code>intr</code> is set to:</p>
|
||
<pre><code> $ stty -a |grep -o 'intr = ^[[:alpha:]]'
|
||
intr = ^C</code></pre>
|
||
<p>… assuming of course that it’s a ctrl combination :-) If for some strange
|
||
reason it’s not you might have to do something else including just piping it to
|
||
just <code>grep intr</code> or whatever.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_13">
|
||
<div id="no_support">
|
||
<h3 id="faq-3.13-why-does-an-ioccc-entry-fail-to-compile-andor-fail-to-run">FAQ 3.13: Why does an IOCCC entry fail to compile and/or fail to run?</h3>
|
||
</div>
|
||
</div>
|
||
<p>What may have worked years ago may not work well or work at all today.
|
||
Please note that the IOCCC judges do <strong>NOT</strong> support IOCCC entries.
|
||
Nevertheless, there may be a number of reasons why an IOCCC entry
|
||
may fail to compile or run well or fail to run on your system.</p>
|
||
<p>In some cases the American National Standards Institute’s ANSI C
|
||
committee has damaged the C standard to the point where perfectly
|
||
valid C programs no longer compile with modern compilers. As such
|
||
some old IOCCC entries cannot no longer be compiled with modern compilers.</p>
|
||
<p>In some cases programs that may have worked on an old computer system
|
||
longer work on modern computers. Some IOCCC entries do not work well,
|
||
or no longer work on modern computers or modern operating systems.
|
||
Some IOCCC entries fail to compile under clang, or gcc.
|
||
Some IOCCC entries require operating system services that
|
||
may not be present on your system.</p>
|
||
<p>In some cases the IOCCC entry simply has bugs or (Mis)features.</p>
|
||
<p>If you are having problems compiling or running an IOCCC entry,
|
||
we recommend that you look in <a href="bugs.html">bugs.html</a> to see if
|
||
there is a known bugs or (Mis)feature. In some cases what you
|
||
may think is a bug is actually an feature that was intentionally
|
||
written by the authors. In some cases the problem is well
|
||
known and we are looking for someone to attempt to fix it.</p>
|
||
<p>In some cases there is an alternate version of the IOCCC entry
|
||
that you may wish to try.</p>
|
||
<p>It also possible that you may have discovered a bug in an winning IOCCC
|
||
entry. If so, you are invited to try and fix the IOCCC entry and
|
||
submit that fix by way of a <a href="https://github.com/ioccc-src/winner/pulls">GitHub pull
|
||
request</a>.
|
||
Please see the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”
|
||
for how to submit a fix to an IOCCC entry.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_14">
|
||
<div id="tcpserver">
|
||
<h3 id="faq-3.14---how-do-i-compile-and-install-tcpserver-for-entries-that-require-it">FAQ 3.14 - How do I compile and install tcpserver for entries that require it?</h3>
|
||
</div>
|
||
</div>
|
||
<p>If your OS package manager does not have the package <code>tcpserver</code> you can
|
||
download, making sure you’re in a temporary directory, and compile the source
|
||
like:</p>
|
||
<pre><code> wget http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz
|
||
tar ucspi-tcp-0.88.tar.gz
|
||
cd ucspi-tcp-0.88
|
||
make</code></pre>
|
||
<p>Then as root or via <code>sudo(1)</code> enter:</p>
|
||
<pre><code> make setup check</code></pre>
|
||
<p>That will install it to <code>/usr/local/bin</code>. Now you should be able to use the
|
||
entry in question.</p>
|
||
<div id="faq3_15">
|
||
<div id="netpbm">
|
||
<h3 id="how-do-i-compile-and-install-netpbm-for-entries-that-require-it">3.15 - How do I compile and install netpbm for entries that require it?</h3>
|
||
</div>
|
||
</div>
|
||
<p>This depends on your operating system for which we describe a couple below.</p>
|
||
<h4 id="red-hat-based-linux-4">Red Hat based Linux</h4>
|
||
<p>Execute the following as root or via sudo:</p>
|
||
<pre><code> dnf install netpbm-progs netpbm</code></pre>
|
||
<p>Older RHEL distributions might have to use “yum” instead of “dnf”
|
||
in the above command.</p>
|
||
<h4 id="macos-4">macOS</h4>
|
||
<p>If you’re using macOS there are at least three ways to obtain it. You can
|
||
use Homebrew or MacPorts. If you do not wish to use either of those
|
||
package managers, you can always try to install via the package website.
|
||
For macOS we do recommend using Homebrew or MacPorts instead of using
|
||
the package website.</p>
|
||
<h5 id="macos-via-homebrew-3">macOS via Homebrew</h5>
|
||
<p>If you have not already done so, install <a href="https://brew.sh">Homebrew</a>.</p>
|
||
<p>Then to install netpbm, execute the following command:</p>
|
||
<pre><code> brew install netpbm</code></pre>
|
||
<h5 id="macos-via-macports-3">macOS via MacPorts</h5>
|
||
<p>If you haven’t already, install
|
||
<a href="https://www.macports.org/install.php">MacPorts</a>. Then run:</p>
|
||
<pre><code> sudo port install libnetpbm netpbm</code></pre>
|
||
<h4 id="debian-based-linux-4">Debian based Linux</h4>
|
||
<p>Execute the following as root or via sudo:</p>
|
||
<pre><code> apt install netpbm</code></pre>
|
||
<p>and then try <code>make all</code> again.</p>
|
||
<h4 id="other-linux-distributions-4">Other Linux distributions</h4>
|
||
<p>Use your package manager to install the appropriate packages. Try the search
|
||
feature of the package manager to determine which packages you need to install.
|
||
Note that you might have to install both the library and the developmental
|
||
packages: one for compiling and one for linking / running.</p>
|
||
<h4 id="package-website-4">Package website</h4>
|
||
<p>Go to the <a href="https://netpbm.sourceforge.net">netpbm website</a> and follow their instructions
|
||
for downloading, installing and using netpbm.</p>
|
||
<p>We recommend trying a method suitable for your environment first, if possible.</p>
|
||
<div id="faq3_16">
|
||
<div id="libjpeg">
|
||
<h3 id="how-do-i-compile-and-install-libjpeg-turbo-for-entries-that-require-it">3.16 - How do I compile and install libjpeg-turbo for entries that require it?</h3>
|
||
</div>
|
||
</div>
|
||
<p>This depends on your operating system for which we describe a couple below.</p>
|
||
<h4 id="red-hat-based-linux-5">Red Hat based Linux</h4>
|
||
<p>Execute the following as root or via sudo:</p>
|
||
<pre><code> dnf install libjpeg-turbo-utils libjpeg-turbo-devel libjpeg-turbo</code></pre>
|
||
<p>Older RHEL distributions might have to use “yum” instead of “dnf”
|
||
in the above command.</p>
|
||
<h4 id="macos-5">macOS</h4>
|
||
<p>If you’re using macOS there are at least three ways to obtain it. You can
|
||
use Homebrew or MacPorts. If you do not wish to use either of those
|
||
package managers, you can always try to install via the package website.
|
||
For macOS we do recommend using Homebrew or MacPorts instead of using
|
||
the package website.</p>
|
||
<h5 id="macos-via-homebrew-4">macOS via Homebrew</h5>
|
||
<p>If you have not already done so, install <a href="https://brew.sh">Homebrew</a>.</p>
|
||
<p>Then to install libjpeg-turbo, execute the following command:</p>
|
||
<pre><code> brew install libjpeg-turbo</code></pre>
|
||
<h5 id="macos-via-macports-4">macOS via MacPorts</h5>
|
||
<p>If you haven’t already, install
|
||
<a href="https://www.macports.org/install.php">MacPorts</a>. Then run:</p>
|
||
<pre><code> sudo port install libjpeg-turbo libjpeg-turbo-devel</code></pre>
|
||
<h4 id="debian-based-linux-5">Debian based Linux</h4>
|
||
<p>Execute the following as root or via sudo:</p>
|
||
<pre><code> apt install libturbojpeg0 libturbojpeg0-dev</code></pre>
|
||
<p>and then try <code>make all</code> again.</p>
|
||
<h4 id="other-linux-distributions-5">Other Linux distributions</h4>
|
||
<p>Use your package manager to install the appropriate packages. Try the search
|
||
feature of the package manager to determine which packages you need to install.
|
||
Note that you might have to install both the library and the developmental
|
||
packages: one for compiling and one for linking / running.</p>
|
||
<h4 id="package-website-5">Package website</h4>
|
||
<p>Go to the <a href="https://www.libjpeg-turbo.org">libjpeg-turbo website</a> and follow their instructions
|
||
for downloading, installing and using libjpeg-turbo.</p>
|
||
<p>We recommend trying a method suitable for your environment first, if possible.</p>
|
||
<div id="faq3_17">
|
||
<div id="imagemagick">
|
||
<h3 id="how-do-i-compile-and-install-imagemagick-for-entries-that-require-it">3.17 - How do I compile and install ImageMagick for entries that require it?</h3>
|
||
</div>
|
||
</div>
|
||
<p>This depends on your operating system for which we describe a couple below.</p>
|
||
<h4 id="red-hat-based-linux-6">Red Hat based Linux</h4>
|
||
<p>Execute the following as root or via sudo:</p>
|
||
<pre><code> dnf install ImageMagick</code></pre>
|
||
<p>Older RHEL distributions might have to use “yum” instead of “dnf”
|
||
in the above command.</p>
|
||
<h4 id="macos-6">macOS</h4>
|
||
<p>If you’re using macOS there are at least three ways to obtain it. You can
|
||
use Homebrew or MacPorts. If you do not wish to use either of those
|
||
package managers, you can always try to install via the package website.
|
||
For macOS we do recommend using Homebrew or MacPorts instead of using
|
||
the package website.</p>
|
||
<h5 id="macos-via-homebrew-5">macOS via Homebrew</h5>
|
||
<p>If you have not already done so, install <a href="https://brew.sh">Homebrew</a>.</p>
|
||
<p>Then to install ImageMagick, execute the following command:</p>
|
||
<pre><code> brew install ImageMagick</code></pre>
|
||
<h5 id="macos-via-macports-5">macOS via MacPorts</h5>
|
||
<p>If you haven’t already, install
|
||
<a href="https://www.macports.org/install.php">MacPorts</a>. Then run:</p>
|
||
<pre><code> sudo port install ImageMagick</code></pre>
|
||
<h4 id="debian-based-linux-6">Debian based Linux</h4>
|
||
<p>Execute the following as root or via sudo:</p>
|
||
<pre><code> apt install imagemagick</code></pre>
|
||
<p>and then try <code>make all</code> again.</p>
|
||
<h4 id="other-linux-distributions-6">Other Linux distributions</h4>
|
||
<p>Use your package manager to install the appropriate packages. Try the search
|
||
feature of the package manager to determine which packages you need to install.
|
||
Note that you might have to install both the library and the developmental
|
||
packages: one for compiling and one for linking / running.</p>
|
||
<h4 id="package-website-6">Package website</h4>
|
||
<p>Go to the <a href="https://imagemagick.org">ImageMagick website</a> and follow their instructions
|
||
for downloading, installing and using ImageMagick.</p>
|
||
<p>We recommend trying a method suitable for your environment first, if possible.</p>
|
||
<div id="faq3_18">
|
||
<div id="OpenGL">
|
||
<h3 id="how-do-i-compile-and-install-opengl-for-entries-that-require-it">3.18 - How do I compile and install OpenGL for entries that require it?</h3>
|
||
</div>
|
||
</div>
|
||
<p>This depends on your operating system for which we describe a couple below.</p>
|
||
<p>In general OpenGL needs X11 to be installed and the X Window Server to be running. See the
|
||
FAQ on “<a href="#X11">X11</a>”
|
||
for general information about X11.</p>
|
||
<p>Once X11 is install and the X Window Server is running, one needs to compile
|
||
and link with the two libraries, <em>GL</em> and <em>GLU</em>:</p>
|
||
<pre><code> cc ... -lGL -lGLU -L _location-where-X11-libs-are-installed_ -lX11</code></pre>
|
||
<p>NOTE: The OpenGL development effort is being manageed by <a href="https://vulkan.org">vulkan.org</a>.
|
||
We suggest you check out their resource for further information on OpenGL.</p>
|
||
<h4 id="red-hat-based-linux-7">Red Hat based Linux</h4>
|
||
<p>Execute the following as root or via sudo:</p>
|
||
<pre><code> sudo dnf install glew-devel SDL2-devel SDL2_image-devel glm-devel freetype-devel</code></pre>
|
||
<p>See <a href="https://en.wikibooks.org/wiki/OpenGL_Programming/Installation/Linux">OpenGL Programming/Installation/Linux</a> for details.</p>
|
||
<p>Older RHEL distributions might have to use “yum” instead of “dnf”
|
||
in the above command.</p>
|
||
<h4 id="macos-7">macOS</h4>
|
||
<p>In the past, macOS has come with OpenGL pre-installed. However as of macOS 10.14,
|
||
<a href="https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html">OpenGL has been deprecated on macOS</a> (in favor of Metal).</p>
|
||
<p>As long as Apple continues to ship OpenGL pre-installed and it works, you
|
||
should be able to go. However in Apple drops support for OpenGL later on,
|
||
you might look to install OpenGL via Homebrew or MacPorts.</p>
|
||
<h4 id="debian-based-linux-7">Debian based Linux</h4>
|
||
<p>Execute the following as root or via sudo:</p>
|
||
<pre><code> sudo apt-get install libglew-dev libsdl2-dev libsdl2-image-dev libglm-dev libfreetype6-dev</code></pre>
|
||
<p>and then try <code>make all</code> again.</p>
|
||
<p>See <a href="https://en.wikibooks.org/wiki/OpenGL_Programming/Installation/Linux">OpenGL Programming/Installation/Linux</a> for details.</p>
|
||
<h4 id="other-linux-distributions-7">Other Linux distributions</h4>
|
||
<p>Use your package manager to install the appropriate packages. Try the search
|
||
feature of the package manager to determine which packages you need to install.
|
||
Note that you might have to install both the library and the developmental
|
||
packages: one for compiling and one for linking / running.</p>
|
||
<h4 id="package-website-7">Package website</h4>
|
||
<p>Go to the <a href="https://vulkan.org">Vulkan website</a> and follow their instructions
|
||
for downloading, installing and using OpenGL.</p>
|
||
<p>We recommend trying a method suitable for your environment first, if possible.</p>
|
||
<div id="faq3_19">
|
||
<div id="make_compatibility">
|
||
<h3 id="what-kind-of-make1-compatibility-does-the-ioccc-support-and-will-it-support-other-kinds">3.19 - What kind of make(1) compatibility does the IOCCC support and will it support other kinds?</h3>
|
||
</div>
|
||
</div>
|
||
<p>For the <a href="https://www.ioccc.org">IOCCC</a> <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry submission
|
||
toolkit</a> and the <a href="years.html">winning IOCCC
|
||
entries</a> we support <em>ONLY</em> GNU Makefile syntax. This means that if
|
||
you only have Cygwin or a BSD <code>make(1)</code> (often <code>bmake(1)</code>) or some other
|
||
<code>make(1)</code> utility the Makefiles we use will not be compatible.</p>
|
||
<p>We do not intend on supporting anything but the GNU <code>make(1)</code> utility so if you
|
||
do not currently have it installed you will have to do that in order to compile
|
||
entries for the IOCCC. If you are submitting an entry this will also be
|
||
necessary.</p>
|
||
<p>If you do not have GNU <code>make(1)</code> you might look for <code>gmake</code> as that is what it
|
||
often is packaged as. Then you can use <code>gmake</code> instead. For instance if you go
|
||
to the top level directory of the winner repo you can do:</p>
|
||
<pre><code> gmake</code></pre>
|
||
<p>In the case that the Makefile uses the <code>MAKE</code> variable you will have to override
|
||
it like:</p>
|
||
<pre><code> gmake MAKE=gmake</code></pre>
|
||
<p>though of course for both you may specify a rule or rules to run.</p>
|
||
<div id="faq3_20">
|
||
<div id="entry_downloads">
|
||
<h3 id="how-do-i-download-individual-winning-entries-or-all-winning-entries-of-a-given-year">3.20 - How do I download individual winning entries or all winning entries of a given year?</h3>
|
||
</div>
|
||
</div>
|
||
<p>Although one can clone the entire <a href="https://github.com/ioccc-src/winner">winner
|
||
repo</a> to get the entire website and all
|
||
entries, we also provide, as a convenience, a way to download individual entries
|
||
as well as a way to download a year’s winning entries.</p>
|
||
<p>Please note that some of the links in the html files will not work! This is
|
||
because you are not downloading the full website. If you want to view the entry
|
||
with links intact you should clone the repo or view it on the <a href="https://www.ioccc.org">official IOCCC
|
||
website</a> instead.</p>
|
||
<h4 id="individual-winning-entry-tarballs">Individual winning entry tarballs</h4>
|
||
<p>The individual entry tarballs are named in the form of
|
||
<code>YYYY/winner/YYYY_winner.tar.bz2</code> (e.g.
|
||
<a href="1984/mullender/1984_mullender.tar.bz2">1984/mullender/1984_mullender.tar.bz2</a>)
|
||
and they contain a single entry as well as some additional necessary files. Each
|
||
entry tarball is linked to in its <code>index.html</code> (e.g.
|
||
<a href="1984/mullender/index.html">1984/mullender/index.html</a>) manifest, listed in the
|
||
<em>Secondary files</em> list.</p>
|
||
<p>These tarballs will have the following files:</p>
|
||
<ul>
|
||
<li><code>ioccc.css</code> - stylesheet for the html files</li>
|
||
<li><code>var.mk</code> - the top level Makefile included by all the other Makefiles that holds variables used by the Makefiles</li>
|
||
<li><code>YYYY/winner/.path</code> - directory path from top level directory</li>
|
||
<li><code>YYYY/winner/.entry.json</code> - entry summary and manifest in JSON</li>
|
||
<li><code>YYYY/winner/.gitignore</code> - list of files that should not be committed under git</li>
|
||
</ul>
|
||
<p>plus the winning entry files like source code, the Makefile, supplementary data
|
||
provided by the author and any other file in the winning entry, found under the
|
||
entry’s subdirectory.</p>
|
||
<p>If you downloaded <code>1984/mullender/1984_mullender.tar.bz2</code>, for instance, you might
|
||
then do:</p>
|
||
<div class="sourceCode" id="cb66"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb66-1"><a href="#cb66-1" aria-hidden="true" tabindex="-1"></a> <span class="bu">cd</span> 1984/mullender</span>
|
||
<span id="cb66-2"><a href="#cb66-2" aria-hidden="true" tabindex="-1"></a> <span class="fu">make</span> everything</span>
|
||
<span id="cb66-3"><a href="#cb66-3" aria-hidden="true" tabindex="-1"></a> <span class="ex">./mullender.alt</span></span></code></pre></div>
|
||
<p>to compile all versions and then run the alternate version (if you have
|
||
a PDP-11 or VAX-11 you would be able to run the original version). For more help
|
||
on compiling entries, see also the
|
||
FAQ on “<a href="#make_rules">IOCCC Makefile rules</a>”.</p>
|
||
<p>If you want to view the <code>index.html</code> file you can point your browser to the
|
||
<code>index.html</code> file of the winning entry (e.g. <code>1984/mullender/index.html</code>) with the
|
||
caveats noted above.</p>
|
||
<h4 id="year-based-tarballs">Year based tarballs</h4>
|
||
<p>The year based tarballs, which are under each year’s directory and are named in
|
||
the form of <code>YYYY/YYYY.tar.bz2</code> (e.g. <a href="1984/1984.tar.bz2">1984/1984.tar.bz2</a>),
|
||
include all the winning entries of a given year.
|
||
Each year’s tarball can be found under that year in the <a href="years.html">years.html</a>
|
||
page and in the year’s <code>index.html</code> as well (e.g.
|
||
<a href="1984/index.html">1984/index.html</a>).</p>
|
||
<p>These tarballs have, along with each entry’s directory and their respective
|
||
files (as if you downloaded each entry tarball of the year individually as
|
||
described above), the following files:</p>
|
||
<ul>
|
||
<li><code>.filelist</code> - list of files in the year that are not part of a winning entry of the year, including the <code>YYYY.tar.bz2</code> tarball</li>
|
||
<li><code>index.html</code> - the <code>YYYY/index.html</code> file rendered from the <code>YYYY/README.md</code> file</li>
|
||
<li><code>Makefile</code> - Makefile for the year to compile etc. all entries of the year</li>
|
||
<li><code>README.md</code> - the source of the <code>YYYY/index.html</code> file</li>
|
||
<li><code>rules.txt</code> - rules of the year’s contest</li>
|
||
<li><code>.year</code> - text file that has a list of the winning entries’ directories of the year</li>
|
||
</ul>
|
||
<p>Additionally, some will have extra files like:</p>
|
||
<ul>
|
||
<li><code>.gitignore</code> - list of files that should not be committed under git</li>
|
||
<li><code>guidelines.txt</code> - the guidelines of the year</li>
|
||
<li><code>iocccsize.c</code> - <code>iocccsize</code> tool of the year</li>
|
||
<li><code>iocccsize.mk</code> - Makefile to compile the <code>iocccsize</code> tool of the year</li>
|
||
<li><code>iocccsize-test.sh</code> - test suite for the <code>iocccsize</code> tool</li>
|
||
</ul>
|
||
<p>.. and perhaps some others we have neglected to mention as well.</p>
|
||
<p>If you extract a year’s tarball you can <code>cd YYYY</code> (e.g. <code>cd 1984</code>) and then run
|
||
<code>make everything</code> to compile the entries and alternate code of every entry, as
|
||
if you switched to each entry’s directory and ran <code>make everything</code> in each one.</p>
|
||
<p>If you download the 1984 tarball, i.e. <code>1984/1984.tar.bz2</code>, then you might
|
||
extract it and then switch to the directory and compile everything of each
|
||
entry:</p>
|
||
<div class="sourceCode" id="cb67"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb67-1"><a href="#cb67-1" aria-hidden="true" tabindex="-1"></a> <span class="bu">cd</span> 1984</span>
|
||
<span id="cb67-2"><a href="#cb67-2" aria-hidden="true" tabindex="-1"></a> <span class="fu">make</span> everything</span></code></pre></div>
|
||
<p>For more help on compiling entries, see also the
|
||
FAQ on “<a href="#make_rules">IOCCC Makefile rules</a>”.</p>
|
||
<p>Of course in this case you can also switch to individual entries and look at the
|
||
<code>index.html</code> file (or any other file in the entry) and try out the entries that
|
||
interest you, as if you downloaded that entry’s individual tarball.</p>
|
||
<p>If you want to view the <code>index.html</code> files of that tarball, for instance the
|
||
year’s <code>index.html</code> file and then <code>1984/mullender/index.html</code> you could point your
|
||
browser to <code>1984/index.html</code>, scroll down to <code>Winning Entries of 1984 - The 1st IOCCC</code> and click on the link <code>1984/mullender</code> which will take you to the
|
||
<code>index.html</code> file. Of course the caveats listed above still will apply.</p>
|
||
<div id="faq3_21">
|
||
<div id="try">
|
||
<h3 id="what-are-try.sh-and-try.alt.sh-scripts-and-why-should-i-use-them">3.21 - What are <code>try.sh</code> and <code>try.alt.sh</code> scripts and why should I use them?</h3>
|
||
</div>
|
||
</div>
|
||
<p>A lot of the entries, old and otherwise, have complicated uses or if not
|
||
complicated uses then numerous uses (sometimes both), and having a script that
|
||
automates these for viewers improves the usability of these entries so one can
|
||
enjoy them better.</p>
|
||
<p>The <code>try.sh</code> script is for the original entry and the <code>try.alt.sh</code> script is for
|
||
alternate versions. These scripts are usually for the <code>Try:</code> and <code>Alternate try:</code> sections in the <code>index.html</code> files.</p>
|
||
<p>Some entries provide additional scripts that are meant to run the entry as well
|
||
but might not fit in the <code>try</code> model though some are used by a <code>try.sh</code> /
|
||
<code>try.alt.sh</code> script.</p>
|
||
<p>Although you’re certainly welcome to copy and paste or type the commands in
|
||
manually, sometimes the scripts will do additional things that you might miss
|
||
and there are some other benefits as well which you would miss if you did not
|
||
use them. Nevertheless, if you prefer to do it manually, whether to help you
|
||
process or appreciate the entry more, then please do so.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq3_22">
|
||
<div id="forced_warnings">
|
||
<h3 id="are-there-any-compiler-warnings-that-i-should-not-worry-about">3.22 - Are there any compiler warnings that I should not worry about?</h3>
|
||
</div>
|
||
</div>
|
||
<p>There are unfortunately some warnings that cannot be disabled; they are always
|
||
enabled whatever warning options you have enabled. Also, there is a warning that
|
||
is enabled whenever you act on <code>char *</code>s, saying it is unsafe buffer usage, even
|
||
when it’s not (this might be enabled by <code>-Weverything</code> but it might not be; for
|
||
more details on why we use <code>-Weverything</code> in Clang see the FAQ on
|
||
“<a href="#weverything"><code>-Weverything</code></a>”), and it is not detrimental to your submission
|
||
if you disable this). This warning happens to be <code>-Wno-unsafe-buffer-usage</code>.</p>
|
||
<p>So in short, no you should not worry about these as they are sometimes
|
||
inevitable in obfuscated code and even non-obfuscated code.</p>
|
||
<p>If you <em>can</em> work past this it might be good but this is not something that
|
||
should be worried about too much as this is on the compiler developers, not you.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq4">
|
||
<h2 id="section-4-changes-made-to-ioccc-entries">Section 4: Changes made to IOCCC entries</h2>
|
||
</div>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq4_0">
|
||
<div id="author_remarks">
|
||
<h3 id="faq-4.0-why-are-some-winning-entry-remarks-incongruent-with-the-winning-ioccc-code">FAQ 4.0: Why are some winning entry remarks incongruent with the winning IOCCC code?</h3>
|
||
</div>
|
||
</div>
|
||
<p>It is very likely in this case that the code was fixed to work for modern
|
||
systems as part of the reworking of the website. If you have this problem in
|
||
some entries you should look at the original code as in <code>dirname.orig.c</code> or
|
||
<code>prog.orig.c</code>. <code>dirname</code> is the directory name. For instance, one of Landon’s
|
||
favourite entries of all time is <a href="1984/mullender/index.html">1984/mullender</a> and
|
||
the entry’s dirname there would be <code>mullender</code>. Sometimes the original is in an alt
|
||
version like <code>dirname.alt.c</code> or <code>prog.alt.c</code>. In fact it is advisable to look at
|
||
the original code when reading the author’s (and sometimes authors’) remarks.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#original_source_code">original source code</a>”
|
||
for more information.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq4_1">
|
||
<div id="gets">
|
||
<div id="fgets">
|
||
<h3 id="faq-4.1-why-were-some-calls-to-the-libc-function-gets3-changed-to-use-fgets3">FAQ 4.1: Why were some calls to the libc function gets(3) changed to use fgets(3)?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>Some may wonder: “Doesn’t this tamper with the entry too much?”</p>
|
||
<p>A fine line indeed has to be drawn here but it was decided that it is worth it
|
||
because of alarming warnings that can be displayed, in some systems at runtime
|
||
interspersed with the output of the program.</p>
|
||
<p>For instance in macOS the entry <a href="1990/tbr/index.html">1990/tbr</a> would output the
|
||
warning in such a way that caused confusing output for the entry, looking like:</p>
|
||
<pre><code> $ ./tbr
|
||
$ warning: this program uses gets(), which is unsafe.
|
||
# nothing here, what to do?</code></pre>
|
||
<p>In some cases it is not possible to fix or at least it is highly unlikely and so
|
||
those have mainly not been touched except one that has had the buffer size
|
||
increased (which could be done for others that are not possible to change to
|
||
<code>fgets()</code> though this has not been done).</p>
|
||
<p>Some entries can be made to look almost identical to the original entry. For
|
||
instance the fix to <a href="1988/reddy/index.html">1988/reddy</a> required only a single
|
||
<code>#define</code> be added.</p>
|
||
<p>In the cases it has not been done it is likely the entry can be found in the
|
||
<a href="bugs.html">bugs.html</a> file.</p>
|
||
<p>In the future we, the judges, would prefer that entries use <code>fgets()</code> to prevent
|
||
these problems.</p>
|
||
<p>An annoying fact is that for ‘“compatibility” reasons’ <code>fgets()</code> retains the
|
||
newline and <code>gets()</code> does not. As the Unix version 7 man page used to say:</p>
|
||
<pre><code> BUGS
|
||
|
||
The fgets(3) function retains the newline while gets(3) does not, all in the
|
||
name of backward compatibility.</code></pre>
|
||
<p>We’re not sure how this is compatibility but either way it can cause a
|
||
problem and it is this that has complicated most of the fixes though again some
|
||
can look almost identical.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq4_2">
|
||
<div id="what_changed">
|
||
<h3 id="faq-4.2-what-was-changed-in-an-ioccc-entry-source-code">FAQ 4.2: What was changed in an IOCCC entry source code?</h3>
|
||
</div>
|
||
</div>
|
||
<p>We have set up make rules to easily do see what was changed in the winning IOCCC
|
||
entry source. Using the <code>Makefile</code> in the entry directory, use
|
||
one of the following <em>make(1)</em> rules:</p>
|
||
<p>The following <code>make</code> rules exist to make a difference:</p>
|
||
<ul>
|
||
<li><code>make diff_orig_prog</code>:
|
||
<ul>
|
||
<li>This rule will show the diff of the <em>original</em> source to the
|
||
current source (that is <code>entry.orig.c</code> to <code>entry.c</code>).</li>
|
||
</ul></li>
|
||
<li><code>make make diff_alt_orig</code>:
|
||
<ul>
|
||
<li>This rule will show the diff of the alternate code to the original
|
||
code (that is <code>entry.alt.c</code> to <code>entry.orig.c</code>). If no alternate code exists
|
||
nothing will be shown.</li>
|
||
</ul></li>
|
||
<li><code>make diff_alt_prog</code>:
|
||
<ul>
|
||
<li>This rule will show the diff of the alternate code to the entry as it
|
||
stands (that is <code>entry.alt.c</code> to <code>entry.c</code>).</li>
|
||
</ul></li>
|
||
<li><code>make diff_orig_alt</code>:
|
||
<ul>
|
||
<li>This rule will show the diff of the original code to the alternate code
|
||
(that is <code>entry.orig.c</code> to <code>entry.alt.c</code>).</li>
|
||
</ul></li>
|
||
<li><code>make diff_prog_alt</code>:
|
||
<ul>
|
||
<li>This rule will show the diff of the entry to the alternate code (that is
|
||
<code>entry.c</code> to <code>entry.alt.c</code>).</li>
|
||
</ul></li>
|
||
<li><code>make diff_prog_orig</code>:
|
||
<ul>
|
||
<li>This rule will show the diff of the entry to the original code (that is
|
||
<code>entry.c</code> to <code>entry.orig.c</code>).</li>
|
||
</ul></li>
|
||
</ul>
|
||
<p>For instance one of Landon’s all time favourite entries is
|
||
<a href="1984/mullender/index.html">1984/mullender</a> so the file names would be:
|
||
<code>mullender.orig.c</code>, <code>mullender.alt.c</code> and <code>mullender.c</code>. For later years, it
|
||
would be instead <code>prog.orig.c</code>, <code>prog.alt.c</code> and <code>prog.c</code>.</p>
|
||
<p>Note that you might see something like:</p>
|
||
<pre><code> make: [Makefile:170: diff_orig_prog] Error 1 (ignored)</code></pre>
|
||
<p>at the end of the output but this is completely normal if there are differences.</p>
|
||
<p>If the alternate code is the same as the original, say with
|
||
<a href="1984/anonymous/index.html">1984/anonymous</a>, then naturally there is no point in
|
||
running the rule and the same applies for all the other rules but this system
|
||
allows for easily seeing the diffs.</p>
|
||
<p>As some examples we’ll first look at one that has really long lines which
|
||
will make it harder to see what is different,
|
||
<a href="2001/anonymous/index.html">2001/anonymous</a>. What you would do is <code>cd 2001/anonymous</code> and then do:</p>
|
||
<pre><code> make diff_orig_prog</code></pre>
|
||
<p>and then be really confused! :-)</p>
|
||
<p>But for an entry like <a href="1991/dds/index.html">1991/dds</a>, you can see the
|
||
differences much more easily. <code>1991/dds</code> is a good example where it’s very
|
||
simple to see what is different as it’s just a couple lines.</p>
|
||
<p>You might be quite surprised how little some entries had to be changed and at
|
||
the same time how much other entries had to be changed, often with quite complex
|
||
differences! In some cases if the line is rather long, like the above mentioned
|
||
one, it will be harder to see what changed but in other cases like
|
||
<a href="1984/decot/index.html">1984/decot</a> or <a href="1986/wall/index.html">1986/wall</a> it’s a
|
||
lot easier.</p>
|
||
<p>Well, at least it’s easier see the differences on a line-by-line basis but maybe
|
||
not what actually changed, especially since it’s easier to know what was fixed
|
||
when you have compiler errors :-) (though there are, as noted, some examples
|
||
where it’s quite easy to see the differences).</p>
|
||
<p><a href="1991/dds/index.html">1991/dds</a> is also a good example to see the alt difference
|
||
very easily. To do that <code>cd 1991/dds</code> and then do:</p>
|
||
<pre><code> make diff_alt_prog</code></pre>
|
||
<p>and you’ll see a single line changed and very simply.</p>
|
||
<p><strong>NOTE</strong>: The above mentioned <code>make</code> rules are located in the <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1337.mk">1337.mk</a>
|
||
include Makefile via the optional include directive line:</p>
|
||
<pre><code> -include 1337.mk ../1337.mk ../../1337.mk</code></pre>
|
||
<p>The <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1337.mk">1337.mk</a> file must exist in the current
|
||
directory, or under the directory above, or under the directory 2 levels
|
||
above in order for these rules to work.</p>
|
||
<h4 id="tip-if-you-have-colordiff-installed-its-a-lot-easier-to-see-the-differences">Tip: if you have <code>colordiff</code> installed it’s a lot easier to see the differences</h4>
|
||
<p>To use these rules but provide a different <code>diff</code>, for instance <code>colordiff</code>,
|
||
just do:</p>
|
||
<pre><code> make DIFF=colordiff diff_orig_prog # for orig to prog diff
|
||
make DIFF=colordiff diff_alt_prog # for alt to prog diff</code></pre>
|
||
<p>Obviously if you want to view the alternate code or the orig code you can just open
|
||
the files as described above.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#original_source_code">original source code</a>”
|
||
for more information.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq4_3">
|
||
<h3 id="faq-4.3---why-do-author-remarks-sometimes-not-match-the-source-andor-why-are-there-other-inconsistencies-with-the-original-entry">FAQ 4.3 - Why do author remarks sometimes not match the source and/or why are there other inconsistencies with the original entry?</h3>
|
||
</div>
|
||
<p>If the entry has been fixed for modern systems and this fix required
|
||
modification to the code then invariably there will be entries where the remarks
|
||
of the author or authors are inconsistent with the original code, the size of
|
||
the code might be against rule 2 and other kinds of inconsistencies might also
|
||
be there.</p>
|
||
<p>This is why we recommend that when you read the remarks, sometimes the judges’
|
||
remarks and always the author’s or authors’ remarks, you look at the original
|
||
code. When the entry source code is called <code>prog.c</code> the original code is in
|
||
<code>prog.orig.c</code>; otherwise it is <code>dirname.orig.c</code>. For instance one of Landon’s all
|
||
time favourite entries is <a href="1984/mullender/index.html">1984/mullender</a> and the
|
||
original code is in <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1984/mullender/mullender.orig.c">mullender.orig.c</a>. In
|
||
some cases, such as <code>1984/mullender</code>, the original code is the same as the code
|
||
as no changes were made (there is an alt version for systems that are not
|
||
VAX-11/PDP-11, however).</p>
|
||
<p>See also the
|
||
FAQ on “<a href="#what_changed">entry source code changes</a>”</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq4_4">
|
||
<div id="orig_c">
|
||
<h3 id="faq-4.4-what-is-the-meaning-of-the-file-ending-in-.orig.c-in-ioccc-entries">FAQ 4.4: What is the meaning of the file ending in .orig.c in IOCCC entries?</h3>
|
||
</div>
|
||
</div>
|
||
<p>Due to the fact that the original code has sometimes had to change these files
|
||
are the original winning entry or as close to as possible to the original that
|
||
we can find.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq4_5">
|
||
<div id="alt">
|
||
<div id="alt_code">
|
||
<h3 id="faq-4.5-what-are-alternate-versions-and-why-were-alternate-versions-added-to-some-entries-when-the-original-entry-worked-fine-and-well">FAQ 4.5: What are alternate versions and why were alternate versions added to some entries when the original entry worked fine and well?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>The alternate versions are exactly what they sound like, versions of their
|
||
respective entries that were not the winning source code but have additional
|
||
features added (often by the author) or fixes, updates at the request of the
|
||
judges (upon winning the contest), unobfuscated versions and a variety of other
|
||
things for instance letting it work on more than one platform (where it would
|
||
not be possible to do in the original submission).</p>
|
||
<p>In some cases the alternate code added come directly from the author (some of
|
||
which already were in the website) but there were other cases where alternate
|
||
code was added that might or might not be necessary; this was a judgement call
|
||
and the reasons vary.</p>
|
||
<p>In many cases it was simply to make the entry more presentable to more people
|
||
but without modifying the entry itself, which would be tampering with the entry
|
||
(a problem that we tried to avoid as much as possible although we certainly did
|
||
not manage to do this perfectly), and in some cases it would be changing it so
|
||
much that it would no longer be what was submitted.</p>
|
||
<p>In one case an alternate version was created to help locate and fix a bug that
|
||
prevented the entry from working properly and it seemed like it should be added
|
||
as well, for fun (it is a game).</p>
|
||
<p>In some cases it might be better to not have them but as noted this was a
|
||
judgement call.</p>
|
||
<p>See also the
|
||
FAQ on “<a href="#original_source_code">original source code</a>”
|
||
for more information.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq4_6">
|
||
<div id="arg_count">
|
||
<div id="main_args">
|
||
<h3 id="faq-4.6-why-was-arg-count-andor-type-changed-in-main-in-some-older-entries">FAQ 4.6: Why was arg count and/or type changed in main() in some older entries?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>There are a number of reasons this was done but they usually come down to a
|
||
mis-feature or defect in the <code>clang</code> compiler.</p>
|
||
<p>In all versions of <code>clang</code> the first arg must be an <code>int</code> and the rest must be a
|
||
<code>char **</code> but in some versions it also objects to the number of args in
|
||
<code>main()</code>. In the versions observed that complain about the number of args it
|
||
says that there must be 0, 2 or 3 args. This only was triggered with 4 args, not
|
||
1, but to future proof the entry entries that had only one arg to <code>main()</code> were
|
||
changed to two.</p>
|
||
<p>The above also meant that some entries that were recursive calls to <code>main()</code>
|
||
could no longer be so: <code>main()</code> instead had to call another function that has
|
||
the body of the old <code>main()</code> and that function would call itself again. In some
|
||
cases, however, this had to be done even without <code>clang</code> objections.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq4_7">
|
||
<div id="renaming_files">
|
||
<h3 id="faq-4.7-why-were-some-filenames-changed">FAQ 4.7: Why were some filenames changed?</h3>
|
||
</div>
|
||
</div>
|
||
<p>The reasons this was done varies. One of the earliest changes was making the old
|
||
<code>.hint</code> or <code>.text</code> files <code>README.md</code> files. The first time this was done was for
|
||
<code>2019/README.text</code> and <code>2020/README.text</code> with <a href="https://github.com/ioccc-src/temp-test-ioccc/commit/87c41a787fa334f6696ec8f23284eacea63e3e89">commit
|
||
87c41a787fa334f6696ec8f23284eacea63e3e89</a>.
|
||
With <a href="https://github.com/ioccc-src/temp-test-ioccc/commit/77fb0f11a2ddc8584a1ebe8d68fb0cccf3b959a6">commit
|
||
77fb0f11a2ddc8584a1ebe8d68fb0cccf3b959a6</a><code>index.html</code>
|
||
and <code>hint.html</code> files were removed in favour of <code>README.md</code> files;
|
||
<a href="https://github.com/ioccc-src/temp-test-ioccc/commit/851e191519953c743cdd363dc19099e89210319c">commit
|
||
851e191519953c743cdd363dc19099e89210319c</a>
|
||
renamed <code>hint.txt</code> and <code>hint.text</code> to <code>README.md</code>. There were most likely other
|
||
commits that fixed some issues with this.</p>
|
||
<p>Other files were also renamed, though, sometimes being converted to markdown as
|
||
well. Shell scripts were often renamed to end with <code>.sh</code> to indicate it is a
|
||
shell script and to help browsers know how to deal with it (this was before the
|
||
method of how to display files was devised).</p>
|
||
<p>Another example is for more consistency, sometimes to do with alternate code and
|
||
other times something else.</p>
|
||
<p>There were certainly other reasons as well.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq4_8">
|
||
<div id="files_added">
|
||
<div id="files_removed">
|
||
<h3 id="faq-4.8-why-were-files-added-or-removed-from-some-entries">FAQ 4.8: Why were files added or removed from some entries?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>Like with files being renamed, there are multiple reasons files were added or
|
||
removed. The addition of the <code>try.sh</code> and <code>try.alt.sh</code> scripts is the most
|
||
significant example of files being added. These scripts, as the
|
||
<code>try.sh</code> sometimes the <code>try.alt.sh</code> scripts
|
||
help demonstrate entries by automating commands, sometimes many
|
||
commands and not always simple commands, that one would previously have to run
|
||
manually (there are other benefits as well).</p>
|
||
<p>See the
|
||
FAQ on “<a href="#try">try.sh and try.alt.sh</a>”
|
||
for more details.</p>
|
||
<p>Alternate code, sometimes provided by the author, sometimes provided by the
|
||
judges and sometimes other people, was added to some entries as well.</p>
|
||
<p>In the case that a link might end up with a 404 the files, if possible, were
|
||
downloaded and put into the entry’s directory. Sometimes the links were already
|
||
dead but with the help of the Internet Wayback Machine we could get the files
|
||
back.</p>
|
||
<p>In a few cases files were removed and there are multiple reasons for this too.</p>
|
||
<p>The end result is to help improve the presentation of the entries in some way or
|
||
ways.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq4_9">
|
||
<div id="original_source_code">
|
||
<h3 id="faq-4.9--what-is-the-original-source-file">FAQ 4.9:- What is the original source file?</h3>
|
||
</div>
|
||
</div>
|
||
<p>Every entry has what is called the “<strong>original source file</strong>”. This is
|
||
a copy of the original source code (usually <code>prog.c</code>) that the
|
||
<a href="judges.html">IOCCC judges</a> used when declaring that submission is a
|
||
winning IOCCC entry.</p>
|
||
<p>There are a number of reasons why the source code (usually <code>prog.c</code>) needs
|
||
to be modified. Reasons include things such as:</p>
|
||
<ul>
|
||
<li>modification as requested by the <a href="judges.html">IOCCC judges</a></li>
|
||
<li>modification as requested by the author(s)</li>
|
||
<li>modification as requested by a pull request from <a href="thanks-for-help.html">someone else</a></li>
|
||
<li>bug fix</li>
|
||
<li>portability improvement</li>
|
||
<li>etc.</li>
|
||
</ul>
|
||
<p>We seek to preserve the “<strong>original source file</strong>”, for historical purposes,
|
||
by preserving the original source code (usually as <code>prog.orig.c</code>).</p>
|
||
<p><strong>IMPORTANT NOTE</strong>: The “<strong>original source file</strong>”, because it is a historic
|
||
record, should <strong>NOT</strong> be modified.</p>
|
||
<p>Unless one can demonstrate that a mistake has been made regarding
|
||
the “<strong>original source file</strong>” and that, for some reason, the file
|
||
is <strong>NOT</strong> the original source code, please do <strong>NOT</strong> attempt to modify it.</p>
|
||
<p><strong>IMPORTANT NOTE</strong>: If you believe that the “<strong>original source file</strong>” is
|
||
<strong>NOT</strong> the original source code, then plesse open an
|
||
<a href="https://github.com/ioccc-src/winner/issues">IOCCC issue</a> and describe the
|
||
problem to the <a href="judges.html">IOCCC judges</a>, including that you believe
|
||
is the correct “<strong>original source file</strong>”.</p>
|
||
<p><strong>FYI</strong>: To determine the difference between the “<strong>original source file</strong>” and
|
||
the source code as it is now now, try:</p>
|
||
<pre><code> make diff_orig_prog</code></pre>
|
||
<p>See the
|
||
FAQ on “<a href="#what_changed">what changed</a>”
|
||
for more information and make rules relating to “<strong>original source file</strong>” differences.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq5">
|
||
<h2 id="section-5-updating-or-correcting-ioccc-website-content">Section 5: Updating or correcting IOCCC website content</h2>
|
||
</div>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq5_0">
|
||
<div id="how_to_help">
|
||
<div id="helping">
|
||
<h3 id="faq-5.0-how-may-i-help-the-ioccc">FAQ 5.0: How may I help the IOCCC?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<h3 id="we-welcome-your-help-in-fixing-ioccc-entries">We welcome your help in fixing IOCCC entries</h3>
|
||
<p>The <a href="bugs.html">known bugs</a> file, order by IOCCC years, contains a
|
||
list of known bugs & (mis)features. If you are looking for an IOCCC entry
|
||
to try and fix, this file is a good place to start.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”
|
||
for information on how to submit a fix to
|
||
an IOCCC entry. Before you consider trying to fix an IOCCC winning entry,
|
||
please check the <a href="bugs.html">known bugs</a> file for the IOCCC entry
|
||
in question. Note that in several cases what you may have discovered,
|
||
while a (mis)feature is not considered a bug and should <strong>not be fixed</strong>.
|
||
In cases where the bug is known, the entry’s <a href="bugs.html">known bugs</a> file
|
||
section may offer you important fixing clues.</p>
|
||
<h3 id="we-welcome-your-help-on-fixing-the-ioccc-website">We welcome your help on fixing the IOCCC website</h3>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq5_1">
|
||
<div id="report_bug">
|
||
<div id="reporting_bugs">
|
||
<h3 id="faq-5.1-how-do-i-report-a-bug-in-an-ioccc-entry">FAQ 5.1: How do I report a bug in an IOCCC entry?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>We do not ‘maintain’ the contest entries as such. The code is made available on an ‘AS
|
||
IS’ basis. If you have a FIX for an entry, we suggest that you submit your fixes in a <a href="https://github.com/ioccc-src/winner/pulls">GitHub pull
|
||
request</a> as we welcome pull requests that have a
|
||
minimal impact on the entry while improving the portability, functionality, and/or addressing known problems.</p>
|
||
<p>If you do submit a pull request, we ask that each pull request address just one IOCCC entry at a time.</p>
|
||
<p>Note that just because you have a fix does not mean it’ll be accepted. This
|
||
might be because the author objects or it doesn’t fit in some way or another. Of
|
||
course if the entry does not work we’ll certainly be more inclined to accept the
|
||
fix. If it is accepted we’ll be happy to credit you in the
|
||
<a href="thanks-for-help.html">thanks</a> file. If you’re a previous author of a winning IOCCC entry we will happily
|
||
link to your entries; if you’re not we can link to your website if you wish.</p>
|
||
<p>Please see the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”
|
||
for information on how to submit a fix to an
|
||
IOCCC entry. See also the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information about pull requests.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq5_2">
|
||
<div id="fix_an_entry">
|
||
<div id="fixing_entries">
|
||
<h3 id="faq-5.2-how-may-i-submit-a-fix-to-an-ioccc-entry">FAQ 5.2: How may I submit a fix to an IOCCC entry?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>If you see a problem with an IOCCC entry, first check the <a href="bugs.html">known bugs</a>
|
||
file. In some cases what you might think of as a bug is instead a known
|
||
feature. In some cases the bug is known, but no fix has ever been submitted.
|
||
In other cases you may have found a new problem.</p>
|
||
<p>If you do have a fix, and the <a href="bugs.html">known bugs</a> file <strong>does not recommend
|
||
against fixing it</strong>, then please consider opening a <a href="https://github.com/ioccc-src/winner/pulls">GitHub pull
|
||
request</a> against the master
|
||
<a href="https://github.com/ioccc-src/winner/branches">branch</a> of the <a href="https://github.com/ioccc-src/winner">ioccc-src/winner
|
||
repo</a>.</p>
|
||
<p>BTW: A <strong>problem</strong> is not limited to the code itself. Fixing typos in files
|
||
such as “<em>index.html</em>” files, fixing issues in a “<em>Makefile</em>”, or otherwise
|
||
correcting an IOCCC entry is <strong>VERY MUCH WELCOME</strong>! Please use the same
|
||
<a href="https://github.com/ioccc-src/winner/pulls">GitHub pull request</a> process against
|
||
the <a href="https://github.com/ioccc-src/winner/branches">master branch</a> of the
|
||
<a href="https://github.com/ioccc-src/winner">ioccc-src/winner repo</a>.</p>
|
||
<p>NOTE: some of the issues in the <a href="bugs.html">bugs.html</a> file includes just missing
|
||
files and we welcome these too!</p>
|
||
<p><strong>Please also help us fix typos and / or otherwise improve the write-up</strong> of how
|
||
IOCCC winning entries are presented!</p>
|
||
<p>In any event we will happily add you to the
|
||
<a href="thanks-for-help.html">thanks</a> file for your help!</p>
|
||
<p>And of course, an IOCCC author may update their own entries
|
||
(metadata as well as source code and any extra files) by opening a
|
||
<a href="https://github.com/ioccc-src/winner/pulls">GitHub pull request</a>
|
||
against the <a href="https://github.com/ioccc-src/winner/branches">master branch</a>
|
||
of the <a href="https://github.com/ioccc-src/winner">ioccc-src/winner repo</a>.</p>
|
||
<p>Please see the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”.
|
||
See also the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information about pull requests.</p>
|
||
<p>Note that we’re much more inclined to accept an author’s fixes but the judges
|
||
have the final say in the matter.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq5_3">
|
||
<div id="report_web_problem">
|
||
<div id="website_problems">
|
||
<h3 id="faq-5.3-how-may-i-report-an-ioccc-website-problem">FAQ 5.3: How may I report an IOCCC website problem?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>If you discover a problem with the IOCCC website that is related
|
||
to a particular IOCCC entry, please see the
|
||
FAQ on “<a href="#report_bug">report entry bug</a>”
|
||
for information about reporting a bug in an IOCCC entry, and see the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”
|
||
for information on how to submit a fix to an IOCCC entry.</p>
|
||
<p>If you discover a problem with the IOCCC website (such as a broken link, which
|
||
may or may not be specific to a particular IOCCC entry) that is <strong>not related
|
||
to a particular IOCCC entry</strong>, the best way you can help is to submit a fix to
|
||
the IOCCC website. See the
|
||
FAQ on “<a href="#fix_web_site">fixing the website</a>”
|
||
for information on submitting fixes
|
||
to the IOCCC website.</p>
|
||
<p>If you do not have an IOCCC website fix, and just wish to report a general IOCCC
|
||
website problem, we ask that you first look at the <a href="https://github.com/ioccc-src/winner/issues">IOCCC
|
||
issues</a> to see if the problem has
|
||
already been reported. If it has been reported, feel free to add a comment to
|
||
the issue. Otherwise, if you do not see the same issue reported, then feel free
|
||
to <a href="https://github.com/ioccc-src/winner/issues/new">open a new IOCCC issue</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq5_4">
|
||
<div id="fix_website">
|
||
<h3 id="faq-5.4-how-may-i-submit-a-fix-to-the-ioccc-website">FAQ 5.4: How may I submit a fix to the IOCCC website?</h3>
|
||
</div>
|
||
</div>
|
||
<p>For IOCCC website problems that relate to a particular IOCCC entry, please
|
||
see the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”
|
||
for information on how submit a fix to an IOCCC entry.</p>
|
||
<p>You may open a <a href="https://github.com/ioccc-src/winner/pulls">GitHub pull request</a>
|
||
against the <a href="https://github.com/ioccc-src/winner/branches">master branch</a>
|
||
of the <a href="https://github.com/ioccc-src/winner">ioccc-src/winner repo</a>
|
||
to submit a fix.</p>
|
||
<p>Please see the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”.
|
||
See also the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information about pull requests.</p>
|
||
<h4 id="some-html-files-should-not-be-directly-modified">Some HTML files should NOT be directly modified</h4>
|
||
<p>Nearly all HTML files on the <a href="https://www.ioccc.org">IOCCC website</a>
|
||
are built from <a href="https://daringfireball.net/projects/markdown/">markdown</a> files.
|
||
If you see lines containing:</p>
|
||
<pre><code> <!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- !!! 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 !!! -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --></code></pre>
|
||
<p>This means that the file is generated by a tool from a <a href="bin/index.html">bin directory tool</a>.
|
||
You should <strong>NOT</strong> attempt to modify the file.</p>
|
||
<p>You may also find lines slightly below the above set that suggest another file to edit.
|
||
For example, in <a href="contact.html">contact.html</a>, one may read:</p>
|
||
<pre><code> <!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: contact.md -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: contact.md -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: contact.md -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --></code></pre>
|
||
<p>This means that you could consider editing the referenced markdown file
|
||
AND then run <code>make www</code> from the top level directory in your IOCCC pull
|
||
request. There are quicker ways but to be sure you get
|
||
everything built you should do this. If you modified a markdown and you do not
|
||
see the same file as a html file then you did not complete the fix.</p>
|
||
<p>Please see the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”.</p>
|
||
<p>See also the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information about pull requests.</p>
|
||
<p>In some cases, the HTML file is <strong>NOT</strong> based on markdown content, but instead
|
||
came from JSON and other data files. So instead of the above reference to a
|
||
markdown file, you will read:</p>
|
||
<pre><code> <!-- The main section of this web page came from JSON and other data files -->
|
||
<!-- -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- The main section of this web page was generated via the tool: bin/gen-years.sh -->
|
||
<!-- The main section of this web page was generated via the tool: bin/gen-years.sh -->
|
||
<!-- The main section of this web page was generated via the tool: bin/gen-years.sh -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --></code></pre>
|
||
<p>This means there is <strong>NOT even a markdown file to edit</strong>. Instead one must
|
||
modify JSON files and/or change a <a href="bin/index.html">bin directory tool</a>.</p>
|
||
<p>If this happens, consider opening up an <a href="https://github.com/ioccc-src/winner/issues">IOCCC issue</a>
|
||
and ask for help. See
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”
|
||
for information on opening up an IOCCC issue.</p>
|
||
<div id="faq5_5">
|
||
<div id="fix_author">
|
||
<h2 id="faq-5.5-how-may-i-correct-or-update-ioccc-author-information">FAQ 5.5: How may I correct or update IOCCC author information?</h2>
|
||
</div>
|
||
</div>
|
||
<p>You may correct or update IOCCC author information by submitting a
|
||
GitHub pull request that modifies an author’s <code>author_handle.json</code> file.</p>
|
||
<p>For example, if a given <code>author_handle.json</code> file contained:</p>
|
||
<pre><code> "url" : "https://www.example.com/employee/username",</code></pre>
|
||
<p>and you knew that the author has long ago left the <code>www.example.com</code> company,
|
||
and that they have a new faculty web page at <code>www.example.edu</code>, then you should
|
||
submit a GitHub pull request to change the above line to:</p>
|
||
<pre><code> "url" : "https://www.example.edu/faculty/deartment/user.name",</code></pre>
|
||
<p>Authors of IOCCC winning entries are kept in JSON files of the form:</p>
|
||
<pre><code> author/author_handle.json</code></pre>
|
||
<p>where <code>author_handle</code> is an author handle.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#author_handle_faq">author handle</a>”
|
||
for more information about author handles.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#author_json">author_handle.json</a>”
|
||
for information about the contents of these JSON files and how they are used.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#find_author_handle">finding author handles</a>”
|
||
for how to find an <em>author_handle</em>.</p>
|
||
<p>You may update IOCCC author information in a <code>author_handle.json</code> file
|
||
by <a href="#pull_request">submitting a pull request</a>
|
||
against the <a href="https://github.com/ioccc-src/winner/branches">master branch</a>
|
||
of the <a href="https://github.com/ioccc-src/winner">ioccc-src/winner repo</a>.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information.</p>
|
||
<p><strong>IMPORTANT NOTE</strong>: As these files are JSON you should verify that
|
||
they are validly formed (e.g., you didn’t make a typo).</p>
|
||
<p>Before you form your GitHub pull request that modifies a
|
||
<code>author_handle.json</code> file, please run the <code>make www</code> command. This
|
||
unfortunately takes quite a while but it is the safest way to do
|
||
it. So you may wish to test your edits by running the somewhat
|
||
quicker <code>make quick_www</code> as this can speed up your testing.</p>
|
||
<p>The <code>make quick_www</code> rule will update the <code>authors.html</code> and
|
||
<code>location.html</code> pages and it will also check the timestamps of the <code>index.html</code>
|
||
files versus the <code>README.md</code> files. Since they were touched and thus the
|
||
timestamp was updated, the
|
||
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/bin/quick-readme2index.sh">bin/quick-readme2index.sh</a> tool would
|
||
only worry about those two files. This greatly speeds things along while testing.
|
||
Nevertheless, doing a final <code>make www</code> is still recommended best practice
|
||
before you form your pull request.</p>
|
||
<p>Please see
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”.</p>
|
||
<p>See also the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information about pull requests.</p>
|
||
<h3 id="important-note-about-xx---anonymous-location">Important note about <strong>XX - Anonymous location</strong>:</h3>
|
||
<p>Unless you are the author who originally selected the <strong>XX - Anonymous
|
||
location</strong>, please do not attempt to change an <strong>XX - Anonymous
|
||
location</strong> without the permission of the original author, as sometimes they
|
||
want to have the location known but not their name and/or other details.</p>
|
||
<div id="zz_help">
|
||
<h3 id="please-help-us-identify-proper-locations-for-ioccc-authors">PLEASE HELP us identify proper locations for IOCCC authors</h3>
|
||
</div>
|
||
<p>If you know the location of an author listed under:</p>
|
||
<p> <strong><a href="location.html#ZZ">ZZ - Unknown location</a></strong></p>
|
||
<p>or if you find IOCCC author location that is incorrect,
|
||
then <strong>please submit a pull request</strong>,
|
||
or at least <a href="contact.html">inform the IOCCC judges</a>.</p>
|
||
<p><strong>FYI</strong>: The <a href="location.html#ZZ">ZZ - Unknown location</a> is used for
|
||
historic winning authors whose location or country is not known,
|
||
whereas the <a href="location.html#XX">XX - Anonymous location</a> is used when the
|
||
winning author does <strong>not wish to disclose their location</strong>.</p>
|
||
<p>The contents of these JSON files contain the best known information
|
||
about authors of IOCCC entries. See
|
||
FAQ on “<a href="#author_json">author_handle.json</a>”
|
||
for information about the contents of these JSON files and how they are used.</p>
|
||
<p>For example, if a given <code>author_handle.json</code> file contained:</p>
|
||
<pre><code> "location_code" : "ZZ",</code></pre>
|
||
<p>and you knew that the author was located in <a href="location.html#AU">Australia</a>
|
||
(location code <strong>AU</strong>), we encourage you to submit a <strong>GitHub pull
|
||
request</strong> to change that line to:</p>
|
||
<pre><code> "location_code" : "AU",</code></pre>
|
||
<p>See the
|
||
FAQ on “<a href="#fix_author">fixing author information</a>”
|
||
for information about how to change author location codes.</p>
|
||
<div id="faq5_6">
|
||
<div id="fix_link">
|
||
<h2 id="faq-5.6-what-should-i-do-if-i-find-a-broken-or-wrong-web-link">FAQ 5.6: What should I do if I find a broken or wrong web link?</h2>
|
||
</div>
|
||
</div>
|
||
<p>We would appreciate if you try to fix the broken (the link goes nowhere) or wrong
|
||
(the link goes to something that clearly is not the original intent) web link.
|
||
If wish to fix such links, you may open a GitHub pull request as described in
|
||
FAQ on “<a href="#fix_web_site">fixing the website</a>”.
|
||
In the case of dead links or invalid links it doesn’t matter
|
||
if it’s a specific winner or not; the procedure is the same: open a pull request
|
||
to fix the problem. See also the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information about pull requests.</p>
|
||
<p>As far as how to find the updated link you can try using the <a href="https://web.archive.org">Internet Wayback
|
||
Machine</a> and see if you can find the last non 4xx non
|
||
3xx page. Note, however, that just because it redirects, does not mean it’s not
|
||
valuable. Other times you might find it with a web search.</p>
|
||
<p>Some links were changed to more recent URLs by doing this exact
|
||
same thing. Some links, while they were a valid web page, no longer
|
||
reach the intended web page (for example when the domain is sold
|
||
and the new domain owner’s content no longer provides the content
|
||
that was originally intended .. and while the content of the web
|
||
page may be humorous to some, the original content may have literally
|
||
gone “up in smoke”).</p>
|
||
<p>In cases where the original content is lost, try searching for it on
|
||
the <a href="https://web.archive.org">Internet Wayback Machine</a>. When searching
|
||
look back for dates that are around the year of given IOCCC contest.
|
||
If you do find the original content in Internet archive history,
|
||
please consider submitting a change to replace the link accordingly.</p>
|
||
<p>If there is no alternative that you can find you might want to remove the link
|
||
instead by replacing the link with just phrase of text. For example,
|
||
if the text in some <code>index.html</code> file was:</p>
|
||
<pre><code> See the [author's description of the program](https://example.com) for more information.</code></pre>
|
||
<p>Assuming that the author’s description cannot be found in the
|
||
<a href="https://web.archive.org">Internet Wayback Machine</a> archive, then
|
||
replace that text with:</p>
|
||
<pre><code> See the **author's description of the program** (sorry the content is no longer available) for more information.</code></pre>
|
||
<p>If you just wish to report the bad link issue, see
|
||
FAQ on “<a href="#report_web_problem">report website problem</a>”.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq5_7">
|
||
<div id="support">
|
||
<div id="supporting_ioccc">
|
||
<h3 id="faq-5.7-how-may-i-support-the-ioccc">FAQ 5.7: How may I support the IOCCC?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>The <a href="judges.html">IOCCC judges</a> run the IOCCC entirely out of
|
||
their own funds. This includes paying for IOCCC related hardware,
|
||
services, registration, software and related technical items.</p>
|
||
<p>There is <strong>NO</strong> requirement for anyone to support the <a href="index.html">IOCCC</a>.
|
||
Nevertheless, it has been shown that receiving <strong>anonymous</strong> gifts
|
||
provides the <a href="judges.html">IOCCC judges</a> with a nice
|
||
<a href="https://en.wikipedia.org/wiki/Dopamine">dopamine</a>
|
||
boost, and happy <a href="judges.html">IOCCC judges</a> help make the IOCCC
|
||
better for everyone. :-)</p>
|
||
<p>If you wish to express your support and/or appreciation for our
|
||
efforts, we suggest making an <strong>Anonymous</strong> gift via the
|
||
<a href="https://www.amazon.com/hz/wishlist/ls/3HSNTEL8RQ1M0?ref_=wl_share">IOCCC Amazon wishlist</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq5_8">
|
||
<div id="deobfuscated">
|
||
<div id="deobfuscation">
|
||
<div id="unobfuscated">
|
||
<div id="unobfuscation">
|
||
<h3 id="faq-5.8-i-deobfuscated-some-entry-code-may-i-contribute-the-source">FAQ 5.8: I deobfuscated some entry code, may I contribute the source?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p><strong>PLEASE NOTE</strong>: <strong>many <a href="authors.html">winning authors</a></strong> have unobfuscated code
|
||
of their <strong>own entries</strong> and you should look for this first, often on GitHub or on
|
||
their website; see the FAQ on <a href="#author-information">how to find more information about a winning
|
||
author of an entry</a> for how you might find this
|
||
information. We ask you to, if you can find them, please ask them what they
|
||
think as they can often provide invaluable information; this is less of an issue
|
||
for fixes of bugs - not features - found in the <a href="bugs.html">bugs.html</a> file.</p>
|
||
<p>The <a href="judges.html">IOCCC judges</a> welcome those who wish to contribute a
|
||
<strong>deobfuscated</strong> version of a winning IOCCC entry: from either the <a href="authors.html">author or
|
||
authors</a> (<strong>which is much, much preferred</strong>) or from people such
|
||
as yourself (assuming you are not the author :-) ) who are willing to contribute
|
||
<strong>deobfuscated</strong> code. We also welcome contributions to improve existing
|
||
<strong>deobfuscated</strong> code. You might wish to look at their URL or alt URL (see below
|
||
for more details) <strong>first</strong> as quite a few <a href="authors.html">authors</a> have provided
|
||
unobfuscated code of their entries and this is far more fair to the <a href="authors.html">winning
|
||
authors</a> (and it is much more likely to be identical functionality
|
||
as well, though many <a href="authors.html">authors</a> are experienced and skilled enough
|
||
to add features <strong>after or during obfuscation!</strong> and many in fact do).</p>
|
||
<p><strong>HISTORICAL NOTE</strong>: The IOCCC website has shifted to a more
|
||
educational theme: preferring to explain entries rather than hiding
|
||
things under the guise of such information being a “<em>spoiler</em>”. We
|
||
now use the term <strong>deobfuscated</strong> instead of “<em>spoiler</em>” for this reason, at
|
||
least in most cases; other terms might be used, including on a rare occasion
|
||
<em>spoiler</em>, this depending on context.</p>
|
||
<p>We ask that the <strong>deobfuscated</strong> code be <strong>identical in functionality</strong>
|
||
to the winning IOCCC entry code.</p>
|
||
<p><strong>NOTE</strong>: Be aware that IOCCC entry code may contain <strong>extremely subtle and
|
||
obscure side effects</strong> (i.e., features). Those wishing to contribute a
|
||
<strong>deobfuscated</strong> version of code should <strong>strive to mimic</strong> the original (or
|
||
existing) IOCCC entry code as much as possible. Some authors can be contacted
|
||
(see above for more details on this) and you could ask them for details and if
|
||
possible it would be good to include them in the discussion as well (see below)
|
||
as it is <strong>very likely</strong> there are things that will be missed when trying to
|
||
deobfuscate the code, some of which might be important to the author.</p>
|
||
<p>To contribute your <strong>deobfuscated</strong> code, please open up a
|
||
<a href="https://github.com/ioccc-src/temp-test-ioccc/discussions/new?category=show-and-tell">Show and tell new discussion</a>
|
||
with a title of the form:</p>
|
||
<blockquote>
|
||
<p>Enhancement: deobfuscated code for YYYY/dirname</p>
|
||
</blockquote>
|
||
<p>where “<code>YYYY/dirname</code>” refers to the winning IOCCC entry for which you are deobfuscating.</p>
|
||
<p>In the <strong>body</strong> of your new discussion, <strong>PLEASE</strong> provide us with a <strong>URL</strong> of
|
||
your <strong>deobfuscated</strong> code, along with whatever notes and/or comments you
|
||
think might be helpful. If the author has a GitHub handle <strong>please</strong> mention
|
||
them in the discussion (see above part for how you might find out if they have a
|
||
GitHub account)!</p>
|
||
<p>If you are providing an improved version of some existing <strong>deobfuscated</strong> code, please
|
||
mention that in the <strong>body</strong> of your new discussion as well.</p>
|
||
<p>If there are <strong>limitations</strong> to how well the your <strong>deobfuscated</strong> code mimics
|
||
the original (or existing) IOCCC entry code, <strong>PLEASE</strong> mention those <strong>limitations</strong>
|
||
in the <strong>body</strong> of your new discussion as well.</p>
|
||
<p>Any questions that may arise will be added as comments to the discussion.</p>
|
||
<p><strong>SUGGESTION</strong>: <strong>PLEASE</strong> try to make your <strong>deobfuscated</strong> code readable. <strong>PLEASE</strong>
|
||
add comments as needed to help the reader of your <strong>deobfuscated</strong> code understand it.</p>
|
||
<p><strong>SUGGESTION</strong>: Where useful, consider providing, as <strong>C comments</strong>,
|
||
code fragments of from the original (or existing) IOCCC
|
||
entry code. While it is <strong>NOT</strong> necessary to include the entire
|
||
original code as <strong>C comments</strong>, including key parts from the
|
||
original (or existing) IOCCC entry code may be helpful
|
||
to others who wish to read your <strong>deobfuscated</strong> code.</p>
|
||
<p>If your <strong>deobfuscated</strong> is accepted (in some form), the <a href="judges.html">IOCCC judges</a>
|
||
will be happy to <strong>thank you</strong> for your contribution in the
|
||
<a href="thanks-for-help.html">thanking people for their help file</a>.</p>
|
||
<p>The <a href="judges.html">IOCCC judges</a> will do the rest of the work in integrate your
|
||
<strong>deobfuscated</strong> code as an “<em>alt</em>” code for the entry <strong>AND</strong> will reference
|
||
your <strong>deobfuscated</strong> code in the entry’s <code>index.html</code> file. We will be
|
||
happy to include any whatever notes and/or comments from your new discussion
|
||
that be prove helpful.</p>
|
||
<p><strong>THANK YOU</strong> in advance for your willingness to assist!</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6">
|
||
<h2 id="section-6-miscellaneous-ioccc">Section 6: Miscellaneous IOCCC</h2>
|
||
</div>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_0">
|
||
<div id="size_2_broken">
|
||
<div id="rule_breaking_entry">
|
||
<h3 id="faq-6.0-how-did-an-entry-that-breaks-the-size-rule-2-win-the-ioccc">FAQ 6.0: How did an entry that breaks the size rule 2 win the IOCCC?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>As entries have been fixed it is entirely possible that some of the entries no
|
||
longer fit within the year’s size restrictions. Invariably the length of columns
|
||
and/or number of rows have also changed.</p>
|
||
<p>The <code>winner.orig.c</code> file contains the original source code that was
|
||
subjected to rule 2 of the given IOCCC. You may also wish to see
|
||
the <a href="archive">archive</a> directory where you can find all the
|
||
original winning entries as compressed tar files for a given year.</p>
|
||
<p>In some cases the entry may have abused rule 2 and declared an
|
||
“abuse of the rules” (although now blatant abuse of the rules to
|
||
get around rule 2 size limits is discouraged).</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_1">
|
||
<div id="bugs">
|
||
<div id="misfeatures">
|
||
<div id="mis-features">
|
||
<h3 id="faq-6.1-is-there-a-list-of-known-bugs-and-misfeatures-of-ioccc-entries">FAQ 6.1: Is there a list of known bugs and (mis)features of IOCCC entries?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>Yes! Please see <a href="bugs.html">bugs.html</a> for a list of known bugs and/or issues of a
|
||
variety of kinds.</p>
|
||
<p>Note that just because an entry is not in the bugs file does not mean there is
|
||
not an issue and note that some issues are simply missing files, dead URL(s) or
|
||
something like that.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_2">
|
||
<div id="mirrors">
|
||
<div id="website_mirrors">
|
||
<div id="website_mirroring">
|
||
<h3 id="faq-6.2-may-i-mirror-the-ioccc-website">FAQ 6.2: May I mirror the IOCCC website?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>We are not accepting mirror requests at this time, sorry. However you are free
|
||
to fork the <a href="https://github.com/ioccc-src/winner">IOCCC winner repo</a>. We do ask
|
||
that your fork keep up to date with the latest changes when possible.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_3">
|
||
<div id="permission">
|
||
<div id="copyright">
|
||
<h3 id="faq-6.3-may-i-use-parts-of-the-ioccc-in-an-article-book-newsletter-or-instructional-material">FAQ 6.3: May I use parts of the IOCCC in an article, book, newsletter, or instructional material?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>While IOCCC judges look favorably on most requests to use IOCCC material,
|
||
we request that you ask the <a href="judges.html">IOCCC judges</a> first. Of course, if
|
||
you’re the winner of the entry you can make use of it as you want (make a shirt,
|
||
put it on your website etc.).</p>
|
||
<p>Please send your request using the instructions on the <a href="contact.html">contacting
|
||
the IOCCC Judges</a> page.</p>
|
||
<p>Please note that the content of the IOCCC
|
||
<strong>Copyrighted and is under the CC BY-SA 4.0 License</strong>.
|
||
See the <a href="#copyright">Copyright</a> at the bottom of IOCCC web pages for more details.</p>
|
||
<p>See
|
||
FAQ on “<a href="#license">using IOCCC content</a>”.
|
||
For additional information on the <a href="license.html">Copyright and CC BY-SA 4.0 License</a>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_4">
|
||
<div id="first_person">
|
||
<div id="person">
|
||
<div id="pronoun">
|
||
<h3 id="faq-6.4-why-do-you-sometimes-use-the-first-person-plural">FAQ 6.4: Why do you sometimes use the first person plural?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>As a precedent for <a href="https://en.wikipedia.org/wiki/Nosism">first person
|
||
plural</a>, we may sight <a href="https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.35.1442">Two-,
|
||
Three-, and Four-Atom Exchange Effects in bcc in
|
||
3He</a> and
|
||
the co-authorship of <a href="https://en.wikipedia.org/wiki/F._D._C._Willard">F. D. C.
|
||
Willard</a> as well
|
||
as the <a href="https://journals.aps.org/2014/04/01/aps-announces-a-new-open-access-initiative">APS New Open Access
|
||
Initiative</a>.</p>
|
||
<p>The number of <a href="https://www.ioccc.org/judges.html">IOCCC judges</a> has
|
||
always been “> 1” such that IOCCC judges often prefer to themselves
|
||
in the plural, sometimes <a href="https://en.wikipedia.org/wiki/Plural">in the common
|
||
plural</a>, sometimes in the
|
||
<a href="https://en.wikipedia.org/wiki/Nosism">first person plural</a>, there
|
||
may be some who reject such a practice. Therefore please consider
|
||
that when you believe that just one of the <a href="judges.html">IOCCC
|
||
judges</a> is in action, you may
|
||
consider that <a href="https://en.wikipedia.org/wiki/F._D._C._Willard">F. D. C.
|
||
Willard</a> has been
|
||
consulted, agreed, and has authorized the statement thus allowing
|
||
the <a href="https://en.wikipedia.org/wiki/Plural">in the common plural</a>
|
||
to be used without offense.</p>
|
||
<p>And while some might claim that <a href="https://en.wikipedia.org/wiki/F._D._C._Willard">F. D. C.
|
||
Willard</a> died in
|
||
1982, we suggest that the <a href="https://en.wikipedia.org/wiki/Schrödinger%27s_cat">Schrödinger’s
|
||
cat</a> superposition
|
||
may still be in effect and the 1982 <a href="https://books.google.com/books?id=ms3tce7BgJsC&lpg=PA134&vq=%22the%20report%20of%20my%20death%20was%20an%20exaggeration%22&pg=PA134#v=onepage&q=%22the%20report%20of%20my%20death%20was%20an%20exaggeration%22&f=false">report of death was an
|
||
exaggeration</a>.</p>
|
||
<p>p.s. Here is an image of F. D. C. Willard:</p>
|
||
<p><a href="png/F.D.C.Willard.png">F D C Willard</a></p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_5">
|
||
<!-- we cannot use id="author_handle" because of a header in FAQ 6.6 -->
|
||
<div id="author_handle_faq">
|
||
<h3 id="faq-6.5-what-is-an-author-handle">FAQ 6.5: What is an author handle?</h3>
|
||
</div>
|
||
</div>
|
||
<p>An <code>author_handle</code> is string that refers to a given author and is unique to the
|
||
IOCCC. Each author has exactly one <code>author_handle</code>.</p>
|
||
<p>For each <code>author_handle</code>, there will be a JSON file of the form:</p>
|
||
<pre><code> author/author_handle.json</code></pre>
|
||
<p>See the
|
||
FAQ on “<a href="#fix_author">fixing author information</a>”
|
||
for information about how to update
|
||
and/or correct IOCCC author information.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#auth_json">.auth.json</a>”
|
||
for information about the contents of these JSON files and
|
||
how they are used.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#find_author_handle">finding author handle</a>”
|
||
for how to find your own <em>author_handle</em>.</p>
|
||
<p>Because the <code>author_handle</code> is used to form a JSON filename, the string must be
|
||
POSIX safe string plus the use of <code>+</code> (for technical reasons beyond this
|
||
answer). In particular, the <code>author_handle</code> must be an ASCII string or
|
||
32 characters or less that matches this regexp:</p>
|
||
<pre><code> ^[0-9A-Za-z][0-9A-Za-z._+-]*$"</code></pre>
|
||
<p>Default <code>author_handle</code>’s do not have multiple consecutive <code>_</code> (underscore)
|
||
characters. Nevertheless, multiple consecutive <code>_</code> (underscore) characters are
|
||
allowed. Contest submitters who wish to override their default <code>author_handle</code>
|
||
may do so, long as the ASCII string matches the regexp above AND
|
||
so long as the length does not exceed the 32 ASCII characters (not including
|
||
the terminating NUL byte).</p>
|
||
<p>The <code>author_handle</code> is derived from the name of the author. While there is a
|
||
algorithm that maps the name of the author (which can contain any UTF-8
|
||
characters) into a default <code>author_handle</code> string, those who submit an entry to
|
||
the IOCCC are free to choose a different <code>author_handle</code> string if they so
|
||
desire.</p>
|
||
<p>An <code>author</code> who has won a previous IOCCC is encouraged to reuse their
|
||
<code>author_handle</code> so that new winning entries can be associated with the same
|
||
author.</p>
|
||
<p>For an anonymous <code>author</code>, their handle is one of these forms:</p>
|
||
<pre><code> Anonymous_year</code></pre>
|
||
<p>or:</p>
|
||
<pre><code> Anonymous_year.digits</code></pre>
|
||
<p>The latter form is in case there are more than one anonymous author in a given
|
||
year.</p>
|
||
<p>NOTE: even if the directory name is not <code>anonymous</code> the above rules apply as in
|
||
in the case of <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/anon/anon.c">2005/anon</a>.</p>
|
||
<p>Anonymous <code>author_handle</code>’s match this regexp:</p>
|
||
<pre><code> Anonymous_[0-9][0-9][0-9][0-9][.0-9]*$</code></pre>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_6">
|
||
<div id="author_json">
|
||
<div id="author_handle_json">
|
||
<h3 id="faq-6.6-what-is-an-author_handle.json-file-and-how-are-they-used">FAQ 6.6: What is an <code>author_handle.json</code> file and how are they used?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p><strong>TL:DR</strong>: The contents of these JSON files contain the best known
|
||
information about authors of IOCCC entries and is used to help form
|
||
HTML files as well to contact an author.</p>
|
||
<p><strong>NOTE</strong>: tools to validate the <code>author_handle.json</code> files, which are only for
|
||
winning authors, are in the works (which will be documented after they are
|
||
developed). See the
|
||
FAQ on “<a href="#author_handle_faq">author handles</a>”
|
||
for more information on author handles.</p>
|
||
<p>The content of these JSON files are used by tools from the <a href="bin/index.html">bin directory</a>
|
||
to help build HTML content for the <a href="https://www.ioccc.org">official IOCCC website</a>.</p>
|
||
<p>For example, the <code>index.html</code> file for each IOCCC entry contains selected
|
||
information about the authors. Tools from the <a href="bin/index.html">bin directory</a>
|
||
use the content of these JSON files to generate the <code>index.html</code> files for each
|
||
IOCCC winning entry.</p>
|
||
<p>Moreover, should the <a href="judges.html">IOCCC judges</a> need to
|
||
contact an authors of an IOCCC entry, they will consult the contents
|
||
of the author’s JSON file for ways to contact them.</p>
|
||
<p>Each author of an IOCCC winning entry has their own <code>author_handle.json</code> file
|
||
of the form:</p>
|
||
<pre><code> author/author_handle.json</code></pre>
|
||
<p>where <em>author_handle</em> is an author handle. See
|
||
FAQ on “<a href="#author_handle_faq">author handle</a>”
|
||
for more information about an author handles.</p>
|
||
<h4 id="author_handle.json-json-file-contents"><code>author_handle.json</code> JSON file contents</h4>
|
||
<p>The syntax of a <code>author_handle.json</code> follows the <em>So-called JSON spec</em>.
|
||
See <a href="https://www.json.org/json-en.html" class="uri">https://www.json.org/json-en.html</a> for information on the <em>So-called JSON
|
||
spec</em>.</p>
|
||
<p>A good way to understand the JSON file contents of a <code>author_handle.json</code> file
|
||
is to look at an example, the <code>author_handle.json</code> file for Yusuke Endoh:</p>
|
||
<pre><code> author/Yusuke_Endoh.json</code></pre>
|
||
<p>As of <em>Thu Nov 30 23:51:12 UTC 2023</em>, the contents was as follows:</p>
|
||
<pre><code> {
|
||
"no_comment" : "mandatory comment: because comments were removed from the original JSON spec",
|
||
"author_JSON_format_version" : "1.0 2023-06-10",
|
||
"author_handle" : "Yusuke_Endoh",
|
||
"full_name" : "Yusuke Endoh",
|
||
"sort_word" : "endoh",
|
||
"location_code" : "JP",
|
||
"email" : "mame@ruby-lang.org",
|
||
"url" : "https://mametter.hatenablog.com",
|
||
"alt_url" : null,
|
||
"deprecated_twitter_handle" : null,
|
||
"mastodon" : "@mame@ruby.social",
|
||
"mastodon_url" : "https://ruby.social/@mame",
|
||
"github" : "@mame",
|
||
"affiliation" : null,
|
||
"winning_entry_set" : [
|
||
{ "entry_id" : "2012_endoh1" },
|
||
{ "entry_id" : "2012_endoh2" },
|
||
{ "entry_id" : "2013_endoh1" },
|
||
{ "entry_id" : "2013_endoh2" },
|
||
{ "entry_id" : "2013_endoh3" },
|
||
{ "entry_id" : "2013_endoh4" },
|
||
{ "entry_id" : "2014_endoh1" },
|
||
{ "entry_id" : "2014_endoh2" },
|
||
{ "entry_id" : "2015_endoh1" },
|
||
{ "entry_id" : "2015_endoh2" },
|
||
{ "entry_id" : "2015_endoh3" },
|
||
{ "entry_id" : "2015_endoh4" },
|
||
{ "entry_id" : "2018_endoh1" },
|
||
{ "entry_id" : "2018_endoh2" },
|
||
{ "entry_id" : "2019_endoh" },
|
||
{ "entry_id" : "2020_endoh1" },
|
||
{ "entry_id" : "2020_endoh2" },
|
||
{ "entry_id" : "2020_endoh3" }
|
||
]
|
||
}</code></pre>
|
||
<p><strong>NOTE</strong>: if you need to just check the validity of a JSON document then see the
|
||
FAQ on “<a href="#validating_json">validating JSON documents</a>”. Taking that FAQ in mind,
|
||
if you wish to validate every JSON file in <code>author/</code> then you could do so like:</p>
|
||
<pre class="<!--sh-->"><code> for auth in *.json; do jparse -q "$auth" || echo "$auth is invalid JSON" ; done</code></pre>
|
||
<p>If you see any output then it will say which file or files are invalid JSON
|
||
(this should not actually happen, however).</p>
|
||
<p>See the
|
||
FAQ on “<a href="#jparse">jparse</a>”,
|
||
for now to location and/or install the <code>jparse(1)</code> command.</p>
|
||
<div id="walk_through_author_json">
|
||
<h5 id="walk-through-of-an-author_handle.json-file">Walk through of an <code>author_handle.json</code> file</h5>
|
||
</div>
|
||
<p>We now will walk thru the above JSON document looking at various JSON members:</p>
|
||
<h5 id="no_comment">no_comment</h5>
|
||
<pre><code> "no_comment" : "mandatory comment: because comments were removed from the original JSON spec",</code></pre>
|
||
<p>Because the authors of the so-called JSON spec removed the ability to use comments in JSON
|
||
(for reason(s) that seem to be less than credible), the IOCCC mandates this <em>JSON member</em>
|
||
be present in all IOCCC related JSON files.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>no_comment</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be the exact <em>JSON string</em> as shown above.</p>
|
||
<h5 id="author_json_format_version">author_JSON_format_version</h5>
|
||
<pre><code> "author_JSON_format_version" : "1.0 2023-06-10",</code></pre>
|
||
<p>This <em>JSON member</em> holds the format version of the <code>author_handle.json</code> JSON file.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>author_JSON_format_version</code>
|
||
<em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong> be a <em>JSON string</em>.</p>
|
||
<p>This is <strong>NOT</strong> the version of the contents! When updating an
|
||
<code>author_handle.json</code> JSON file, <strong>DO NOT MODIFY author_JSON_format_version</strong>!
|
||
As of <em>Thu Nov 30 23:51:12 UTC 2023</em>, the <em>JSON value</em> <strong>MUST</strong> be <em>“1.0 2023-06-10”</em>.</p>
|
||
<p>The <em>author_JSON_format_version</em> would only changed when the overall format
|
||
of the these files is modified: and then only those who maintain the
|
||
<a href="https://www.ioccc.org">official IOCCC website</a> would be the one to do this
|
||
in conjunction with changes to <a href="bin/index.html">bin directory tools</a>.</p>
|
||
<h5 id="author_handle">author_handle</h5>
|
||
<pre><code> "author_handle" : "Yusuke_Endoh",</code></pre>
|
||
<p>This <em>JSON member</em> holds the author handle of the author.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>author_handle</code> <em>JSON member</em>
|
||
and the <em>JSON value</em> <strong>MUST</strong> be a <em>JSON string</em> that is also a value author handle.</p>
|
||
<p>See
|
||
FAQ on “<a href="#author_handle_faq">author handle</a>”
|
||
for more information about an author handles.</p>
|
||
<p>Normally the <em>author_handle</em> <em>JSON value</em> should <strong>NOT</strong> be changed
|
||
<strong>unless there is a strong reason to do so</strong>. If the <em>JSON value</em>
|
||
changes, then all of the <code>.entry.json</code> files for all of this authors
|
||
winning IOCCC entries should also be changed. The <em>author_handle</em>
|
||
<em>JSON value</em> must match the basename (without the leading path and
|
||
without the trailing <code>.json</code>) of the <code>author_handle.json</code> file. So
|
||
a change of <em>author_handle</em> <em>JSON value</em> would also require the
|
||
<code>author_handle.json</code> file to also be renamed.</p>
|
||
<h5 id="full_name">full_name</h5>
|
||
<pre><code> "full_name" : "Yusuke Endoh",</code></pre>
|
||
<p>This <em>JSON member</em> holds the full name of the author.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>full_name</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be a <em>JSON string</em>.</p>
|
||
<p>The full name of an author may use non-ASCII characters so long as the
|
||
full name is properly encoded as a <em>JSON string</em>.</p>
|
||
<h5 id="sort_word">sort_word</h5>
|
||
<pre><code> "sort_word" : "endoh",</code></pre>
|
||
<p>This <em>JSON member</em> holds the string that will be used to sort the author.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>sort_word</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be a <em>JSON string</em>. Moreover the string <strong>MUST</strong> be a lower case ASCII
|
||
alphanumeric string that starts with a lower case ASCII letter.</p>
|
||
<p>The <em>JSON value</em> is used, for example, to place a reference to the author
|
||
in the <code>/authors.html</code> file.</p>
|
||
<p>Normally the <code>sort_word</code> <em>JSON member</em> <em>JSON value</em> is the last
|
||
name of the author, translated into lower case ASCII alphanumeric
|
||
string that starts with a lower case ASCII letter. If the author
|
||
wishes to be found in the <code>/authors.html</code> file under a different
|
||
string, such as if they wish to be listed under their first name
|
||
or their username, then they may change this accordingly.</p>
|
||
<h5 id="location_code">location_code</h5>
|
||
<pre><code> "location_code" : "JP",</code></pre>
|
||
<p>This <em>JSON member</em> holds the string that is the
|
||
<a href="https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table">ISO 3166-1 alpha-2 code</a>
|
||
of the author’s location or country.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>location_code</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be a <em>JSON string</em>. Moreover the string <strong>MUST</strong> be 2 character UPPER case ASCII
|
||
alphabetic string that is <strong>NOT</strong> an Unassigned
|
||
<a href="https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table">ISO 3166-1 alpha-2 code</a> value
|
||
(not a 2 character symbol with a gray background on that Wikipedia table)</p>
|
||
<p>The <code>soup/location</code> tool from the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry repo</a>,
|
||
when run without arguments, will print the ISO 3166-1 alpha-2 codes that permitted, along with
|
||
the location name.</p>
|
||
<p>We use the term “location” (and not “country”) because some of the
|
||
ISO 3166-1 alpha-2 codes belong to locations that are not technically
|
||
a country, such as “Antarctica” or a User-assigned code.</p>
|
||
<p>If the author wishes to not specify a location, they should select <strong>XX</strong>.</p>
|
||
<h5 id="email">email</h5>
|
||
<pre><code> "email" : "mame@ruby-lang.org",</code></pre>
|
||
<p>This <em>JSON member</em> holds the email address of the author, or is the value null.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>email</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be a <em>JSON string</em> or it <strong>MUST</strong> be a <em>JSON null</em>.</p>
|
||
<p>If the author wishes to not specify an email address, or if the email address is
|
||
unknown, it should be the <em>JSON null</em> as the <em>JSON value</em> of this <em>JSON member</em>.
|
||
For example:</p>
|
||
<pre><code> "email" : null,</code></pre>
|
||
<p>NOTE: The <em>JSON null</em> is <strong>NOT</strong> enclosed in quotes!</p>
|
||
<h5 id="url">url</h5>
|
||
<pre><code> "url" : "https://mametter.hatenablog.com",</code></pre>
|
||
<p>This <em>JSON member</em> holds the URL of the author’s home page.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>url</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be a <em>JSON string</em> or it <strong>MUST</strong> be a <em>JSON null</em>.</p>
|
||
<p>If the author wishes to not specify a URL or if the URL is
|
||
unknown, it should be the <em>JSON null</em> as the <em>JSON value</em> of this <em>JSON
|
||
member</em>. For example:</p>
|
||
<pre><code> "url" : null,</code></pre>
|
||
<p>NOTE: The <em>JSON null</em> is <strong>NOT</strong> enclosed in quotes!</p>
|
||
<h5 id="alt_url">alt_url</h5>
|
||
<pre><code> "alt_url" : null,</code></pre>
|
||
<p>This <em>JSON member</em> holds an alternate or 2nd URL a home page for the author.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>alt_url</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be a <em>JSON string</em> or it <strong>MUST</strong> be a <em>JSON null</em>.</p>
|
||
<p>In some cases the author may wish to record a special URL for their IOCCC entry,
|
||
or a 2nd URL such as a work or school or personal home page. For example,
|
||
Cody as of <em>Thu Nov 30 23:51:12 UTC 2023</em> used:</p>
|
||
<pre><code> "alt_url" : "https://ioccc.xexyl.net",</code></pre>
|
||
<p>If the author wishes to not specify an alternate URL, or if the alternate URL is
|
||
unknown, it should be the <em>JSON null</em> as the <em>JSON value</em> of this <em>JSON
|
||
member</em>. For example:</p>
|
||
<pre><code> "alt_url" : null,</code></pre>
|
||
<p>NOTE: The <em>JSON null</em> is <strong>NOT</strong> enclosed in quotes!</p>
|
||
<h5 id="deprecated_twitter_handle">deprecated_twitter_handle</h5>
|
||
<p>This <em>JSON member</em> used to hold the twitter handle of the author.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>deprecated_twitter_handle</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be a <em>JSON string</em> or it <strong>MUST</strong> be a <em>JSON null</em>.</p>
|
||
<p>The IOCCC no longer is associated with twitter (or whatever someone chooses to call it),
|
||
and so the <code>deprecated_twitter_handle</code> is <strong>no longer used</strong>. A <em>JSON value</em> that is
|
||
not a <em>JSON null</em> is kept for only historic reasons. For example, Anthony C. Howe
|
||
once used:</p>
|
||
<pre><code> "deprecated_twitter_handle" : "@SirWumpus",</code></pre>
|
||
<p>If the author wishes to not specify a twitter handle, or if the twitter handle is
|
||
unknown, it should be the <em>JSON null</em> as the <em>JSON value</em> of this <em>JSON member</em>.
|
||
For example:</p>
|
||
<pre><code> "deprecated_twitter_handle" : null,</code></pre>
|
||
<p>Of course in the future we will not be asking for twitter handles so this means
|
||
that unless the winner is a previous winner (before we moved to mastodon) this
|
||
will always be <code>null</code> anyway.</p>
|
||
<p>NOTE: The <em>JSON null</em> is <strong>NOT</strong> enclosed in quotes!</p>
|
||
<h5 id="mastodon">mastodon</h5>
|
||
<pre><code> "mastodon" : "@mame@ruby.social",</code></pre>
|
||
<p>This <em>JSON member</em> holds the
|
||
<a href="https://en.wikipedia.org/wiki/Mastodon_(social_network)">Mastodon social network</a>
|
||
handle of the author.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>mastodon</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be a <em>JSON string</em> or it <strong>MUST</strong> be a <em>JSON null</em>. The <em>JSON string</em> just be a valid
|
||
Mastodon handle. In particular is must start with an at sign (<em><span class="citation" data-cites="_">@_</span>), followed by the
|
||
Mastodon username, followed by a 2nd sign (</em>@_), followed by the Mastodon server instance
|
||
used by the author.</p>
|
||
<p>For more information in Mastodon, see the <a href="https://mastodon.help">Mastodon help</a> guide.
|
||
See the “Mastodon Address” section of that page in particular.</p>
|
||
<p>The IOCCC Mastodon handle is:</p>
|
||
<pre><code> @ioccc@fosstodon.org</code></pre>
|
||
<p>The IOCCC uses the Mastodon social network for announcements such
|
||
as the opening and closing of a new IOCCC, changes to the IOCCC web
|
||
site, updates during the judging process, and when new IOCCC entries
|
||
are selected. We recommend you follow us on Mastodon.</p>
|
||
<p>If the author wishes to not specify an Mastodon handle, or if the Mastodon handle is
|
||
unknown, it should be the <em>JSON null</em> as the <em>JSON value</em> of this <em>JSON member</em>.
|
||
For example:</p>
|
||
<pre><code> "mastodon" : null,</code></pre>
|
||
<p>NOTE: The <em>JSON null</em> is <strong>NOT</strong> enclosed in quotes!</p>
|
||
<h5 id="mastodon_url">mastodon_url</h5>
|
||
<pre><code> "mastodon_url" : "https://ruby.social/@mame",</code></pre>
|
||
<p>This <em>JSON member</em> holds the URL of the author’s Mastodon page.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>mastodon_url</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be a <em>JSON string</em> or it <strong>MUST</strong> be a <em>JSON null</em>. The <em>JSON string</em> just be a valid URL.
|
||
If the <code>mastodon</code> handle is a <em>JSON null</em>, them the <code>mastodon_url</code> <strong>MUST</strong> be a <em>JSON null</em>.
|
||
If the <code>mastodon</code> handle is a <em>JSON string</em>, then the <code>mastodon_url</code> <strong>MUST</strong> be a <em>JSON string</em>.</p>
|
||
<p>The <code>mastodon_url</code> is just a translation of the above mentioned Mastodon handle.
|
||
For example, if the Mastodon handle is:</p>
|
||
<pre><code> @user@server.domain</code></pre>
|
||
<p>Then the <code>mastodon_url</code> would be:</p>
|
||
<pre><code> https://server.domain/@user</code></pre>
|
||
<p>If the author wishes to not specify an Mastodon URL, or if the Mastodon URL is
|
||
unknown, it should be the <em>JSON null</em> as the <em>JSON value</em> of this <em>JSON member</em>.
|
||
For example:</p>
|
||
<pre><code> "mastodon_url" : null,</code></pre>
|
||
<p>NOTE: The <em>JSON null</em> is <strong>NOT</strong> enclosed in quotes!</p>
|
||
<p>See
|
||
FAQ on “<a href="#try_mastodon">Mastodon</a>”
|
||
for more information on Mastodon.</p>
|
||
<h5 id="github">github</h5>
|
||
<pre><code> "github" : "@mame",</code></pre>
|
||
<p>This <em>JSON member</em> holds the <a href="https://github.com">GitHub</a> handle of the author.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>github</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be a <em>JSON string</em> or it <strong>MUST</strong> be a <em>JSON null</em>. The <code>github</code> <em>JSON string</em> <strong>MUST</strong>
|
||
start with an at sign (_<span class="citation" data-cites="_">@_</span>) and <strong>MUST</strong> be a valid GitHub username.</p>
|
||
<p>The IOCCC uses GitHub to hold the <a href="https://github.com/ioccc-src/winner">official winner repo of the IOCCC</a>,
|
||
and hosts <a href="https://www.ioccc.org">official IOCCC website</a> on GitHub pages.</p>
|
||
<p>The IOCCC GitHub handle is:</p>
|
||
<pre><code> @ioccc-src</code></pre>
|
||
<p>If the author wishes to not specify an GitHub handle, or if the GitHub handle is
|
||
unknown, it should be the <em>JSON null</em> as the <em>JSON value</em> of this <em>JSON member</em>.
|
||
For example:</p>
|
||
<pre><code> "github" : null,</code></pre>
|
||
<p>NOTE: The <em>JSON null</em> is <strong>NOT</strong> enclosed in quotes!</p>
|
||
<h5 id="affiliation">affiliation</h5>
|
||
<pre><code> "affiliation" : null,</code></pre>
|
||
<p>This <em>JSON member</em> holds the affiliation of the author.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>affiliation</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be a <em>JSON string</em> or it <strong>MUST</strong> be a <em>JSON null</em>.</p>
|
||
<p>An affiliation might be the name of a school, university, company, or organization.
|
||
It is recommended that the affiliation <em>JSON string</em> be the formal affiliation name.
|
||
For example, the affiliation for the IOCCC would be:</p>
|
||
<pre><code> The International Obfuscared C Code Contest</code></pre>
|
||
<p>If the author wishes to not specify an affiliation, or if the affiliation is
|
||
unknown, it should be the <em>JSON null</em> as the <em>JSON value</em> of this <em>JSON member</em>.
|
||
For example:</p>
|
||
<pre><code> "affiliation" : null,</code></pre>
|
||
<p>NOTE: The <em>JSON null</em> is <strong>NOT</strong> enclosed in quotes!</p>
|
||
<h5 id="winning_entry_set">winning_entry_set</h5>
|
||
<h5 id="entry_id">entry_id</h5>
|
||
<pre><code> "winning_entry_set" : [
|
||
{ "entry_id" : "2012_endoh1" },
|
||
{ "entry_id" : "2012_endoh2" },
|
||
{ "entry_id" : "2013_endoh1" },
|
||
...
|
||
{ "entry_id" : "2020_endoh1" },
|
||
{ "entry_id" : "2020_endoh2" },
|
||
{ "entry_id" : "2020_endoh3" }
|
||
]</code></pre>
|
||
<p>The <code>winning_entry_set</code> <em>JSON member</em> holds <em>JSON array</em> containing one or more <code>entry_id</code> _JSON member_s.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>winning_entry_set</code> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be a non-empty <em>JSON array</em>. Each value in that <em>JSON array</em> <strong>MUST</strong> must contain
|
||
a <em>JSON member</em> whose <em>JSON name</em> <strong>MUST</strong> be “<em>entry_id</em>” and those <em>JSON value</em>
|
||
is a valid entry ID.</p>
|
||
<p>Due to the nature of the <em>So-called JSON spec</em>, the last value of the <code>winning_entry_set</code>
|
||
<em>JSON array</em> cannot end in a comma (<em>,</em>).</p>
|
||
<p>See
|
||
FAQ on “<a href="#author_json">author_handle.json</a>”
|
||
for information about entry ids.</p>
|
||
<p>See
|
||
FAQ on “<a href="#fix_author">fixing author information</a>”
|
||
for information about how to update
|
||
and/or correct IOCCC author information.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_7">
|
||
<!-- we cannot use id="entry_id" because of a header in FAQ 6.6 -->
|
||
<div id="entry_id_faq">
|
||
<h3 id="faq-6.7-what-is-an-entry_id">FAQ 6.7: What is an <code>entry_id</code>?</h3>
|
||
</div>
|
||
</div>
|
||
<p>A <code>entry_id</code> is a string that identifies a winning entry of the IOCCC.</p>
|
||
<p>A <code>entry_id</code> is a 4-digit year, followed by an underscore, followed by a directory name.</p>
|
||
<p>For example, the <code>entry_id</code> associated with Cody Boone Ferguson’s 2nd winning IOCCC entry
|
||
of 2020 is found under the following directory:</p>
|
||
<pre><code> 2020/ferguson2</code></pre>
|
||
<p>The <code>entry_id</code> for that winning entry is:</p>
|
||
<pre><code> 2020_ferguson2</code></pre>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_8">
|
||
<div id="dot_path">
|
||
<div id="dot_year">
|
||
<div id="dot_allyear">
|
||
<div id="dot_top">
|
||
<h3 id="faq-6.8-what-is-the-purpose-of-the-.top-.allyear-.year-and-.path-files">FAQ 6.8: What is the purpose of the .top, .allyear, .year and .path files?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>The <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/.top">.top</a> file resides at the top directory. This file contains the complete list
|
||
of IOCCC years.</p>
|
||
<p>Under each IOCCC year. one will find a <code>.year</code> file. These files contain directory paths from the top directory,
|
||
of the IOCCC entry directories for a given year. For example, see the <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1984/.year">1984/.year</a> file.</p>
|
||
<p>The <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/.allyear">.allyear</a> file contains the contents of all <code>.year</code> files for all IOCCC years.</p>
|
||
<p>Under each IOCCC entry directory, you will find a <code>.path</code> file.
|
||
These files contain the directory path from the top directory.
|
||
For example see <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1984/anonymous/.path">1984/anonymous/.path</a>.</p>
|
||
<p>The .top, .allyear, .year and .path files are generated from the top level Makefile, by:</p>
|
||
<pre><code> make genpath</code></pre>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_9">
|
||
<div id="terms">
|
||
<h3 id="faq-6.9-what-is-the-current-meaning-of-the-ioccc-terms-author-entry-and-submission">FAQ 6.9: What is the current meaning of the IOCCC terms Author, Entry, and Submission?</h3>
|
||
</div>
|
||
</div>
|
||
<p>The IOCCC is now attempting to use the following terms:</p>
|
||
<ul>
|
||
<li>Author</li>
|
||
</ul>
|
||
<p>An <em>author</em> is someone who has submitted an entry that has won the IOCCC.</p>
|
||
<p>An entry can have more than one authors. A number of authors have submitted
|
||
entries that have won the IOCCC, sometimes in the same IOCCC contest year.</p>
|
||
<p><strong>An apology for being inconsistent</strong>: In the past, the IOCCC used the term <em>winner</em> to
|
||
refer to what is now an <em>author</em>. In a number of historical cases,
|
||
such as old rules and old guidelines, terms such as <em>winner</em> may still be
|
||
found. Moreover, out of habit, the IOCCC judges sometimes use old
|
||
names such as <em>winner</em> when they should use <em>author</em>. Sorry (tm Canada)! :-)</p>
|
||
<ul>
|
||
<li>Entry</li>
|
||
</ul>
|
||
<p>An <em>entry</em> is a <em>submission</em> that won the IOCCC.</p>
|
||
<p>An <em>entry</em> has one or more <em>authors</em>.</p>
|
||
<p>An <em>entry</em> includes all of the files needed to compile it,
|
||
plus sample input files, a <code>Makefile</code>, an <code>.entry.json</code> file
|
||
describing the entry, a compressed tarball containing all of
|
||
files in the entry, etc. Under the IOCCC tree, an <em>entry</em>
|
||
that win the IOCCC in year <em>YYYY</em> is located under the
|
||
directory <code>YYYY/entry</code>.</p>
|
||
<p><strong>An apology for being inconsistent</strong>: In the past, the IOCCC used the term <em>winner</em> to
|
||
refer to what is now an <em>entry</em>. In a number of historical cases,
|
||
such as old rules and old guidelines, terms such as <em>winner</em> may still be
|
||
found. Moreover, out of habit, the IOCCC judges sometimes use old
|
||
names such as <em>winner</em> when they should use <em>entry</em>. Sorry (tm Canada)! :-)</p>
|
||
<ul>
|
||
<li>Submission</li>
|
||
</ul>
|
||
<p>A <em>submission</em> is something given to the IOCCC judges
|
||
for consideration when the IOCCC is open.</p>
|
||
<p>When the IOCCC is open for submissions, those who register
|
||
to enter the IOCCC may use the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry tool</a>
|
||
to package their code into a compressed tarball that may be
|
||
uploaded to the <a href="https://submit.ioccc.org">IOCCC submit server</a>.
|
||
This compressed tarball is formatted in such a way that
|
||
the IOCCC judges do not see who wrote the code.</p>
|
||
<p>A <em>submission</em> that the IOCCC judges deem to have won the IOCCC
|
||
becomes an <em>entry</em>. Only then do the IOCCC judges look into
|
||
the special JSON file to discover who the <em>author</em>(s) are.</p>
|
||
<p><strong>An apology for being inconsistent</strong>: In the past, the IOCCC used the term <em>entry</em> to
|
||
refer to what is now a <em>submission</em>. In a number of historical cases,
|
||
such as old rules and old guidelines, terms such as <em>entry</em> may still be
|
||
found. Moreover, out of habit, the IOCCC judges sometimes use old
|
||
names such as <em>entry</em> when they should use <em>submission</em>. Sorry (tm Canada)! :-)</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_10">
|
||
<div id="pull_request">
|
||
<div id="commit">
|
||
<h3 id="faq-6.10-how-does-someone-make-a-change-to-a-file-and-submit-that-change-as-a-github-pull-request">FAQ 6.10: How does someone make a change to a file and submit that change as a GitHub pull request?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>First, if you do not already have a GitHub account or you have not installed an
|
||
ssh key to your account you must do so. For this we will assume you do not have
|
||
a GitHub account. For the steps following creating a GitHub account you will
|
||
have to be logged into your account.</p>
|
||
<p>To help you out here is a navigation menu in this FAQ entry:</p>
|
||
<ul>
|
||
<li><a href="#creating-a-github-account">Creating a GitHub account</a></li>
|
||
<li><a href="#installing-an-ssh-key">Installing an ssh key to GitHub</a></li>
|
||
<li><a href="#forking-the-ioccc-winner-repo">Forking the IOCCC winner repo</a></li>
|
||
<li><a href="#cloning-the-ioccc-winner-repo">Cloning the IOCCC winner repo</a></li>
|
||
<li><a href="#making-changes-fixes-etc">Making changes, fixes etc.</a></li>
|
||
<li><a href="#committing-your-changes">Committing your changes</a></li>
|
||
<li><a href="#opening-a-pull-request">Opening a pull request</a></li>
|
||
<li><a href="#what-to-do-after-a-merge">What to do after a merge</a></li>
|
||
</ul>
|
||
<h4 id="creating-a-github-account">Creating a GitHub account</h4>
|
||
<p>Go to <a href="https://github.com/">GitHub</a> and click on ‘Sign up’. Follow the
|
||
instructions. Once you’ve completed this task make sure you log in to GitHub.</p>
|
||
<h4 id="installing-an-ssh-key-to-github">Installing an ssh key to GitHub</h4>
|
||
<p>Assuming you do not have an ssh key you should go to the command prompt and
|
||
type (if you already have one and are okay using it for GitHub you can use that
|
||
one):</p>
|
||
<pre><code> ssh-keygen -t rsa -b 4096 -C "luser@example.com"</code></pre>
|
||
<p>where <code>luser@example.com</code> is the email you want associated with your key.
|
||
Follow the instructions. It will tell you the key files.</p>
|
||
<p>Once you have an ssh key you need to go to your <a href="https://github.com/settings/profile">account
|
||
settings</a>. Once there, in the menu
|
||
on the left you should see the item <em>SSH and GPG keys</em>. Click that and then
|
||
click (on the right side) the button that says <em>New SSH key</em>. You will see that
|
||
you have to specify a title, the key type and the PUBLIC key. Put whatever title
|
||
you want and keep the key type as <em>Authentication Key</em>. Now you need to put the
|
||
PUBLIC key in.</p>
|
||
<p>If you used an rsa key the default file will likely be found in:
|
||
<code>~/.ssh/id_rsa.pub</code>. If you used a different algorithm the file name will be
|
||
different. For instance if you used <code>ed25519</code> the default PUBLIC key file would
|
||
be <code>~/.ssh/id_ed25519</code>. If, like some people do, you have a separate key for
|
||
GitHub, it could be anything you wish, as long as it’s in <code>~/.ssh</code>. For instance
|
||
it might be <code>~/.ssh/github.pub</code>.</p>
|
||
<p>Whatever the key file is, copy the contents and paste it into the GitHub field
|
||
labelled <em>Key</em>. Once you have done so click on <em>Add SSH key</em>.</p>
|
||
<h4 id="forking-the-ioccc-winner-repo">Forking the IOCCC winner repo</h4>
|
||
<p>Open in your browser the link:
|
||
<a href="https://github.com/ioccc-src/winner/fork" class="uri">https://github.com/ioccc-src/winner/fork</a>. You now should follow the
|
||
instructions in forking the repo.</p>
|
||
<h4 id="cloning-the-ioccc-winner-repo">Cloning the IOCCC winner repo</h4>
|
||
<p>Once you have forked the repo you are ready to clone it to your system. For
|
||
instance Cody Boone Ferguson has the GitHub handle <em>xexyl</em> so he would type in:</p>
|
||
<pre><code> git clone https://github.com/xexyl/winner [target_dir]</code></pre>
|
||
<p>Once that is completed you will need to change to that directory. The default
|
||
directory would be the name of the repo but if you specified a target directory
|
||
it will be that. For instance using the above example you might do:</p>
|
||
<pre><code> cd winner</code></pre>
|
||
<p>You’re ready to make your changes now!</p>
|
||
<h4 id="making-changes-fixes-etc.">Making changes, fixes etc.</h4>
|
||
<p>Here you must use your wits, knowledge, creativity and whatever else you have.
|
||
Let’s say that Cody wants to update his file
|
||
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2020/ferguson1/play.sh">2020/ferguson1/play.sh</a> script. He would open it in
|
||
his editor of choice (in his case vim) and make the changes. He would then make
|
||
sure (as there is a last updated date) to update the last updated date. For
|
||
instance he might add the following:</p>
|
||
<blockquote>
|
||
<p>BTW: did you know that some people believe in snake human hybrids? It’s true! See
|
||
http://www.macroevolution.net/snake-human-hybrids.html and have a laugh, shock
|
||
or an exercise in sibilance!</p>
|
||
</blockquote>
|
||
<p>Then, assuming that the date is 1 March 2024, he would update the line that
|
||
starts with <code># Last updated:</code> to refer to <code>01 March 2024</code> rather than what it
|
||
is now (at the time of writing this), <code>15 April 2023</code>.</p>
|
||
<p>But what if he wanted to add a file? He’d create the file and then type:</p>
|
||
<pre><code> git add foo</code></pre>
|
||
<p>where <em>foo</em> is the file to add.</p>
|
||
<p>When he’s ready to make a commit he would need to create a new branch for the
|
||
pull request.</p>
|
||
<h4 id="committing-your-changes">Committing your changes</h4>
|
||
<p>First, as an aside, if this is your first pull request (which we assume is if you’re
|
||
reading this :-) ) you need to make sure that you can push changes to GitHub
|
||
with your ssh key. To do this you need to do:</p>
|
||
<pre><code> ssh -T git@github.com</code></pre>
|
||
<p>Cody would see:</p>
|
||
<blockquote>
|
||
<p>Hi xexyl! You’ve successfully authenticated, but GitHub does not provide shell access.</p>
|
||
</blockquote>
|
||
<p>Now, assuming that the forked repo is
|
||
<a href="https://github.com/xexyl/winner" class="uri">https://github.com/xexyl/winner</a>, you’d type:</p>
|
||
<pre><code> git remote set-url origin git@github.com:xexyl/winner.git</code></pre>
|
||
<p>Now you’d be ready to make your commits.</p>
|
||
<p>Before doing anything else, however, a new branch needs to be created.
|
||
Continuing the example above for
|
||
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2020/ferguson1/play.sh">2020/ferguson1/play.sh</a>, it might be that:</p>
|
||
<pre><code> git checkout -B human-snakes</code></pre>
|
||
<p>This would change the branch to the newly created branch <code>human-snakes</code> branch.
|
||
Now Cody could commit the changes:</p>
|
||
<pre><code> git commit play.sh # if specifying specific files
|
||
git commit -a # if committing everything</code></pre>
|
||
<p>He could also have done:</p>
|
||
<pre><code> git add play.sh
|
||
git commit</code></pre>
|
||
<p>In any case this would open an editor (in his case vim) to write a commit log.
|
||
It is recommended that the first line is <=51 chars and the next line is blank.
|
||
Then if necessary add a description for the log. For instance the above might
|
||
warrant the log:</p>
|
||
<pre><code> Add fun link to 2020/ferguson1/play.sh
|
||
|
||
Did you know some people believe in snake human hybrids? I added a link to the
|
||
script that discusses this and gives supposed examples.</code></pre>
|
||
<p>Now a pull request has to be opened.</p>
|
||
<h4 id="opening-a-pull-request">Opening a pull request</h4>
|
||
<p>To do this depends on the branch name. Assuming the branch from above,
|
||
<code>human-snakes</code>, you would type:</p>
|
||
<pre><code> git push --set-upstream origin human-snakes</code></pre>
|
||
<p>This might show:</p>
|
||
<pre><code> Enumerating objects: 9, done.
|
||
Counting objects: 100% (9/9), done.
|
||
Delta compression using up to 10 threads
|
||
Compressing objects: 100% (5/5), done.
|
||
Writing objects: 100% (5/5), 739 bytes | 147.00 KiB/s, done.
|
||
Total 5 (delta 4), reused 0 (delta 0), pack-reused 0
|
||
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
|
||
remote:
|
||
remote: Create a pull request for 'human-snakes' on GitHub by visiting:
|
||
remote: https://github.com/xexyl/winner/pull/new/human-snakes
|
||
remote:
|
||
To github.com:xexyl/winner.git
|
||
* [new branch] human-snakes -> human-snakes
|
||
branch 'human-snakes' set up to track 'origin/human-snakes'.</code></pre>
|
||
<p>The link referred to above would then be opened to open a pull request. Just
|
||
follow the instructions at this point. If however it does not show a link it is
|
||
likely because the branch already exists in your GitHub account (for the repo).
|
||
In this case you can open the link:
|
||
<a href="https://github.com/ioccc-src/winner/pulls" class="uri">https://github.com/ioccc-src/winner/pulls</a> which might show something
|
||
like:</p>
|
||
<pre><code> xexyl:human-snakes had recent pushes 1 minute ago</code></pre>
|
||
<p>and to the right of it you would see a button that says <em>Compare & pull request</em>
|
||
which you could click on. Do that and follow the instructions.</p>
|
||
<p>An important note is if you have more than one pull request opened it’ll only
|
||
show the branch name as the summary. You should in that case copy paste the log
|
||
you put in into the website. For instance the line (on the website) <em>Add a
|
||
title</em> could have:</p>
|
||
<blockquote>
|
||
<p>Add fun link to 2020/ferguson1/play.sh</p>
|
||
</blockquote>
|
||
<p>and then the text field that is labelled <em>Add a description</em> would have:</p>
|
||
<blockquote>
|
||
<p>Did you know some people believe in snake human hybrids? I added a link to the
|
||
script that discusses this and gives supposed examples.</p>
|
||
</blockquote>
|
||
<p>Once you’ve done this you should click on <em>Create pull request</em>.</p>
|
||
<p>IMPORTANT NOTE: although the <a href="https://www.ioccc.org/judges.html">Judges</a> will
|
||
give more deference to the authors of edited entries the
|
||
<a href="https://www.ioccc.org/judges.html">Judges</a> also retain the final editorial say
|
||
in the matter.</p>
|
||
<h4 id="what-to-do-after-a-merge">What to do after a merge</h4>
|
||
<p>When the judges have merged the pull request you now need to make sure your fork
|
||
has the merge. To do this from the command line, assuming the fork in the above
|
||
example, you would type:</p>
|
||
<pre><code> git checkout master && git pull https://github.com/ioccc-src/winner.git master && git push origin master</code></pre>
|
||
<p>This will merge your pull request to your fork.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_11">
|
||
<div id="license">
|
||
<div id="licence">
|
||
<h3 id="faq-6.11-am-i-allowed-to-use-ioccc-content">FAQ 6.11: Am I allowed to use IOCCC content?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p><strong>Disclaimer</strong>: This FAQ is <strong>not a license</strong>, has <strong>no legal
|
||
value</strong>, and only highlights some of the key features and terms of
|
||
the actual <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.en">CC BY-SA 4.0
|
||
license</a>.</p>
|
||
<p>The content of the IOCCC is <a href="#copyright">Copyrighted and is under the CC BY-SA 4.0 License</a>.</p>
|
||
<p>As long as you abide by the terms of the <a href="https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1">CC BY-SA 4.0
|
||
License</a>
|
||
you may copy and redistribute the material in any medium or format
|
||
for any purpose, even commercially.</p>
|
||
<p>As long as you abide by the terms of the <a href="https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1">CC BY-SA 4.0
|
||
License</a>
|
||
you may remix, transform, and build upon the material for any
|
||
purpose, even commercially.</p>
|
||
<p>This FAQ is an incomplete summary of how you may use IOCCC content.
|
||
You should review the <a href="license.html">highlights of some of the key features and terms</a>
|
||
and this may help clarify some aspects of the
|
||
<a href="https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1">CC BY-SA 4.0 License</a>.</p>
|
||
<p>The <a href="#copyright">Copyright and CC BY-SA 4.0 License</a> applies to all
|
||
IOCCC content. We use this to help ensure that we can all
|
||
enjoy hat those working on the IOCCC have proper Attribution
|
||
including, of course, the IOCCC winners themselves! It is designed
|
||
to help ensure that everyone may enjoy the IOCCC.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_12">
|
||
<div id="try_mastodon">
|
||
<div id="mastodon">
|
||
<h3 id="faq-6.12-what-is-mastodon-and-why-does-ioccc-use-it">FAQ 6.12: What is Mastodon and why does IOCCC use it?</h3>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<p>The <a href="https://fosstodon.org/@ioccc">IOCCC uses Mastodon</a> for news updates,
|
||
announcements, and for various other social media purposes.</p>
|
||
<p><strong>Please follow the <a href="https://fosstodon.org/@ioccc">IOCCC on Mastodon</a></strong>.</p>
|
||
<blockquote>
|
||
<p>The IOCCC no longer uses twitter, or whatever that someone who appears to have
|
||
poor impulse control (allegedly) calls their platform these days.</p>
|
||
</blockquote>
|
||
<p>The IOCCC prefers to reside in the <a href="https://fediverse.info">fediverse</a>.</p>
|
||
<p><strong>For help with Mastodon</strong>:</p>
|
||
<p>There is <a href="https://mastodon.help">help with Mastodon</a> available for
|
||
those who might wish to <a href="https://fosstodon.org/deck/getting-started">get started with Mastodon</a>.</p>
|
||
<p>While there are many fine Mastodon server instances out there, the <a href="judges.html">IOCCC judges</a>
|
||
use <a href="https://fosstodon.org/about">fosstodon.org</a> where lots of fun folk hang out,
|
||
and topics like science, technology, <a href="https://en.wikipedia.org/wiki/Free_and_open-source_software">free and open source</a>
|
||
have a good home. The <a href="https://fosstodon.org/@fosstodon">fosstodon.org</a> folk made the IOCCC feel welcome.</p>
|
||
<p>While using Mastodon is free, the <a href="judges.html">IOCCC judges</a> are pleased to
|
||
<a href="https://hub.fosstodon.org/support/">support the Fosstodon Hub</a>.</p>
|
||
<p>If you have a phone or tablet there is also an official app that you can get
|
||
from the App Store or whatever equivalent your device has. Please note that the
|
||
app does not at this time seem to give push notifications when someone you
|
||
follow posts something so you will have to check the IOCCC feed manually.</p>
|
||
<p><strong>HINT to mastodon users</strong>: You may wish to refresh the <a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span>
|
||
mastodon feed</a> page and/or mastodon
|
||
app from time to time to view IOCCC mastodon updates.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_13">
|
||
<div id="find_author_handle">
|
||
<h3 id="faq-6.13-how-may-i-find-my-author-handle">FAQ 6.13: How may I find my author handle?</h3>
|
||
</div>
|
||
</div>
|
||
<p>If you are an <em>author</em> of a winning <em>entry</em>, you may find your own <em>author_handle</em>
|
||
by going to your entry in the <a href="authors.html">authors.html</a> web page and viewing the string
|
||
that follows the <em>author_handle</em>: line.</p>
|
||
<p>If you are not someone who has won a previous IOCCC, you will be able to select
|
||
a potential <em>author_handle</em> when you form your <em>submission</em> tarball (see
|
||
FAQ on “<a href="#submit">how to submit</a>”
|
||
).</p>
|
||
<p><strong>Helpful Hint</strong>: If an <em>author</em> clicks on their <em>author_handle:</em>
|
||
line link, you will be taken to that author’s <code>author_handle.json</code> file.</p>
|
||
<p>For example, <a href="authors.html#Brian_Westley">Brian Westley</a> can view his
|
||
author entry and see that his <em>author_handle</em> is <strong>Brian_Westley</strong>.
|
||
Clicking on the <em>author_handle</em> shows the contents of
|
||
the <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/author/Brian_Westley.json">Brian_Westley.json</a> file.</p>
|
||
<p><strong>IMPORTANT NOTE</strong>: An <code>author</code> who has won a previous IOCCC is encouraged to reuse their
|
||
<code>author_handle</code> so that new winning entries can be associated with the same author.</p>
|
||
<p>See
|
||
FAQ on “<a href="#fix_author">fixing author information</a>”
|
||
for information about how to update
|
||
and/or correct IOCCC author information.</p>
|
||
<p>See
|
||
FAQ on “<a href="#author_handle_faq">author handle</a>”
|
||
for more information about author handles.</p>
|
||
<p>See
|
||
FAQ on “<a href="#author_json">author_handle.json</a>”
|
||
for information about the contents of these JSON file and
|
||
how they are used.</p>
|
||
<p>See
|
||
FAQ on “<a href="#terms">Author, Entry, Submission</a>”
|
||
for more information on terms such as <em>author</em>, <em>entry</em>, and <em>submission</em>.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_14">
|
||
<div id="tabstops">
|
||
<h3 id="faq-6.14-how-do-i-set-certain-tabstops-for-viewing-source-code-in-vim">FAQ 6.14: How do I set certain tabstops for viewing source code in vi(m)?</h3>
|
||
</div>
|
||
</div>
|
||
<p>Sometimes an author will state that for best viewing purposes you should have
|
||
your tabstop set at say 4 or 8. If you use vim or vi or vim in no compatible
|
||
mode you can do this easily: make sure you’re in command mode (in most cases you
|
||
can hit ESC to do this) and then type the command:</p>
|
||
<pre><code> :set tabstop=4</code></pre>
|
||
<p>where <code>4</code> is the value you wish to set the tabstop to.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_15">
|
||
<div id="menus">
|
||
<h3 id="faq-6.15---how-do-the-menus-on-the-website-work-and-what-can-i-do-if-they-dont-work">FAQ 6.15 - How do the menus on the website work and what can I do if they don’t work?</h3>
|
||
</div>
|
||
</div>
|
||
<div id="desktop_menu">
|
||
<h4 id="menu-on-desktops-or-laptop-computers">Menu on desktops or laptop computers</h4>
|
||
</div>
|
||
<p>The way the menu works on desktops or laptops is that you should simply see the
|
||
menu directly without the need of JavaScript or any intervention on your part.
|
||
It should look something like:</p>
|
||
<p><img src="png/ioccc-menu-desktop.png"
|
||
alt="screenshot of IOCCC menu on desktops"
|
||
width=912 height=160></p>
|
||
<p>Simply move your mouse cursor over the category you want and then click on the
|
||
item you wish to view that drops down from the category.</p>
|
||
<p>This is likely how it will appear with a <a href="#tablet_menu">tablet device in landscape
|
||
mode</a>, too, unless <a href="#no_javascript_menu">JavaScript is
|
||
disabled</a>.</p>
|
||
<div id="mobile_menus">
|
||
<h4 id="mobile-menus">Mobile menus</h4>
|
||
</div>
|
||
<p>If, however, you’re on a mobile device, it can vary, depending on the dimensions
|
||
and whether or not you have JavaScript enabled.</p>
|
||
<div id="mobile_phone_menu">
|
||
<h5 id="menus-on-mobile-phones">Menus on mobile phones</h5>
|
||
</div>
|
||
<p>For instance, on an iPhone 14
|
||
Pro Max or similar device (in dimensions), you should see at the top right of
|
||
every page, something that looks like:</p>
|
||
<p><img src="png/ioccc-menu-mobile-phone.png"
|
||
alt="screenshot of IOCCC menu on iPhone 14 Pro Max"
|
||
width=1290 height=527></p>
|
||
<p>In this case click on the icon at the top right corner that looks like:</p>
|
||
<p><img src="png/hamburger-icon-open.png"
|
||
alt="menu open icon"
|
||
width=24 height=24></p>
|
||
<p>to activate the menu.</p>
|
||
<div id="no_javascript_menu">
|
||
<h5 id="menu-on-mobile-devices-if-javascript-is-disabled">Menu on mobile devices if JavaScript is disabled</h5>
|
||
</div>
|
||
<p>If JavaScript is disabled on any mobile device, tablet or phone, you should see
|
||
the words:</p>
|
||
<pre><code> Please Enable JavaScript</code></pre>
|
||
<p>at the top right corner; clicking on this will take you to the <a href="nojs-menu.html">no JavaScript
|
||
menu</a> which is a plaintext menu. You of course can use this if
|
||
you like, even if you do not have JavaScript enabled, by pointing your browser
|
||
to <a href="https://ioccc-src.github.io/temp-test-ioccc/nojs-menu.html" class="uri">https://ioccc-src.github.io/temp-test-ioccc/nojs-menu.html</a>.</p>
|
||
<div id="tablet_menu">
|
||
<h5 id="menus-on-tablet-devices-e.g.-ipads">Menus on tablet devices (e.g. iPads)</h5>
|
||
</div>
|
||
<p>With tablets, it likely depends on the orientation you have your device in. If it’s
|
||
in portrait mode you likely will see the <a href="#mobile_phone_menu">menu that one will get on a mobile
|
||
phone</a>.</p>
|
||
<p>If, on the other hand, you are using landscape mode, say on an iPad Pro 11 inch
|
||
4th generation, then you will likely see the <a href="#desktop_menu">menu as you would on a desktop or
|
||
laptop</a>.</p>
|
||
<div id="1024px_menu">
|
||
<h5 id="menus-on-mobile-devices-wider-than-1024-pixels">Menus on mobile devices wider than 1024 pixels</h5>
|
||
</div>
|
||
<p>Finally, if you’re on a mobile device that is wider than 1024 pixels, you will
|
||
very possibly have to <strong>press and hold</strong> the menu icon:</p>
|
||
<p><img src="png/hamburger-icon-open.png"
|
||
alt="menu open icon"
|
||
width=24 height=24></p>
|
||
<p>to activate it. You can then use it <a href="#mobile_phone_menu">as you would on a mobile
|
||
phone</a>.</p>
|
||
<div id="browser_bug_menu">
|
||
<h5 id="browsing-the-website-on-mobile-devices-with-a-browser-bug">Browsing the website on mobile devices with a browser bug</h5>
|
||
</div>
|
||
<p>It was noticed that in iOS 16 Safari (both on an iPhone 8 Plus and in simulation
|
||
mode in macOS) the menu does not work at all. That is to say one might see:</p>
|
||
<p><img src="png/ioccc-menu-browser-bug.png"
|
||
alt="browser bug where menu icon does not show up"
|
||
width=1242 height=531></p>
|
||
<p>Notice how the menu icon is not even there! This happens in both portrait mode
|
||
and landscape mode.</p>
|
||
<p>In this case one will have to use the <a href="#no_javascript_menu">no JavaScript
|
||
menu</a>. If you have a fix for this that <strong>does NOT
|
||
affect the usability of desktops, laptops or other mobile devices</strong>, please
|
||
consider fixing it and <a href="#pull_request">opening a pull request</a> or at
|
||
least <a href="https://github.com/ioccc-src/temp-test-ioccc/issues/new/choose">report it as an
|
||
issue</a> (choose
|
||
the category <em>Website issue</em>).</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_16">
|
||
<div id="author-information">
|
||
<h3 id="faq-6.16---how-do-i-find-more-information-about-a-winning-author-of-an-entry">FAQ 6.16 - How do I find more information about a winning author of an entry?</h3>
|
||
</div>
|
||
</div>
|
||
<p>At the top of the index.html file of a winning entry with the author you want
|
||
information on, you should see a section called <code>Author</code>. All you have to do is
|
||
click on the author’s name (it’s a link) and it will take you to their
|
||
information in the <a href="authors.html">authors.html</a> page.</p>
|
||
<p>There you will find various information including a link to their
|
||
<a href="authors.html">authors.html</a> information which includes various things like
|
||
their GitHub account (if known), a URL or alternate UL, mastodon handle,
|
||
location (if known and not anonymous location) and a link to their JSON author file.</p>
|
||
<p><strong>NOTE</strong>: you might wish to search google (or some other search engine) by their
|
||
name as sometimes you can find out their GitHub account even if it’s not in our
|
||
JSON files.</p>
|
||
<p>Of course if you know the author’s name you can go directly to
|
||
<a href="authors.html">authors.html</a> and click on their surname’s/last name’s/second
|
||
name’s initial and then scroll down (if necessary) to the author in question.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_17">
|
||
<div id="entry_json">
|
||
<h3 id="faq-6.17-what-is-a-.entry.json-file-and-how-is-they-used">FAQ 6.17: What is a <code>.entry.json</code> file and how is they used?</h3>
|
||
</div>
|
||
</div>
|
||
<p><strong>TL:DR</strong>: The contents of this JSON file contain information about each winning
|
||
entry in JSON format.</p>
|
||
<p>Each winning entry has a <code>.entry.json</code> file that includes data in JSON format
|
||
about the entry. We describe the fields below in order to help you understand
|
||
its contents.</p>
|
||
<p>This file is created by the <a href="bin/index.html#cvt-submission">cvt-submission.sh</a>
|
||
tool as part of the final steps to announce a new set of winning IOCCC entries.</p>
|
||
<p>Each winning entry has its own <code>.entry.json</code> filename of the form:</p>
|
||
<pre><code> YYYY/winner/.entry.json</code></pre>
|
||
<p>where <em>winner</em> is the entry directory name, usually the name of the author.</p>
|
||
<p><strong>IMPORTANT NOTE</strong>: this file should <strong>NOT</strong> be manually modified! It is created
|
||
by the <a href="bin/index.html#csv2entry">csv2entry</a> tool when updating the manifest.</p>
|
||
<h4 id="entry.json-json-file-contents"><code>.entry.json</code> JSON file contents</h4>
|
||
<p>The syntax of a <code>.entry.json</code> follows the <em>So-called JSON spec</em>.
|
||
See <a href="https://www.json.org/json-en.html" class="uri">https://www.json.org/json-en.html</a> for information on the <em>So-called JSON
|
||
spec</em>.</p>
|
||
<p>A good way to understand the JSON file contents of a <code>.entry.json</code> file
|
||
is to look at an example, for instance the
|
||
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1984/laman/.entry.json">1984/laman/.entry.json</a> file, as
|
||
it is shorter than some of the others.</p>
|
||
<p>As of <em>Fri 26 Jul 2024 17:29:15 UTC</em>, it contains:</p>
|
||
<pre><code> {
|
||
"no_comment" : "mandatory comment: because comments were removed from the original JSON spec",
|
||
"entry_JSON_format_version" : "1.1 2024-02-11",
|
||
"award" : "Third Place",
|
||
"year" : 1984,
|
||
"dir" : "laman",
|
||
"entry_id" : "1984_laman",
|
||
"author_set" : [
|
||
{ "author_handle" : "Mike_Laman" }
|
||
],
|
||
"manifest" : [
|
||
{
|
||
"file_path" : "laman.c",
|
||
"inventory_order" : 20,
|
||
"OK_to_edit" : true,
|
||
"display_as" : "c",
|
||
"display_via_github" : true,
|
||
"entry_text" : "entry source code"
|
||
},
|
||
{
|
||
"file_path" : "Makefile",
|
||
"inventory_order" : 30,
|
||
"OK_to_edit" : true,
|
||
"display_as" : "makefile",
|
||
"display_via_github" : true,
|
||
"entry_text" : "entry Makefile"
|
||
},
|
||
{
|
||
"file_path" : "laman.orig.c",
|
||
"inventory_order" : 50,
|
||
"OK_to_edit" : false,
|
||
"display_as" : "c",
|
||
"display_via_github" : true,
|
||
"entry_text" : "original source code"
|
||
},
|
||
{
|
||
"file_path" : "try.sh",
|
||
"inventory_order" : 100,
|
||
"OK_to_edit" : true,
|
||
"display_as" : "shellscript",
|
||
"display_via_github" : true,
|
||
"entry_text" : "script to try entry"
|
||
},
|
||
{
|
||
"file_path" : "1984_laman.tar.bz2",
|
||
"inventory_order" : 1415926535,
|
||
"OK_to_edit" : false,
|
||
"display_as" : "tbz2",
|
||
"display_via_github" : false,
|
||
"entry_text" : "download entry tarball"
|
||
},
|
||
{
|
||
"file_path" : ".entry.json",
|
||
"inventory_order" : 4000000000,
|
||
"OK_to_edit" : true,
|
||
"display_as" : "json",
|
||
"display_via_github" : true,
|
||
"entry_text" : "entry summary and manifest in JSON"
|
||
},
|
||
{
|
||
"file_path" : ".gitignore",
|
||
"inventory_order" : 4000000000,
|
||
"OK_to_edit" : true,
|
||
"display_as" : "gitignore",
|
||
"display_via_github" : true,
|
||
"entry_text" : "list of files that should not be committed under git"
|
||
},
|
||
{
|
||
"file_path" : ".path",
|
||
"inventory_order" : 4000000000,
|
||
"OK_to_edit" : false,
|
||
"display_as" : "path",
|
||
"display_via_github" : true,
|
||
"entry_text" : "directory path from top level directory"
|
||
},
|
||
{
|
||
"file_path" : "README.md",
|
||
"inventory_order" : 4000000000,
|
||
"OK_to_edit" : true,
|
||
"display_as" : "markdown",
|
||
"display_via_github" : true,
|
||
"entry_text" : "markdown source for this web page"
|
||
},
|
||
{
|
||
"file_path" : "index.html",
|
||
"inventory_order" : 4294967295,
|
||
"OK_to_edit" : false,
|
||
"display_as" : "html",
|
||
"display_via_github" : false,
|
||
"entry_text" : "this web page"
|
||
}
|
||
]
|
||
}
|
||
</code></pre>
|
||
<div id="walk_through_entry_json">
|
||
<h5 id="walk-through-of-a-.entry.json-file">Walk through of a <code>.entry.json</code> file</h5>
|
||
</div>
|
||
<p>We now will walk through the above JSON document looking at all the JSON
|
||
members:</p>
|
||
<h5 id="no_comment-1"><code>no_comment</code></h5>
|
||
<pre><code> "no_comment" : "mandatory comment: because comments were removed from the original JSON spec",</code></pre>
|
||
<p>Because the authors of the so-called JSON spec removed the ability to use comments in JSON
|
||
(for reason(s) that seem to be less than credible), the IOCCC mandates this <em>JSON member</em>
|
||
be present in all IOCCC related JSON files.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>no_comment</code> <em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong>
|
||
be the exact <em>JSON string</em> as shown above.</p>
|
||
<h5 id="entry_json_format_version"><code>entry_JSON_format_version</code></h5>
|
||
<pre><code> "entry_JSON_format_version" : "1.1 2024-02-11",</code></pre>
|
||
<p>This <em>JSON member</em> holds the format version of the <code>.entry.json</code> JSON file.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>entry_JSON_format_version</code>
|
||
<em>JSON member</em> and the <em>JSON value</em> <strong>MUST</strong> be a <em>JSON string</em>.</p>
|
||
<p>This is <strong>NOT</strong> the version of the contents!</p>
|
||
<p>The <code>entry_JSON_format_version</code> would only changed when the overall format
|
||
of the these files is modified: and then only those who maintain the
|
||
<a href="https://www.ioccc.org">official IOCCC website</a> would be the one to do this
|
||
in conjunction with changes to <a href="bin/index.html">bin directory tools</a>.</p>
|
||
<h5 id="award"><code>award</code></h5>
|
||
<pre><code> "award" : "Third Place",</code></pre>
|
||
<p>This JSON string is the award title of the entry which the <a href="judges.html">Judges</a>
|
||
decide/decided when it becomes/became a winning entry.</p>
|
||
<h5 id="year"><code>year</code></h5>
|
||
<pre><code> "year" : 1984,</code></pre>
|
||
<p>This JSON number is the year the contest ran, ended or was announced in.</p>
|
||
<h5 id="dir"><code>dir</code></h5>
|
||
<pre><code> "dir" : "laman",</code></pre>
|
||
<p>This JSON string is the subdirectory of the entry, <strong>under</strong> the year directory,
|
||
in this case <a href="1984/index.html">1984</a>. With the above member, <code>year</code>, and this
|
||
one, one can determine the directory of the entry, here being
|
||
<a href="1984/laman/index.html">1984/laman</a>.</p>
|
||
<h5 id="entry_id-1"><code>entry_id</code></h5>
|
||
<pre><code> "entry_id" : "1984_laman",</code></pre>
|
||
<p>This is the ID of the entry in question and corresponds to the <code>entry_id</code> in the
|
||
<code>author/author_handle.json</code> file.</p>
|
||
<p>See
|
||
FAQ on “<a href="#author_handle_faq">author handle</a>”
|
||
for more information about author handles.</p>
|
||
<p>See
|
||
FAQ on “<a href="#author_json">author_handle.json</a>”
|
||
for information about the contents of these JSON file and
|
||
how they are used.</p>
|
||
<h5 id="author_set"><code>author_set</code></h5>
|
||
<pre><code> "author_set" : [
|
||
{ "author_handle" : "Mike_Laman" }
|
||
],</code></pre>
|
||
<p>This JSON <strong>array</strong> has a list of <code>author_handle</code>s that indicate who won this
|
||
entry.</p>
|
||
<p>That <em>JSON member</em> holds the author handle of the author.</p>
|
||
<p>In most cases there is only one <code>author_handle</code> in a <code>.entry.json</code> file but in
|
||
some there is more than one.</p>
|
||
<p>See
|
||
FAQ on “<a href="#author_handle_faq">author handle</a>”
|
||
for more information about an author handles.</p>
|
||
<p>Normally the <code>author_handle</code> <em>JSON value</em> should <strong>NOT</strong> be changed
|
||
<strong>unless there is a strong reason to do so</strong>. If the <em>JSON value</em>
|
||
changes, then all of the <code>.entry.json</code> files for all of this author’s
|
||
winning IOCCC entries should also be changed. The <code>author_handle</code>
|
||
<em>JSON value</em> must match the basename (without the leading path and
|
||
without the trailing <code>.json</code>) of the <code>author_handle.json</code> file. So
|
||
a change of <code>author_handle</code> <em>JSON value</em> would also require the
|
||
<code>author_handle.json</code> file to also be renamed.</p>
|
||
<p>The full name of an author may use non-ASCII characters so long as the
|
||
full name is properly encoded as a <em>JSON string</em>.</p>
|
||
<h5 id="manifest"><code>manifest</code></h5>
|
||
<p>Finally there is the manifest JSON <strong>array</strong> that lists the files of the winning
|
||
entry. Because each array member (a file) has the same fields we will only list
|
||
one of the files in the manifest, providing comments about each field. After
|
||
that we will list some files that are mandatory files, also with comments.</p>
|
||
<p>There <strong>MUST</strong> be one and only one <code>manifest</code> <em>JSON member</em> and the <em>JSON value</em>
|
||
<strong>MUST</strong> be a <em>JSON</em> array.</p>
|
||
<p>A shortened manifest for our example entry is:</p>
|
||
<pre><code> "manifest" : [
|
||
{
|
||
"file_path" : "laman.c",
|
||
"inventory_order" : 20,
|
||
"OK_to_edit" : true,
|
||
"display_as" : "c",
|
||
"display_via_github" : true,
|
||
"entry_text" : "entry source code"
|
||
}
|
||
]</code></pre>
|
||
<p>Now we will describe each field of each file in the manifest:</p>
|
||
<ul>
|
||
<li><p><code>file_path</code> (string)</p>
|
||
<ul>
|
||
<li>This <em>JSON</em> <strong>string</strong> is the name of the file in question.</li>
|
||
</ul></li>
|
||
<li><p><code>inventory_order</code> (number)</p>
|
||
<ul>
|
||
<li>This <em>JSON</em> <strong>number</strong> decides which file list in the <code>index.html</code> file this
|
||
file is listed and its order in that list. The details are beyond the scope
|
||
of this document and it is only necessary to understand this if you are
|
||
adding a file to the manifest. However as the <a href="judges.html">Judges</a> are the
|
||
ones who will be doing this this need not concern you.</li>
|
||
</ul></li>
|
||
<li><p><code>OK_to_edit</code> (boolean)</p>
|
||
<ul>
|
||
<li>This <em>JSON</em> <strong>boolean</strong> indicates whether this file should be modified,
|
||
edited, replaced, or even removed directly.</li>
|
||
</ul>
|
||
<p>If <code>true</code> then a modification (i.e., edit) of the file, replacement of the file,
|
||
or even removal os the file would be welcome via a pull request.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information about pull requests.</p>
|
||
<p>If <code>false</code>, then the file almost certainlty should <strong>NOT</strong> be modified
|
||
(i.e., edited), replaced or removed. Submitting a pull request that impacts
|
||
such a <code>false</code> <code>OK_to_edit</code> file is likely to cause the pull request
|
||
to be modifed or rejected.</p>
|
||
<p><strong>IMPORTANT NOTE</strong>: In most all cases, <code>OK_to_edit</code> should be set to <code>true</code>.
|
||
There are only a few cases when <code>OK_to_edit</code> needs to be <code>false</code> that are documented below:</p>
|
||
<ul>
|
||
<li><strong>Reason for <code>OK_to_edit == false</code> # 0</strong>:</li>
|
||
</ul>
|
||
<p>The file is original source code file.</p>
|
||
<p>Modifications of the <strong>original source code</strong> is only permitted it can
|
||
be shown at the file is not the true <strong>original source code</strong>.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#original_source_file">original source code</a>”
|
||
for more information including how to open an <a href="https://github.com/ioccc-src/winner/issues">IOCCC issue</a>
|
||
if you believe the <strong>original source code</strong> is not a true original.</p>
|
||
<ul>
|
||
<li><strong>Reason for <code>OK_to_edit == false</code> # 1</strong>:</li>
|
||
</ul>
|
||
<p>The HTML file is generated by a <a href="bin/index.html">set of tools and scripts</a>(including a related <code>Makefile</code> rule).</p>
|
||
<p>Modifing HTML files that contain comments such as “<em>DO NOT MODIFY THIS FILE …</em>”
|
||
or “<em>Do not modify this web page …</em>” will not have the desired effect
|
||
because any modications will be overridden when the <a href="bin/index.html">set of tools and scripts</a>
|
||
(includeing a related <code>Makefile</code> rule).</p>
|
||
<p>In order to properly change a generated HTML file, files such as a markdown file
|
||
(often <code>README.md</code>) and/or sometimes JSON files (such as <code>.entry.json</code> or
|
||
the <code>author/author_handle.json</code> JSON files)</p>
|
||
<p>See the
|
||
FAQ on “<a href="#fix_web_site">fix web site</a>”
|
||
for information on submitting fixes to the IOCCC website.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#fix_author">update IOCCC author information</a>”
|
||
for information how to modify <code>author/author_handle.json</code> JSON files.</p>
|
||
<ul>
|
||
<li><strong>Reason for <code>OK_to_edit == false</code> # 2</strong>:</li>
|
||
</ul>
|
||
<p>The file is a compressed tarball for an entry or set of entries for a given IOCCC year.</p>
|
||
<p>Compressed tarball files are provided as a conveience for those who wish th download
|
||
an IOCCC entry or all IOCCC entries for a given IOCCC year. These files are generate
|
||
by <a href="bin/index.html">set of tools and scripts</a>(including a related <code>Makefile</code> rules).</p>
|
||
<p>Instead of trying to modify a compressed tarball, individual files that make
|
||
up the compressed tarball should be modified instead. When you pull request to modify
|
||
such individual files, the <a href="judges.html">IOCCC judges</a> will run the appropriate
|
||
<a href="bin/index.html">set of tools and scripts</a> to update the compressed tarballs as needed.</p>
|
||
<ul>
|
||
<li><strong>Reason for <code>OK_to_edit == false</code> # 3</strong>:</li>
|
||
</ul>
|
||
<p>The file is a <code>.path</code> file.</p>
|
||
<p>As the <code>.path</code> file is related to the path of the entry under an IOCCC year,
|
||
this file should be consider as <strong>read-only</strong>.</p>
|
||
<p>If you believe a <code>.path</code> file is in error, then please open up an
|
||
<a href="https://github.com/ioccc-src/winner/issues">IOCCC issue</a>.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#dot_path">.path files</a>”
|
||
for more information on <code>.path</code> files.</p>
|
||
<p>See also the
|
||
FAQ on “<a href="#fix_an_entry">fixing an entry</a>”
|
||
for information on opening up an IOCCC issue.</p>
|
||
<ul>
|
||
<li><strong>Reason for <code>OK_to_edit == false</code> # 4</strong>:</li>
|
||
</ul>
|
||
<p>There is some rare case or reason we forgot to document.</p>
|
||
<p>The reasons previously listed for why the <code>OK_to_edit</code> set to <code>false</code> may be incomplete,
|
||
or there is some special rare case. More likely, however, if some other file has
|
||
<code>OK_to_edit</code> set to <code>false</code>, is a mistake.</p>
|
||
<p>If you believe if <code>OK_to_edit</code> has the wrong value, please open a GitHub pull request.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#pull_request">GitHub pull request</a>”
|
||
for more information about pull requests.</p></li>
|
||
<li><p><code>display_as</code> (string)</p>
|
||
<ul>
|
||
<li>This <em>JSON</em> <strong>string</strong> describes what kind of file it is and in particular
|
||
how to <strong>display</strong> it. An entry source code file would be (all strings are
|
||
lower case) <code>c</code>, a shell script would be <code>shellscript</code> and a <code>Makefile</code>
|
||
would be <code>makefile</code>, for three examples of others. As updating the manifest
|
||
is mostly a task for the <a href="judges.html">Judges</a> you need not concern yourself
|
||
with all the different names.</li>
|
||
</ul></li>
|
||
<li><p><code>display_via_github</code> (boolean)</p>
|
||
<ul>
|
||
<li>This <em>JSON</em> <strong>boolean</strong> indicates whether the file should be viewed at
|
||
(that is linked to) GitHub or not. A good reason it might be viewed at
|
||
GitHub is for syntax highlighting or if it should not be downloaded but
|
||
would likely be downloaded by the browser otherwise.</li>
|
||
</ul></li>
|
||
<li><p><code>entry_text</code> (string)</p>
|
||
<ul>
|
||
<li>This <em>JSON</em> <strong>string</strong> is a short string that gives a summary of what the
|
||
file is, for purposes of the file lists in the <code>index.html</code> inventory.</li>
|
||
</ul></li>
|
||
</ul>
|
||
<p>Now that we have discussed the <em>JSON members</em> of each file in the <code>manifest</code> we
|
||
will give a list of <strong>MANDATORY</strong> files (for winning entry source code the names
|
||
will depend on the year).</p>
|
||
<ul>
|
||
<li><p>the entry source code</p>
|
||
<ul>
|
||
<li>This file is typically called <code>winner.c</code>, where <code>winner</code> is as described
|
||
above, or <code>prog.c</code> (for later years). The <code>entry_text</code> is always <code>"entry source code"</code>.</li>
|
||
</ul></li>
|
||
<li><p>the entry Makefile</p>
|
||
<ul>
|
||
<li>This is the submission’s Makefile <strong>modified</strong> by the <a href="judges.html">Judges</a>,
|
||
should the submission win. The <code>entry_text</code> is always <code>"entry Makefile"</code> and
|
||
the <code>file_path</code> is <strong>ALWAYS</strong> <code>"Makefile"</code>.</li>
|
||
</ul></li>
|
||
<li><p>the original source code file</p>
|
||
<ul>
|
||
<li>This is the entry source code file that was submitted and that won. This
|
||
will be named either <code>winner.orig.c</code> or <code>prog.orig.c</code>, depending on the
|
||
year. This file may <strong>NOT</strong> be modified. The <code>entry_text</code> for this file is
|
||
always <code>"original source code"</code>.</li>
|
||
</ul>
|
||
<p>See the
|
||
FAQ on “<a href="#original_source_code">original source code</a>”
|
||
for more information.</p></li>
|
||
<li><p>the <a href="#tarball">entry tarball</a></p>
|
||
<ul>
|
||
<li>This is the tarball of just the top level Makefile (and those included by
|
||
it) and the entry itself, for convenience. It is named in the form of
|
||
<code>YYYY_winner.tar.bz2</code>. For instance, for <a href="1984/laman/index.html">1984/laman</a>
|
||
it is called <code>1984_laman.tar.bz2</code>. This file is <strong>NOT</strong> displayed via
|
||
GitHub. The <code>entry_text</code> is always <code>download entry tarball</code> as it is a file
|
||
that is to be downloaded, should one wish to.</li>
|
||
</ul></li>
|
||
<li><p><a href="#entry_json">.entry.json</a> file</p>
|
||
<ul>
|
||
<li>This is the file we’re currently discussing, the <code>.entry.json</code> file. The
|
||
<code>entry_text</code> is always <code>"entry summary and manifest in JSON"</code> and the
|
||
<code>file_path</code> is <strong>ALWAYS</strong> <code>".entry.json"</code>.</li>
|
||
</ul></li>
|
||
<li><p><code>.gitignore</code></p>
|
||
<ul>
|
||
<li>The list of files that should not be committed under git. Its <code>entry_text</code>
|
||
is always <code>"list of files that should not be committed under git"</code> and the
|
||
<code>file_path</code> is <strong>ALWAYS</strong> <code>".gitignore"</code>.</li>
|
||
</ul></li>
|
||
<li><p><code>.path</code></p>
|
||
<ul>
|
||
<li>This file contains the path to the entry subdirectory from the top level
|
||
directory. For instance for <a href="1984/laman/index.html">1984/laman</a> it is
|
||
<code>"1984/laman"</code>. This file’s <code>entry_text</code> is always <code>"directory path from top level directory"</code> and the <code>file_path</code> is <strong>ALWAYS</strong> <code>".path"</code>.</li>
|
||
</ul></li>
|
||
<li><p><code>README.md</code></p>
|
||
<ul>
|
||
<li>This file is the markdown source file for the <code>index.html</code> file. Its
|
||
<code>entry_text</code> is always <code>"markdown source for this web page"</code> (because it is
|
||
listed in <code>index.html</code>) and the <code>file_path</code> is <strong>ALWAYS</strong> <code>"README.md"</code>
|
||
(renamed from the <code>remarks.md</code> provided in submissions).</li>
|
||
</ul>
|
||
<p>In most cases, if the entry has other html files then they are also formed
|
||
from markdown files and the <code>entry_text</code> will be similar; the <code>file_path</code> in
|
||
these cases will be the same as the html file except it will have the
|
||
extension <code>.md</code>.</p></li>
|
||
<li><p><code>index.html</code></p>
|
||
<ul>
|
||
<li>This is the main page of the entry, formed from the <code>README.md</code> file. Its
|
||
<code>entry_text</code> is always <code>"this web page"</code> and its <code>file_path</code> is <strong>ALWAYS</strong>
|
||
<code>"index.html"</code>.</li>
|
||
</ul></li>
|
||
</ul>
|
||
<p>If the entry has an alternate source code file, often it will be in the form of
|
||
<code>"winner.alt.c"</code> or <code>"prog.alt.c"</code>; this is also what the <code>file_path</code> will be.
|
||
The <code>entry_text</code> will typically (not always but almost always) be <code>"alternate source code"</code>.</p>
|
||
<p>Many entries have a script (or scripts) for the <code>Try</code> section in their index.html file.
|
||
Usually this is called <code>try.sh</code> for the entry and <code>try.alt.sh</code> for the alternate
|
||
source code (if there is an alternate version). Some, however, have another file
|
||
name. The <code>entry_text</code> for the <code>try</code> scripts will be <code>script to try entry</code> or
|
||
something along those lines.</p>
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<div id="faq6_18">
|
||
<div id="explain_IOCCC">
|
||
<h3 id="faq-6.18-i-do-not-understand-the-ioccc-can-you-explain-it-to-me">FAQ 6.18: I do not understand the IOCCC, can you explain it to me?</h3>
|
||
</div>
|
||
</div>
|
||
<p>The IOCCC stands for the International Obfuscated C Code Contest.
|
||
The IOCCC is a C programming contest.</p>
|
||
<p>The goals of the IOCCC are:</p>
|
||
<ul>
|
||
<li>To write the most Obscure/Obfuscated C program within the rules.</li>
|
||
<li>To show the importance of programming style, in an ironic way.</li>
|
||
<li>To stress C compilers with unusual code.</li>
|
||
<li>To illustrate some of the subtleties of the C language.</li>
|
||
<li>To provide a safe forum for poor C code. :-)</li>
|
||
<li>To have fun with C!</li>
|
||
</ul>
|
||
<p>See the
|
||
FAQ on “<a href="#ioccc_start">start of the IOCCC</a>”
|
||
and the
|
||
FAQ on “<a href="#website_history">history of the IOCCC</a>”
|
||
for more information the background of the IOCCC.</p>
|
||
<p>See the
|
||
FAQ on “<a href="#submit">entering the IOCCC</a>”
|
||
for information on how to enter and submit to the IOCCC.</p>
|
||
<p>If you are still confused, consider the nature of
|
||
the <a href="next/rules.html">IOCCC rules</a> and of the <a href="next/guidelines.html">IOCCC
|
||
guidelines</a>. You will see a dose of the technical,
|
||
mixed with “nerd humor” (or humour if you prefer 🤓).</p>
|
||
<p>If after all that you are still confused, sorry (tm Canada 😉).
|
||
Consider this: While the IOCCC often attempts to be presentable,
|
||
it is under no obligation to be wholly understandable. One might
|
||
say that to truly understand the IOCCC is problematic. And if
|
||
someone did manage to fully understand the IOCCC, then perhaps
|
||
this <strong>modified</strong> quote from the <a href="https://en.wikipedia.org/wiki/The_Hitchhiker's_Guide_to_the_Galaxy">The Hitchhiker’s Guide to the
|
||
Galaxy</a>
|
||
may apply:</p>
|
||
<blockquote>
|
||
<p>“There is a theory which states that if ever anyone discovers
|
||
exactly what the IOCCC is for and why it is here, it will
|
||
instantly disappear and be replaced by something even more bizarre
|
||
and inexplicable.</p>
|
||
<p>There is another theory which states that this has
|
||
<a href="#great_fork_merge">already happened</a>.” 😜</p>
|
||
</blockquote>
|
||
<p>Share and enjoy! ☺️</p>
|
||
<hr style="width:10%;text-align:left;margin-left:0">
|
||
<p>Jump to: <a href="#">top</a></p>
|
||
<!--
|
||
|
||
Copyright © 1984-2024 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/
|
||
|
||
-->
|
||
<!-- AFTER: last line of markdown file: faq.md -->
|
||
|
||
<!-- 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-2024 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-2024 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%2Fioccc-src.github.io%2Ftemp-test-ioccc%2Ffaq.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 -->
|