In other words rather than have the link name in the form of:
1984 decot bugs
it is now:
1984/decot in bugs.html
so that it matches how the entry itself looks (as in how it's
identified) and to say where (what file) it is (in). The reason it says
'in bugs.html' rather than 'bugs' (saying that the entry has bugs) is
because not all are bugs and it's saying where to see it anyway. But
some are features, others are missing links or files or other things
like that and to keep the same form it now says 'in bugs.html'.
This was done with my sgit(1) tool like:
sgit -e 's,\([0-9][0-9][0-9][0-9]\) \([-a-z\.0-9]*\) bugs,\1/\2 in bugs.html,g' '*/*md'
The link to bugs.html itself has the path '../../bugs.html'. This is
important as it's meant to be rendered in the browser. At first this was
not remembered and I did something like:
sgit -e 's,\[\([0-9][0-9][0-9][0-9]\) \([-a-z\.0-9]*\) bugs\](../../bugs.html,\[\1/\2 in bugs.html\](%%REPO_URL%%/bugs.html,g' '*/*md'
but this was changed to the simpler one due to the problem described
above. It's worth putting this note here as a reminder, though, so I
have included it here.
859 lines
40 KiB
HTML
859 lines
40 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">
|
||
People who have won
|
||
</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 & (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 & 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 web site
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html#fix_author" class="sub-item-link">
|
||
Fixing 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="../../thanks-for-help.html" class="sub-item-link">
|
||
Thanks for the help
|
||
</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">
|
||
People who have won
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../location.html">
|
||
Location of authors
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../bugs.html">
|
||
Bugs & (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 & 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 web site
|
||
</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>2005/anon - Best 3D puzzle</h2>
|
||
</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">← aidan</a>
|
||
<a class="Left" href="../index.html">↑ 2005 ↑</a>
|
||
<a class="Left" href="../boutines/index.html">boutines →</a>
|
||
<a class="Right" href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/anon/anon.c">C code</a>
|
||
<a class="Right" href="https://github.com/ioccc-src/temp-test-ioccc/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%2Fioccc-src.github.io%2Ftemp-test-ioccc%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>NOTE: there is an alternate version for vi(m) like movements. See <a href="#alternate-code">alternate
|
||
version</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/temp-test-ioccc/blob/master/2005/anon/anon.c">anon.c</a> as <code>anon</code> to not use <code>stty(1)</code>.</p>
|
||
<h3 id="bugs-and-misfeatures">Bugs and (Mis)features:</h3>
|
||
<p>The current status of this entry is:</p>
|
||
<pre><code> STATUS: INABIAF - please **DO NOT** fix</code></pre>
|
||
<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-version">Alternate version:</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>
|
||
<pre><code> k | Move empty spot up
|
||
h | Move empty spot left
|
||
j | Move empty spot down
|
||
l | Move empty spot right
|
||
J | Move empty spot forwards
|
||
K | Move empty spot backwards</code></pre>
|
||
<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: 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.
|
||
:-)</strong></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>
|
||
<pre><code> i | Slide the tile above the current empty space downwards.
|
||
j | Slide the tile to the left of the current empty space to the right.
|
||
k | Slide the tile below the current empty space upwards.
|
||
l | Slide the tile to the right of the current empty space to the left.
|
||
o | Slide the tile behind the current empty space forwards.
|
||
n | Slide the tile in front of the current empty space backwards.</code></pre>
|
||
<p>To quit the game:</p>
|
||
<pre><code> q | Quit the game.</code></pre>
|
||
<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>
|
||
<pre><code> i | Move empty spot up
|
||
j | Move empty spot left
|
||
k | Move empty spot down
|
||
l | Move empty spot right
|
||
n | Move empty spot forwards
|
||
o | Move empty spot backwards</code></pre>
|
||
<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 spoilers 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="spoiler">SPOILER</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.[*] 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>[*] <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></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> [**]
|
||
array.</p>
|
||
<p>[**] for “Memory Allocated by Stack Smashing” :-)</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>
|
||
<pre><code> 0 | Function return value
|
||
1 | Function argument 1
|
||
2 | Function argument 2
|
||
3 | Function argument 3
|
||
4 | Scratch register 1
|
||
5 | Scratch register 2
|
||
6 | Scratch register 3
|
||
7 | Scratch register 4
|
||
8 | Value of original argv :-)
|
||
9 | Value of original argc :-)
|
||
11 | Zero register (always set to 0)
|
||
12 | Width of board
|
||
13 | Length of board
|
||
14 | Height of board
|
||
15 | Current position of hole
|
||
16 | Random seed for rand_r(3)
|
||
18 | Scratch register used by state 18 :-)
|
||
31 | field width for printing tiles
|
||
32 | Start of board data</code></pre>
|
||
<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>
|
||
<pre><code> 1 | showhelp
|
||
2 | showhelp
|
||
3 | is 2D: start init
|
||
4 | is 3D: start init
|
||
5 | find allocation type
|
||
6 | MASS init, bottom-up
|
||
7 | MASS init, top-down
|
||
8 | main program
|
||
9 | generate() outer loop
|
||
13 | render()
|
||
14 | render() loop
|
||
15 | exit(0)
|
||
16 | pick a tile that hasn't occurred yet
|
||
17 | inner loop of 16.
|
||
18 | main loop
|
||
19 | checkwin() loop</code></pre>
|
||
<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 -->
|
||
|
||
<!-- 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/temp-test-ioccc/blob/master/2005/anon/anon.c">anon.c</a> - entry source</li>
|
||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/anon/Makefile">Makefile</a> - entry Makefile</li>
|
||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/anon/anon.alt.c">anon.alt.c</a> - alternate code</li>
|
||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/anon/anon.orig.c">anon.orig.c</a> - original source</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/temp-test-ioccc/blob/master/2005/anon/README.md">README.md</a> - markdown source for this web page</li>
|
||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/anon/.entry.json">.entry.json</a> - entry summary and manifest in JSON</li>
|
||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/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/temp-test-ioccc/blob/master/2005/anon/.path">.path</a> - directory path from top 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.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"><h2>Copyright and CC BY-SA 4.0 License</h2></div>
|
||
<p>All IOCCC content including this file and web page are:</p>
|
||
<b> Copyright © 1984-2024 by Landon Curt Noll. <a href="https://creativecommons.org/faq/#what-does-some-rights-reserved-mean">Some Rights Reserved</a>.</b>
|
||
<p>This work is licensed by Landon Curt Noll under:</p>
|
||
<p><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
|
||
<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">
|
||
</a></b></p>
|
||
<p>The <b>CC BY-SA 4.0 LEGAL CODE</b> for this license is found under:</p>
|
||
<p> <b><a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.en">
|
||
https://creativecommons.org/licenses/by-sa/4.0/legalcode.en</a></b></p>
|
||
<p>You should <b>carefully review</b> all of the terms and conditions of the
|
||
<a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.en">actual license</a>
|
||
before using the licensed material.</p>
|
||
<p>You may wish to review the <b><a href="../../license.html">highlights of some of the key
|
||
features and terms</a></b> of the <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.en">actual license</a>.</p>
|
||
<h2>Coda</h2>
|
||
<p><a href="https://validator.w3.org/nu/?doc=https%3A%2F%2Fioccc-src.github.io%2Ftemp-test-ioccc%2F2005%2Fanon%2Findex.html">Nu HTML check this web page</a></p>
|
||
<p><a href="#top">Jump to top</a> <a href="#content">Jump to Content</a> <a href="#inventory">Jump to Inventory</a></p>
|
||
</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 -->
|