Created `quick-start.md` to hold the FAQ 0.0 content. Used `sgit(1)` to change: * faq.html#enter ==> quick-start.html#enter * faq.html#enter_questions ==> quick-start.html#enter_questions * faq.html#step_0 ==> quick-start.html#step_0 * faq.html#step_1 ==> quick-start.html#step_1 * faq.html#step_2 ==> quick-start.html#step_2 * faq.html#register ==> quick-start.html#register * faq.html#step_3 ==> quick-start.html#step_3 * faq.html#step_4 ==> quick-start.html#step_4 * faq.html#step_5 ==> quick-start.html#step_5 * faq.html#step_6 ==> quick-start.html#step_6 * faq.html#step_7 ==> quick-start.html#step_7 * faq.html#step_submit ==> quick-start.html#step_submit Via: ```sh sgit -e 's/faq\.html#enter/quick-start.html#enter/g' '*.md' '*.hdr' 'inc/*.html' sgit -e 's/faq\.html#enter_questions/quick-start.html#enter_questions/g' '*.md' '*.hdr' 'inc/*.html' sgit -e 's/faq\.html#step_0/quick-start.html#step_0/g' '*.md' '*.hdr' 'inc/*.html' sgit -e 's/faq\.html#step_1/quick-start.html#step_1/g' '*.md' '*.hdr' 'inc/*.html' sgit -e 's/faq\.html#step_2/quick-start.html#step_2/g' '*.md' '*.hdr' 'inc/*.html' sgit -e 's/faq\.html#register/quick-start.html#register/g' '*.md' '*.hdr' 'inc/*.html' sgit -e 's/faq\.html#step_3/quick-start.html#step_3/g' '*.md' '*.hdr' 'inc/*.html' sgit -e 's/faq\.html#step_4/quick-start.html#step_4/g' '*.md' '*.hdr' 'inc/*.html' sgit -e 's/faq\.html#step_5/quick-start.html#step_5/g' '*.md' '*.hdr' 'inc/*.html' sgit -e 's/faq\.html#step_6/quick-start.html#step_6/g' '*.md' '*.hdr' 'inc/*.html' sgit -e 's/faq\.html#step_7/quick-start.html#step_7/g' '*.md' '*.hdr' 'inc/*.html' sgit -e 's/faq\.html#step_submit/quick-start.html#step_submit/g' '*.md' '*.hdr' 'inc/*.html' ``` The former FAQ 0.0 section in `faq.html` now just refers to `quick-start.html`. Modified menu and non-JS menu so that "Enter the IOCCC" refers to `quick-start.html`. Changed `bin/gen-top-html.sh` VERSION from "1.4.10 2024-11-23" to "1.4.11 2025-01-09". Performed `make www` on macOS to complete the above.
1102 lines
44 KiB
HTML
1102 lines
44 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>2005/anon - Best 3D puzzle</title>
|
||
<link rel="icon" type="image/x-icon" href="../../favicon.ico">
|
||
<meta name="description" content="2005 IOCCC entry anon - Best 3D puzzle">
|
||
<meta name="keywords" content="IOCCC, 2005, IOCCC 2005, IOCCC entry, anon, Best 3D puzzle">
|
||
</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/readme2index.sh -->
|
||
<!-- The content of main section of this web page came from: 2005/anon/README.md -->
|
||
<!-- -->
|
||
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: 2005/anon/README.md !!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: 2005/anon/README.md !!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: 2005/anon/README.md !!! -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
|
||
<!-- Markdown content was converted into HTML via the tool: bin/md2html.sh -->
|
||
|
||
<!-- START: this line starts content from: inc/body.default.html -->
|
||
|
||
<body>
|
||
|
||
<!-- END: this line ends content from: inc/body.default.html -->
|
||
<!-- START: this line starts content from: inc/topbar.default.html -->
|
||
|
||
<div class="theader">
|
||
<nav class="topbar">
|
||
<div class="container">
|
||
<div class="logo">
|
||
<a href="../../index.html" class="logo-link">
|
||
IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="topbar-items">
|
||
<div class="item">
|
||
<span class="item-header">
|
||
Entries
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
<div class="outfit-font">
|
||
<a href="../../years.html" class="sub-item-link">
|
||
Winning entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../authors.html" class="sub-item-link">
|
||
Winning authors
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../location.html" class="sub-item-link">
|
||
Location of authors
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../bugs.html" class="sub-item-link">
|
||
Bugs and (mis)features
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html#fix_an_entry" class="sub-item-link">
|
||
Fixing entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html#fix_author" class="sub-item-link">
|
||
Updating author info
|
||
</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
Status
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
<div class="outfit-font">
|
||
<a href="../../news.html" class="sub-item-link">
|
||
News
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../status.html" class="sub-item-link">
|
||
Contest status
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../next/index.html" class="sub-item-link">
|
||
Rules and guidelines
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../markdown.html" class="sub-item-link">
|
||
Markdown guidelines
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../SECURITY.html" class="sub-item-link">
|
||
Security policy
|
||
</a>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
FAQ
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html" class="sub-item-link">
|
||
Frequently Asked Questions
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../quick-start.html#enter" class="sub-item-link">
|
||
Enter the IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html#compiling" class="sub-item-link">
|
||
Compiling entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html#running_entries" class="sub-item-link">
|
||
Running entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html#help" class="sub-item-link">
|
||
How to help
|
||
</a>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
About
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
<div class="outfit-font">
|
||
<a href="../../index.html" class="sub-item-link">
|
||
Home page
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../about.html" class="sub-item-link">
|
||
About the IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../judges.html" class="sub-item-link">
|
||
The Judges
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../thanks-for-help.html" class="sub-item-link">
|
||
Thanks for the help
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../contact.html" class="sub-item-link">
|
||
Contact us
|
||
</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</nav>
|
||
|
||
<div class="header-mobile-menu">
|
||
<noscript>
|
||
<a href="../../nojs-menu.html" class="topbar-js-label">
|
||
Please Enable JavaScript
|
||
</a>
|
||
</noscript>
|
||
|
||
<button id="header-open-menu-button" class="topbar-mobile-menu">
|
||
<img
|
||
src="../../png/hamburger-icon-open.png"
|
||
alt="hamburger style menu icon - open state"
|
||
width=48
|
||
height=48>
|
||
</button>
|
||
|
||
<button id="header-close-menu-button" class="hide-content">
|
||
<img
|
||
src="../../png/hamburger-icon-closed.png"
|
||
alt="hamburger style menu icon - closed state"
|
||
width=48
|
||
height=48>
|
||
</button>
|
||
|
||
<div id="mobile-menu-panel" class="hide-content">
|
||
<div class="mobile-menu-container">
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
Entries
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../../years.html">
|
||
Winning entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../authors.html">
|
||
Winning authors
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../location.html">
|
||
Location of authors
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../bugs.html">
|
||
Bugs and (mis)features
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../faq.html#fix_an_entry">
|
||
Fixing entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../faq.html#fix_author">
|
||
Updating author info
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../thanks-for-help.html">
|
||
Thanks for the help
|
||
</a>
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
|
||
<div class="mobile-menu-item">
|
||
Status
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../../news.html">
|
||
News
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../status.html">
|
||
Contest status
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../next/index.html">
|
||
Rules and guidelines
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../markdown.html">
|
||
Markdown guidelines
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../SECURITY.html">
|
||
Security policy
|
||
</a>
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
FAQ
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../../faq.html">
|
||
Frequently Asked Questions
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../quick-start.html#enter">
|
||
Enter the IOCCC
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../faq.html#compiling">
|
||
Compiling entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../faq.html#running_entries">
|
||
Running entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../faq.html#help">
|
||
How to help
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
About
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../../index.html">
|
||
Home page
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../about.html">
|
||
About the IOCCC
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../judges.html">
|
||
The Judges
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../contact.html">
|
||
Contact us
|
||
</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
</div>
|
||
|
||
<script>
|
||
var headerOpenMenuButton = document.getElementById("header-open-menu-button");
|
||
var headerCloseMenuButton = document.getElementById("header-close-menu-button");
|
||
var mobileMenuPanel = document.getElementById("mobile-menu-panel");
|
||
|
||
headerOpenMenuButton.addEventListener("click", () => {
|
||
headerOpenMenuButton.classList.remove("topbar-mobile-menu");
|
||
headerOpenMenuButton.classList.add("hide-content");
|
||
|
||
headerCloseMenuButton.classList.remove("hide-content");
|
||
headerCloseMenuButton.classList.add("topbar-mobile-menu");
|
||
|
||
mobileMenuPanel.classList.remove("hide-content");
|
||
mobileMenuPanel.classList.add("topbar-mobile-panel");
|
||
});
|
||
|
||
headerCloseMenuButton.addEventListener("click", () => {
|
||
headerCloseMenuButton.classList.remove("topbar-mobile-menu");
|
||
headerCloseMenuButton.classList.add("hide-content");
|
||
|
||
mobileMenuPanel.classList.add("hide-content");
|
||
mobileMenuPanel.classList.remove("topbar-mobile-panel");
|
||
|
||
headerOpenMenuButton.classList.add("topbar-mobile-menu");
|
||
headerOpenMenuButton.classList.remove("hide-content");
|
||
});
|
||
</script>
|
||
|
||
<!-- END: this line ends content from: inc/topbar.default.html -->
|
||
<!-- START: this line starts content from: inc/header.default.html -->
|
||
|
||
<div class="header">
|
||
<a href="../../2011/zucker/index.html">
|
||
<img src="../../png/ioccc.png"
|
||
alt="IOCCC image by Matt Zucker"
|
||
width=300
|
||
height=110>
|
||
</a>
|
||
<h1>The International Obfuscated C Code Contest</h1>
|
||
<h2>2005/anon - Best 3D puzzle</h2>
|
||
<h3>Multi-dimensional sliding tile puzzle generator</h3>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/header.default.html -->
|
||
<!-- START: this line starts content from: inc/navbar.mid.html -->
|
||
|
||
<div class="navbar">
|
||
<a class="Left" href="../aidan/index.html">← 2005/aidan</a>
|
||
<a class="Left" href="../index.html">↑ 2005 ↑</a>
|
||
<a class="Left" href="../boutines/index.html">2005/boutines →</a>
|
||
<a class="Right" href="https://github.com/ioccc-src/winner/blob/master/2005/anon/anon.c">C code</a>
|
||
<a class="Right" href="https://github.com/ioccc-src/winner/blob/master/2005/anon/Makefile">Makefile</a>
|
||
<a class="Right" href="#inventory">Inventory</a>
|
||
<a class="Right" href="https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.ioccc.org%2F2005%2Fanon%2Findex.html">✓</a>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/navbar.mid.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 20 by: bin/output-index-author.sh via bin/md2html.sh -->
|
||
|
||
<!-- START: this line starts content generated by: bin/output-index-author.sh -->
|
||
|
||
<h2 id="author">Author:</h2>
|
||
<ul>
|
||
<li>Name: <a href="../../authors.html#Anonymous_2005">Anonymous 2005</a><br>
|
||
Location: <a href="../../location.html#ZZ">ZZ</a> - <em>Unknown location</em></li>
|
||
</ul>
|
||
|
||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||
|
||
<!-- END: this line ends content for HTML phase 20 by: bin/output-index-author.sh via bin/md2html.sh -->
|
||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||
|
||
<!-- BEFORE: 1st line of markdown file: 2005/anon/README.md -->
|
||
<h2 id="to-build">To build:</h2>
|
||
<pre><code> make</code></pre>
|
||
<p><strong>NOTE</strong>: there is an alternate version for vi(m) like movements. See <a href="#alternate-code">Alternate
|
||
code</a> below. If your terminal has problems with the
|
||
<code>stty(1)</code> commands try:</p>
|
||
<pre><code> make anon-no_stty</code></pre>
|
||
<p>This will compile <a href="https://github.com/ioccc-src/winner/blob/master/2005/anon/anon.c">anon.c</a> as <code>anon</code> to not use
|
||
<code>stty(1)</code>, with the support of an <code>#ifdef..#endif</code> added by the author.</p>
|
||
<h3 id="bugs-and-misfeatures">Bugs and (Mis)features:</h3>
|
||
<p>The current status of this entry is:</p>
|
||
<blockquote>
|
||
<p><strong>STATUS: INABIAF - please DO NOT fix</strong></p>
|
||
</blockquote>
|
||
<p>For more detailed information see <a href="../../bugs.html#2005_anon">2005/anon in bugs.html</a>.</p>
|
||
<h2 id="to-use">To use:</h2>
|
||
<pre><code> ./anon x y [z]</code></pre>
|
||
<h2 id="try">Try:</h2>
|
||
<pre><code> ./anon 4 4
|
||
|
||
./anon 3 3 3</code></pre>
|
||
<p>After a very large number of moves this program will deliberately force itself
|
||
to destroy its runtime stack. This is the author’s way to prevent you from being
|
||
frustrated (which might happen as it likes to create unsolvable puzzles just to
|
||
hook you) and spending too much time playing. :-)</p>
|
||
<p>If you want to see this in action you can easily do this:</p>
|
||
<pre><code> yes 'please crash on me :-)' | ./anon 4 4</code></pre>
|
||
<p>What happens if you specify a larger board? For instance:</p>
|
||
<pre><code> yes 'please crash on me :-)' | ./anon 10 10 10</code></pre>
|
||
<p>If you specify more than three args the program might also crash or do
|
||
something strange. This might also happen if you specify excessively large board
|
||
dimensions. Try <code>100 100 100</code> for instance and see what happens!</p>
|
||
<h2 id="alternate-code">Alternate code:</h2>
|
||
<p>The alternate version uses <code>vi(m)</code> like movement keys.</p>
|
||
<h3 id="alternate-build">Alternate build:</h3>
|
||
<pre><code> make alt</code></pre>
|
||
<p>To compile the version without <code>stty(1)</code>:</p>
|
||
<pre><code> make alt-no_stty</code></pre>
|
||
<h3 id="alternate-use">Alternate use:</h3>
|
||
<p>Use <code>anon.alt</code> as you would <code>anon</code> with the change in movements:</p>
|
||
<ul>
|
||
<li><code>k</code>
|
||
<ul>
|
||
<li>Move empty spot up</li>
|
||
</ul></li>
|
||
<li><code>h</code>
|
||
<ul>
|
||
<li>Move empty spot left</li>
|
||
</ul></li>
|
||
<li><code>j</code>
|
||
<ul>
|
||
<li>Move empty spot down</li>
|
||
</ul></li>
|
||
<li><code>l</code>
|
||
<ul>
|
||
<li>Move empty spot right</li>
|
||
</ul></li>
|
||
<li><code>J</code>
|
||
<ul>
|
||
<li>Move empty spot forwards</li>
|
||
</ul></li>
|
||
<li><code>K</code>
|
||
<ul>
|
||
<li>Move empty spot backwards</li>
|
||
</ul></li>
|
||
</ul>
|
||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||
<p>Taking the 4x4 board with 15 tiles to a whole new level, this entry takes this
|
||
puzzle to a whole new dimension! While you puzzle out this puzzle, we invite
|
||
you to take a good LONG look how and WHY <code>main()</code> is recursively called and how
|
||
the runtime stack is used.</p>
|
||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||
<h3 id="about-the-game-itself">ABOUT THE GAME ITSELF</h3>
|
||
<p>Remember Sam Loyd’s <a href="https://en.wikipedia.org/wiki/15_puzzle">Fifteen Puzzle</a>?
|
||
It consists of a 4x4 board with 15 tiles numbered 1 to 15, and an empty spot.
|
||
The goal of the game is to slide the tiles around without lifting them off the
|
||
board, so that they become sorted.</p>
|
||
<p>Well, that was then. This program is the 21st century version of the Fifteen
|
||
Puzzle: not only does it allow arbitrary board sizes, it also supports <em>3D</em>
|
||
boards! The tiles are numbered from 1 to N, where N is one less the number of
|
||
spaces on the board, and the goal is to rearrange them so that they appear
|
||
sorted in the order they appear on the screen.</p>
|
||
<p>The program takes 2 or 3 arguments, specifying the dimensions of the board.
|
||
For example, to play the original version of the Fifteen Puzzle:</p>
|
||
<pre><code> ./anon 4 4</code></pre>
|
||
<p>To play with a 3D board, do something like this:</p>
|
||
<pre><code> ./anon 3 3 3</code></pre>
|
||
<p><strong>WARNING</strong>: do NOT run the program with more than 3 command-line arguments.
|
||
This will trigger a bug that will cause it to crash or do something strange.
|
||
:-)</p>
|
||
<p>Also, resist the temptation to create very large puzzles. The program does not
|
||
attempt to resize your terminal for you, and will produce confusing output. It
|
||
may also crash on you if you insist on running it with excessively large board
|
||
dimensions. :-) (10x10x10 is considered a safe upper limit.)</p>
|
||
<p>The empty space on the board is represented by a space filled with <code>#</code>
|
||
characters instead of digits. To slide the tiles around, use the following
|
||
keys:</p>
|
||
<ul>
|
||
<li><code>i</code>
|
||
<ul>
|
||
<li>Slide the tile above the current empty space downwards.</li>
|
||
</ul></li>
|
||
<li><code>j</code>
|
||
<ul>
|
||
<li>Slide the tile to the left of the current empty space to the right.</li>
|
||
</ul></li>
|
||
<li><code>k</code>
|
||
<ul>
|
||
<li>Slide the tile below the current empty space upwards.</li>
|
||
</ul></li>
|
||
<li><code>l</code>
|
||
<ul>
|
||
<li>Slide the tile to the right of the current empty space to the left.</li>
|
||
</ul></li>
|
||
<li><code>o</code>
|
||
<ul>
|
||
<li>Slide the tile behind the current empty space forwards.</li>
|
||
</ul></li>
|
||
<li><code>n</code>
|
||
<ul>
|
||
<li>Slide the tile in front of the current empty space backwards.</li>
|
||
</ul></li>
|
||
</ul>
|
||
<p>To quit the game, hit <code>q</code>.</p>
|
||
<p>Note that, for example, sliding the tile above the current empty spot
|
||
downwards will fill up the empty spot, and create a new empty spot above where
|
||
the current empty spot was. Hence, you could think of the movement keys in
|
||
terms of how they effectively “move” the empty spot:</p>
|
||
<ul>
|
||
<li><code>i</code>
|
||
<ul>
|
||
<li>Move empty spot up</li>
|
||
</ul></li>
|
||
<li><code>j</code>
|
||
<ul>
|
||
<li>Move empty spot left</li>
|
||
</ul></li>
|
||
<li><code>k</code>
|
||
<ul>
|
||
<li>Move empty spot down</li>
|
||
</ul></li>
|
||
<li><code>l</code>
|
||
<ul>
|
||
<li>Move empty spot right</li>
|
||
</ul></li>
|
||
<li><code>n</code>
|
||
<ul>
|
||
<li>Move empty spot forwards</li>
|
||
</ul></li>
|
||
<li><code>o</code>
|
||
<ul>
|
||
<li>Move empty spot backwards</li>
|
||
</ul></li>
|
||
</ul>
|
||
<p><strong>NOTE:</strong> as a measure of alleviating counter-productivity due to addiction to
|
||
this game, particularly for those hardcore gamers who insist on solving a
|
||
10x10x10 puzzle during work hours, and also to give an upper bound to user
|
||
frustration when the program generates an unsolvable puzzle (which it does
|
||
roughly half the time, just to hook you), the program will, after a very large
|
||
number of moves (which is system-specific) terminate itself by forcefully
|
||
destroying its own runtime stack. This will result in a core dump and/or an
|
||
abnormal termination message; but this is a feature, not a bug! :-)</p>
|
||
<h3 id="compile-notes">COMPILE NOTES</h3>
|
||
<p>This program complies with ANSI/C99. It uses ANSI terminal control sequences,
|
||
and so requires a terminal that understands ANSI sequences, such as VT100 or
|
||
xterm.</p>
|
||
<p>Some compilers may emit lots of warnings about how things ought to be
|
||
parenthesized (e.g. <code>gcc -Wall</code>). This is deliberate, since if everything were
|
||
parenthesized “properly” the program would fail to work. It (ab)uses C
|
||
operator precedence to accomplish some cool hacks. :-) However, there are no
|
||
compiler errors. I have tested this with <code>gcc -pedantic -std=c99</code>.</p>
|
||
<p>The program also uses <code>stty cbreak</code>. If this breaks on your system, compile it
|
||
with <code>-DNO_STTY</code>. The game interface will be a bit annoying (you will need to
|
||
hit enter after every key), but it works.</p>
|
||
<p>The game requires lots of space on the runtime stack space due to deep
|
||
recursion, among other things. :-)</p>
|
||
<p>See the “<strong>OBFUSCATION</strong>” section below for more notes about portability.</p>
|
||
<h3 id="about-the-code">ABOUT THE CODE</h3>
|
||
<p>Clearly, the author is very, very confused. Although he has broken up the file
|
||
into sections labelled with helpful headings, and although he has left ample
|
||
whitespace between all those <code>#define</code>s to make them easier to read, :-) and
|
||
although he has helpfully formatted the code with beautiful indentation,
|
||
something is clearly very, very wrong.</p>
|
||
<p>In fact, the closer you look at this code, the more you realize something is
|
||
horribly wrong with it. For example, why is it that the first statement in
|
||
<code>main()</code> is a <code>return</code>? What do all those nested <code>do</code> loops do (pun intended)? Why
|
||
is the first statement inside the first <code>do</code> loop a mere integer literal? Why
|
||
are there such strange statements, like that empty string on line 65, or that
|
||
isolated <code>||</code> on line 68?</p>
|
||
<p>But wait… why aren’t any statements terminated by semicolons? Why is there
|
||
only ONE semicolon in the entire program?! Why is the author opening nested
|
||
blocks by such strange things as <code>||</code> and <code>(</code>, and closing them by <code>||</code> and <code>)</code>? The
|
||
<code>for</code> loop isn’t a <code>for</code> loop! The <code>do</code> loop isn’t a <code>do</code> loop! Or… are they? Well,
|
||
the <code>for</code> loop is defined in terms of a <code>while</code> loop. But wait, the <code>while</code> loop is
|
||
defined in terms of the <code>do</code> loop. And the <code>do</code> loop is defined in terms of …
|
||
Huh???</p>
|
||
<p>And that <code>switch</code> statement toward the end of the program… wait a minute,
|
||
that’s not a <code>switch</code> statement! Why is a <code>case</code> defined in terms of a <code>switch</code>
|
||
statement?! And that initial return isn’t a return! Well, it is… but not what
|
||
you might think!</p>
|
||
<p>Let’s see if it all makes sense after we run it through CPP…</p>
|
||
<p>Uh oh. The result looks like the diseased imagination of a mind more confused
|
||
than the one who wrote the original code. Unfortunately, unless you’re a Lisp
|
||
expert, it is probably easier to understand the program in its original form.
|
||
(And even then.) But that’s just so, so wrong…</p>
|
||
<p>The entire program consists of a single expression, returned from <code>main()</code>.
|
||
There are no <code>if</code> statements, no <code>for</code> loops or any looping or control constructs
|
||
besides the <code>return</code>, in spite of the misleading appearance of the original
|
||
source. :) Yes I know, this has been attempted before, using <code>?:</code> and the bad
|
||
old comma operator. BUT this program does NOT use the <code>?:</code> operator, and there
|
||
are only TWO comma operators in the entire program–and they are only there
|
||
because <code>srand()</code> and <code>exit()</code> return void.</p>
|
||
<p>The entire program consists of a single boolean expression returned from
|
||
<code>main()</code>. Looping is achieved by recursion, of course, and branching is achieved
|
||
by exploiting short-circuit evaluation of boolean expressions. :-)</p>
|
||
<p>But this is not all.</p>
|
||
<p>It is comprehensible that the program can achieve branching and looping using
|
||
only boolean expressions and recursion. But HOW does the program STORE DATA???
|
||
There are no variables of any kind in the program except for the two arguments
|
||
to <code>main()</code>. There are certainly no arrays declared anywhere. The program does
|
||
not call any memory allocation routines, nor any function that indirectly
|
||
returns allocated memory. Yet it happily looks up array references without
|
||
crashing. How??</p>
|
||
<p>One might be tempted to think that this program would be highly non-portable
|
||
because of such insane hacks. However, it has been tested and proven to work
|
||
on the following architectures:</p>
|
||
<ul>
|
||
<li>i386/linux</li>
|
||
<li>sparc/solaris</li>
|
||
<li>parisc64/linux</li>
|
||
<li>arm/linux</li>
|
||
<li>s390/linux</li>
|
||
<li>mips/linux</li>
|
||
<li>m68k/linux</li>
|
||
<li>ia64/linux</li>
|
||
<li>sparc64/linux</li>
|
||
</ul>
|
||
<p>It probably will also compile and work on many (all?) other *nix platforms as
|
||
well. How does it achieve this incredible feat?</p>
|
||
<h3 id="notice-to-those-who-wish-for-a-greater-challenge">NOTICE to those who wish for a greater challenge:</h3>
|
||
<p><strong>If you want a greater challenge, don’t read any further</strong>:
|
||
just try to understand the program via the source.</p>
|
||
<p>If you get stuck, come back and read below for additional hints and information.</p>
|
||
<h3 id="obfuscation">OBFUSCATION</h3>
|
||
<p>Read the following only if you give up figuring it out :-)</p>
|
||
<h4 id="the-evil-hack">The Evil Hack</h4>
|
||
<p>The program (ab)uses an implicit assumption underlying practically all
|
||
architectures, and that is that parameters to C functions are implicit local
|
||
variables allocated on the runtime stack. This runtime stack is a contiguous
|
||
section of memory, and therefore, after <code>N</code> recursive calls of <code>main()</code> to
|
||
itself, there is enough room on the stack to store whatever the program desires,
|
||
so long as it does not exceed the maximum stack size.</p>
|
||
<p>(Theoretically, the runtime stack doesn’t <strong>have</strong> to be contiguous… but all
|
||
current architectures that are worth consideration make this assumption. I
|
||
submit that this implies this program is 100% portable, even though
|
||
theoretically it shouldn’t even work in the first place.) :-)</p>
|
||
<p>There are two types of architectures the program must handle: those that
|
||
allocate the stack top-down, and those that allocate the stack bottom-up. The
|
||
program correctly detects this at runtime, and adjusts itself accordingly.
|
||
:-) (It is a simple matter of testing if the address of <code>argc</code> in a recursive
|
||
call is greater or less than in the parent call.)</p>
|
||
<p>To avoid having to handle issues of <code>int</code> sizes, memory alignment, what exactly
|
||
is on the stack between successive locations of <code>argc</code>, etc., the program
|
||
(ab)uses the fact that <code>argc</code> must necessarily be allocated on an aligned
|
||
address, and therefore, the range of memory between two <code>argc</code>s is aligned, and
|
||
therefore safe to use as an array of <code>long</code>s.<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a> The program also compares the
|
||
pointers as <code>long*</code> pointers, so that it will not have to deal with mapping
|
||
bytes to larger types. The initial memory allocation is done by recursively
|
||
calling <code>main()</code> until there is enough space on the stack (the exact number of
|
||
recursive calls is, of course, architecture-dependent).</p>
|
||
<p>After the stack is deemed to have grown deep enough to be a sufficiently <code>long</code>
|
||
array (pun intended), the program begins its real code. It uses <code>argc</code> to keep
|
||
track of what it’s supposed to be doing (since <code>main()</code> is the only function),
|
||
and <code>argv</code> to point to the base of this array (which is computed differently
|
||
based on how the architecture allocates the stack). Since this fills up the
|
||
only two variables in the program, everything else is stored in the <code>MASS</code> <a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a>
|
||
array.</p>
|
||
<p>Note that from this point on, all bets are off as to what the contents of the
|
||
runtime stack are below the current recursive call to <code>main()</code>. We are
|
||
overwriting frame pointers, return addresses, etc., with data. Hence, the
|
||
program must never return from this call, otherwise it will crash horribly.
|
||
That’s why I had to call <code>exit()</code> even though it meant I can no longer claim the
|
||
program doesn’t need the comma operator. :-) (I was going to skirt around the
|
||
issue by indirectly calling <code>exit()</code>, such as via <code>bsearch()</code> or <code>raise()</code>, but I
|
||
was getting too close to the size limit.)</p>
|
||
<h4 id="some-notes-about-the-macros">Some notes about the macros</h4>
|
||
<p>In spite of the frightening appearance, it is probably easiest to understand
|
||
the code in its original form. (Don’t even try running <code>indent</code> on it: on my
|
||
system it chokes and complains about nesting errors.)</p>
|
||
<p>Most of the <code>#define</code>s are just to keep the code size down, due to the abusive
|
||
amounts of type casting employed. The others define a bizarre “programming
|
||
language” (in the crudest, most twisted sense of the word) that the author
|
||
used to write this mess.</p>
|
||
<p><code>R(i)</code> and <code>W(i,j)</code> are macros to read/write the <code>i</code>th position of the <code>MASS</code>.</p>
|
||
<p><code>A(i)</code> retrieves the <code>i</code>th command-line argument. This is slightly tricky,
|
||
because by the time the <code>MASS</code> is setup, we no longer have access to the
|
||
original values of <code>argc</code> and <code>argv</code>. So what is done is that the initial memory
|
||
allocation code will save <code>argc</code> and <code>argv</code> into positions 8 and 9 in the <code>MASS</code>
|
||
after the allocation. It does this by using <code>argv</code>, which at that time contains
|
||
a pointer to the top-level <code>argc</code>, to compute the location of the top-level
|
||
<code>argv</code>. This is done before the rest of the <code>MASS</code> is used, since otherwise they
|
||
may be overwritten.</p>
|
||
<p><code>do(x,y)</code> has nothing to do with <code>do</code> loops. :-) It defines a “state” in <code>main()</code>,
|
||
essentially, what to do when <code>main()</code> is called with <code>argc</code> containing a
|
||
particular value. (This is why the user must never run the program with more
|
||
than 3 arguments. :-) The state number is <code>x</code>, and <code>y</code> is the code. The program’s
|
||
boolean expression consists of a number of states <code>&&</code>d together. Within each
|
||
state, it is assumed that statements are separated by <code>||</code>. All statements are
|
||
assumed to evaluate to false. This makes it easy to write conditional
|
||
statements: <code>if (a) { b } ...</code> can simply be written <code>a && b || ...</code>. All
|
||
states created by <code>do(x,y)</code> are assumed to evaluate to false. There is only 1
|
||
state which can return true or false: state 5, a “manually-implemented” state
|
||
which determines whether the system uses top-down or bottom-up stack
|
||
allocation. It’s the only state that needs to return a value from the boolean
|
||
expression, since once the <code>MASS</code> is initialized any return value can simply be
|
||
stored in a well-known location in the <code>MASS</code>.</p>
|
||
<p><code>if(p,q,r,s)</code> is, in fact, an <code>if</code> statement. :-) It is equivalent to:</p>
|
||
<pre><code> if (p) { q; r } else {s}</code></pre>
|
||
<p>Why are <code>q</code> and <code>r</code> split up? Because it’s cleaner (in whatever twisted sense of
|
||
the word that can be applied to an IOCCC entry) to implement using boolean
|
||
expressions. Keep in mind that all statements are assumed to evaluate to
|
||
false. The proof that this macro in fact implements an <code>if-then-else</code> construct
|
||
is left as an exercise for the reader.</p>
|
||
<p><code>while(x,y,z)</code> is actually a <code>while</code> loop after all. :-) It implements the loop
|
||
using, of course, recursive calls to <code>main()</code>. However, this macro doesn’t
|
||
actually run a <code>while</code> loop; it implements the loop in the state numbered <code>x</code>. It
|
||
is used for defining a <code>while</code> loop, which can then be called from another state
|
||
using <code>f(x)</code>. (The reason we can’t directly implement a <code>while</code> loop inside
|
||
another state ought to be clear: we can’t recursively call <code>main()</code> to enter
|
||
into the middle of a state.)</p>
|
||
<p>However, it <em>is</em> possible to implement a <code>for</code> loop directly inside a state! The
|
||
<code>for(s,i,x,y,z,Z)</code> macro does exactly this. Well, actually, technically speaking
|
||
this macro can only be used as the last thing in a state, because it secretly
|
||
closes the current state and opens a new one behind the programmer’s back.
|
||
:-) Its intended usage is this: <code>s</code> is the state number for the loop body, and
|
||
<code>i</code> is the index variable (well, the index into the <code>MASS</code> of the index
|
||
variable); <code>x</code> and <code>y-1</code> define the starting and ending values of <code>i</code>, and <code>z</code>
|
||
is the loop body. <code>Z</code> is the post-loop code in the current state. For example:</p>
|
||
<pre><code> for(s,i, 0, 10,
|
||
some_code ,
|
||
other_code)</code></pre>
|
||
<p>is equivalent to:</p>
|
||
<pre><code> for (i=0; i&lt;10; i++) {
|
||
some_code;
|
||
}
|
||
other_code;</code></pre>
|
||
<p>Note the “wrong” indentation in the former: the author prefers to write it
|
||
that way, since the analogy to the usual <code>for</code> loop is clearer. This is why it’s
|
||
easier to understand the pre-CPP code, since after CPP, the macro reshuffles
|
||
<code>some_code</code> after <code>other_code</code> so that it can close the current state and define
|
||
the one containing the loop body. (Have I told you that the author of this
|
||
program is horribly, horribly, confused? :-) This confusion also shows up in
|
||
the superficial appearance of the program, which heavily suffers from wrong
|
||
indentation.)</p>
|
||
<p>In spite of all appearances, <code>switch()</code> really is just a shorthand macro for
|
||
reducing code size. The evil choice of macro name is just to instill more
|
||
confusion into the would-be decipherer of this entry. :-) After all, <code>case()</code>
|
||
really <em>is</em> the equivalent of a <code>case</code> statement, implemented using <code>&&</code>, and
|
||
conveniently encapsulating code common to the cases in the only <code>switch</code>
|
||
statement in the program, which is the code that decides what to do with a
|
||
key press. What could be more fun than to define such a case in terms of a
|
||
<code>switch</code>? :-)</p>
|
||
<p>Finally, for those who give up deciphering this horribly confused code, here
|
||
are the mappings of various locations of the <code>MASS</code> to their usage in the
|
||
program, and what the various state numbers are meant to do:</p>
|
||
<h4 id="mass-usage-map">MASS usage map</h4>
|
||
<ul>
|
||
<li><code>0</code>
|
||
<ul>
|
||
<li>Function return value</li>
|
||
</ul></li>
|
||
<li><code>1</code>
|
||
<ul>
|
||
<li>Function argument 1</li>
|
||
</ul></li>
|
||
<li><code>2</code>
|
||
<ul>
|
||
<li>Function argument 2</li>
|
||
</ul></li>
|
||
<li><code>3</code>
|
||
<ul>
|
||
<li>Function argument 3</li>
|
||
</ul></li>
|
||
<li><code>4</code>
|
||
<ul>
|
||
<li>Scratch register 1</li>
|
||
</ul></li>
|
||
<li><code>5</code>
|
||
<ul>
|
||
<li>Scratch register 2</li>
|
||
</ul></li>
|
||
<li><code>6</code>
|
||
<ul>
|
||
<li>Scratch register 3</li>
|
||
</ul></li>
|
||
<li><code>7</code>
|
||
<ul>
|
||
<li>Scratch register 4</li>
|
||
</ul></li>
|
||
<li><code>8</code>
|
||
<ul>
|
||
<li>Value of original argv :-)</li>
|
||
</ul></li>
|
||
<li><code>9</code>
|
||
<ul>
|
||
<li>Value of original argc :-)</li>
|
||
</ul></li>
|
||
<li><code>11</code>
|
||
<ul>
|
||
<li>Zero register (always set to 0)</li>
|
||
</ul></li>
|
||
<li><code>12</code>
|
||
<ul>
|
||
<li>Width of board</li>
|
||
</ul></li>
|
||
<li><code>13</code>
|
||
<ul>
|
||
<li>Length of board</li>
|
||
</ul></li>
|
||
<li><code>14</code>
|
||
<ul>
|
||
<li>Height of board</li>
|
||
</ul></li>
|
||
<li><code>15</code>
|
||
<ul>
|
||
<li>Current position of hole</li>
|
||
</ul></li>
|
||
<li><code>16</code>
|
||
<ul>
|
||
<li>Random seed for rand_r(3)</li>
|
||
</ul></li>
|
||
<li><code>18</code>
|
||
<ul>
|
||
<li>Scratch register used by state 18 :-)</li>
|
||
</ul></li>
|
||
<li><code>31</code>
|
||
<ul>
|
||
<li>Field width for printing tiles</li>
|
||
</ul></li>
|
||
<li><code>32</code>
|
||
<ul>
|
||
<li>Start of board data</li>
|
||
</ul></li>
|
||
</ul>
|
||
<p>(<strong>CAVEAT</strong>: not all of these mappings ended up in the final version of the
|
||
program, mainly due to size limitations which entailed the trimming off of a
|
||
lot of neat features in the game. It is left as an exercise for the reader to
|
||
figure out which of these are actually used.)</p>
|
||
<p>Note that <code>argv</code> and <code>argc</code> necessarily need to stay away from lower indices of
|
||
the <code>MASS</code>, because otherwise they may overwrite their original values when the
|
||
memory allocation code saves them. Index 8 is deemed “safe enough”. (It seems
|
||
to be on all tested architectures.)</p>
|
||
<h4 id="state-number-assignments">State number assignments</h4>
|
||
<ul>
|
||
<li><code>1</code>
|
||
<ul>
|
||
<li><code>showhelp</code></li>
|
||
</ul></li>
|
||
<li><code>2</code>
|
||
<ul>
|
||
<li><code>showhelp</code></li>
|
||
</ul></li>
|
||
<li><code>3</code>
|
||
<ul>
|
||
<li>is 2D: start init</li>
|
||
</ul></li>
|
||
<li><code>4</code>
|
||
<ul>
|
||
<li>is 3D: start init</li>
|
||
</ul></li>
|
||
<li><code>5</code>
|
||
<ul>
|
||
<li>find allocation type</li>
|
||
</ul></li>
|
||
<li><code>6</code>
|
||
<ul>
|
||
<li>MASS init, bottom-up</li>
|
||
</ul></li>
|
||
<li><code>7</code>
|
||
<ul>
|
||
<li>MASS init, top-down</li>
|
||
</ul></li>
|
||
<li><code>8</code>
|
||
<ul>
|
||
<li>main program</li>
|
||
</ul></li>
|
||
<li><code>9</code>
|
||
<ul>
|
||
<li><code>generate()</code> outer loop</li>
|
||
</ul></li>
|
||
<li><code>13</code>
|
||
<ul>
|
||
<li><code>render()</code></li>
|
||
</ul></li>
|
||
<li><code>14</code>
|
||
<ul>
|
||
<li><code>render()</code> loop</li>
|
||
</ul></li>
|
||
<li><code>15</code>
|
||
<ul>
|
||
<li><code>exit(0)</code></li>
|
||
</ul></li>
|
||
<li><code>16</code>
|
||
<ul>
|
||
<li>pick a tile that hasn’t occurred yet</li>
|
||
</ul></li>
|
||
<li><code>17</code>
|
||
<ul>
|
||
<li>inner loop of <code>16</code>.</li>
|
||
</ul></li>
|
||
<li><code>18</code>
|
||
<ul>
|
||
<li>main loop</li>
|
||
</ul></li>
|
||
<li><code>19</code>
|
||
<ul>
|
||
<li><code>checkwin()</code> loop</li>
|
||
</ul></li>
|
||
</ul>
|
||
<p>Note that some of the manually-implemented states (those not implemented by
|
||
<code>do()</code>) respond to multiple state numbers. Also note that states 1-4
|
||
conveniently correspond to what the program should do when 1-4 arguments are
|
||
given at the command-line. :-)</p>
|
||
<p>The original intention was to include a parity-checking routine in the game so
|
||
that it will always generate a solvable game. However, size limits
|
||
necessitated the removal of this code. And besides, the game is more addictive
|
||
when it’s sometimes unsolvable. Especially when it taunts the user with a
|
||
smiley. :-)</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: 2005/anon/README.md -->
|
||
<hr style="width:10%;text-align:left;margin-left:0">
|
||
<section id="footnotes" class="footnotes footnotes-end-of-document" role="doc-endnotes">
|
||
<h5>Footnotes</h5>
|
||
<ol>
|
||
<li id="fn1"><p><code>long</code> was chosen instead of <code>int</code>, in order to skirt around pointer-size
|
||
issues on architectures like ia64. It really can be made anything large enough
|
||
to hold both <code>int</code>s and pointers. <code>:-)</code><a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
|
||
<li id="fn2"><p>for “Memory Allocated by Stack Smashing” :-)<a href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
|
||
</ol>
|
||
</section>
|
||
|
||
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||
<!-- START: this line starts content for HTML phase 22 by: bin/output-index-inventory.sh via bin/md2html.sh -->
|
||
|
||
<!-- START: this line starts content generated by: bin/output-index-inventory.sh -->
|
||
|
||
<div id="inventory">
|
||
<h1 id="inventory-for-2005anon">Inventory for 2005/anon</h1>
|
||
</div>
|
||
<h2 id="primary-files">Primary files</h2>
|
||
<ul>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2005/anon/anon.c">anon.c</a> - entry source code</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2005/anon/Makefile">Makefile</a> - entry Makefile</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2005/anon/anon.alt.c">anon.alt.c</a> - alternate source code</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2005/anon/anon.orig.c">anon.orig.c</a> - original source code</li>
|
||
</ul>
|
||
<h2 id="secondary-files">Secondary files</h2>
|
||
<ul>
|
||
<li><a href="2005_anon.tar.bz2">2005_anon.tar.bz2</a> - download entry tarball</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2005/anon/README.md">README.md</a> - markdown source for this web page</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2005/anon/.entry.json">.entry.json</a> - entry summary and manifest in JSON</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2005/anon/.gitignore">.gitignore</a> - list of files that should not be committed under git</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2005/anon/.path">.path</a> - directory path from top level directory</li>
|
||
<li><a href="index.html">index.html</a> - this web page</li>
|
||
</ul>
|
||
<hr style="width:10%;text-align:left;margin-left:0">
|
||
<h4>
|
||
Jump to: <a href="#">top</a>
|
||
</h4>
|
||
|
||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||
|
||
<!-- END: this line ends content for HTML phase 22 by: bin/output-index-inventory.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.inventory.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%2Fwww.ioccc.org%2F2005%2Fanon%2Findex.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> <a href="#inventory">Jump to Inventory</a><br>
|
||
</p>
|
||
</div>
|
||
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/footer.inventory.html -->
|
||
<!-- START: this line starts content from: inc/bottom.default.html -->
|
||
|
||
</body>
|
||
</html>
|
||
|
||
<!-- END: this line ends content from: inc/bottom.default.html -->
|