build index.html for all winners
Updated manifest as per recent file changes. Updated winner `.winner.json` to reflect the manifest changes. Added [bin/all_run.sh](bin/all_run.sh) tool to run a command over all winning entries. These tools had slight improvements in the help usage message: * bin/gen-author.sh VERSION="1.3.1 2024-01-16" * bin/gen-inventory.sh VERSION="1.0.1 2024-01-16" * bin/pandoc_wrapper.sh VERSION="1.3.1 2024-01-16" * bin/subst.default.sh VERSION="1.1.1 2024-01-16" * bin/subst.winner-index.sh VERSION="1.1.1 2024-01-16" The `bin/readme2index.sh` tool was improved so that if the `index.html` file exists and the tool forms the exact same content, then the file `index.html` file is NOT touched. * bin/readme2index.sh VERSION="1.1 2024-01-16" We used the following command to generate `index.html` files for all winning entries: ```sh bin/all_run.sh -v 3 bin/readme2index.sh ``` NOTE: We have not (yet) built HTML files above the winner directory level (e.g., no year level nor top level HTML), nor have be built non-index HTML files for winners. NOTE: By default we are running `pandoc(1)` with: ``` --fail-if-warnings=true ``` This means that any problems with markdown to HTML generates an error. This is done to be sure that the HTML conversion is clean. We had to fix the following `README.md` files: * `2000/rince/README.md` The reference [^2] was never used. We made a guess that [^2] applies to the same spot as [^1]. Perhaps there is a better spot where [^2] applies? NOTE: For every reference, there MUST be some place where that reference is used. * 2012/vik/README.md The string "$...$" is assumed to be a TeX encoded string. NOTE: Every "$..$" needs to be backslashed as in "\$..\$". * 2018/burton1/README.md The reference [2] was duplicated. We changed the second [2] to [3]. NOTE: Every reference needs to have a unique number. * 2020/carlini/README.md The string "$...$" is assumed to be a TeX encoded string. NOTE: Every "$..$" needs to be backslashed as in "\$..\$". We also found 2 errors in the `author/author_handle.json` file set: * author/Anonymous_2001.json The `author/Anonymous_2001.json` file was missing. * author/Jari_Arkko.json The winner ID for `1989_jar.1` had a typo.
This commit is contained in:
1 parent
893cd915b6
commit
c1466f5165
350 files changed
+95242
-4217
No files matched your search
+591
-13
@@ -1,4 +1,6 @@
|
||||
<!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 -->
|
||||
<!-- -->
|
||||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||||
@@ -6,27 +8,603 @@
|
||||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||||
<!-- -->
|
||||
<!-- file: 2005/anon/index.html created by: fake.gen_index.sh version: 1.0.5 2023-10-31 -->
|
||||
<html lang="en">
|
||||
<!-- END: this line ends content from: inc/top.default.html -->
|
||||
<!-- -->
|
||||
<!-- This file was formed by the tool: bin/readme2index.sh version: 1.1 2024-01-16 -->
|
||||
<!-- -->
|
||||
<!-- START: this line starts content from: inc/head.default.html -->
|
||||
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>2005 anon</title>
|
||||
<meta name="description" content="IOCCC year: 2005 IOCCC winner: anon winner index page">
|
||||
<meta name="keywords" content="IOCCC,2005,anon,winner index page">
|
||||
<link rel="stylesheet" href="/temp-test-ioccc/ioccc.css">
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
|
||||
<title>2005/anon</title>
|
||||
<meta name="description" content="2005 IOCCC winner anon">
|
||||
<meta name="keywords" content="IOCCC, 2005, IOCCC 2005, IOCCC winner, anon">
|
||||
</head>
|
||||
|
||||
<!-- END: this line ends content from: inc/head.default.html -->
|
||||
<!-- START: this line starts content from: inc/body.default.html -->
|
||||
|
||||
<body>
|
||||
|
||||
<h1>2005 anon</h1>
|
||||
<!-- END: this line ends content from: inc/body.default.html -->
|
||||
<!-- START: this line starts content from: inc/header.default.html -->
|
||||
|
||||
<p>XXX - fake content until readme2index is working - XXX</p>
|
||||
<div class="header">
|
||||
<img src="/temp-test-ioccc/png/ioccc.png" alt="IOCCC image by Matt Zucker" width=300 height=110>
|
||||
<h1>The International Obfuscated C Code Contest</h1>
|
||||
<h2>2005/anon</h2>
|
||||
</div>
|
||||
|
||||
<hr style="width:50%;text-align:left;margin-left:0">
|
||||
<!-- END: this line ends content from: inc/header.default.html -->
|
||||
<!-- START: this line starts content from: inc/topnav.mid.html -->
|
||||
|
||||
<!-- Start Nu Html Checker -->
|
||||
<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 https://ioccc-src.github.io/temp-test-ioccc/2005/anon/index.html</a></p>
|
||||
<!-- End Nu Html Checker -->
|
||||
<div class="topnav">
|
||||
<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="#inventory">Inventory</a>
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/topnav.mid.html -->
|
||||
<!-- START: this line starts content from: inc/begin-row.default.html -->
|
||||
|
||||
<div class="row">
|
||||
|
||||
<!-- END: this line ends content from: inc/begin-row.default.html -->
|
||||
<!-- START: this line starts content from: inc/begin-leftcolumn.default.html -->
|
||||
|
||||
<div class="leftcolumn">
|
||||
|
||||
<!-- END: this line ends content from: inc/begin-leftcolumn.default.html -->
|
||||
<!-- START: this line starts content from: inc/sidenav.default.html -->
|
||||
|
||||
<div class="sidenav">
|
||||
<a href="#content">Jump to contents</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="/temp-test-ioccc/index.html">IOCCC Home</a>
|
||||
<a href="/temp-test-ioccc/years.html">Winning Entries</a>
|
||||
<a href="/temp-test-ioccc/winners.html">People who have won</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="/temp-test-ioccc/news.html">IOCCC News</a>
|
||||
<a href="/temp-test-ioccc/faq.html#submit">How to enter the IOCCC</a>
|
||||
<a href="/temp-test-ioccc/faq.html">FAQ</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="/temp-test-ioccc/bugs.html">Bugs & (mis)features</a>
|
||||
<a href="/temp-test-ioccc/faq.html#fix_a_winner">Fixing IOCCC winners</a>
|
||||
<a href="/temp-test-ioccc/faq.html#fix_web_site">Fixing the web site</a>
|
||||
<a href="/temp-test-ioccc/faq.html#fix_author">Fixing winner info</a>
|
||||
<a href="/temp-test-ioccc/thanks-for-help.html">Thanks for the help</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="/temp-test-ioccc/judges.html">The IOCCC Judges</a>
|
||||
<a href="/temp-test-ioccc/contact.html">Contacting the IOCCC</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="#top">Jump to top</a>
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/sidenav.default.html -->
|
||||
<!-- START: this line starts content from: inc/end-leftcolumn.default.html -->
|
||||
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/end-leftcolumn.default.html -->
|
||||
<!-- START: this line starts content from: inc/begin-rightcolumn.default.html -->
|
||||
|
||||
<div class="rightcolumn">
|
||||
|
||||
<!-- END: this line ends content from: inc/begin-rightcolumn.default.html -->
|
||||
<!-- START: this line starts content from: inc/before-content.default.html -->
|
||||
|
||||
<a name="content"></a>
|
||||
|
||||
<!-- END: this line ends content from: inc/before-content.default.html -->
|
||||
<!-- START: this line starts content generated by: bin/gen-author.sh -->
|
||||
|
||||
<p><a name="author"><strong>Author:</strong></a> <br><br>Name: <a
|
||||
href="/temp-test-ioccc/winners.html#Anonymous_2005">Anonymous
|
||||
2005</a><br> Location: <a
|
||||
href="/temp-test-ioccc/location.html#null">unknown</a></p>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/gen-author.sh -->
|
||||
<h2 id="to-build">To build:</h2>
|
||||
<div class="sourceCode" id="cb1"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span></span></code></pre></div>
|
||||
<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>
|
||||
<div class="sourceCode" id="cb2"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> anon-no_stty</span></code></pre></div>
|
||||
<p>This will compile <a href="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.md#2005-anon">2005
|
||||
anon in bugs.md</a>.</p>
|
||||
<h2 id="to-use">To use:</h2>
|
||||
<div class="sourceCode" id="cb4"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./anon</span> x y <span class="pp">[</span><span class="ss">z</span><span class="pp">]</span></span></code></pre></div>
|
||||
<h2 id="try">Try:</h2>
|
||||
<div class="sourceCode" id="cb5"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb5-1"><a href="#cb5-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./anon</span> 4 4</span>
|
||||
<span id="cb5-2"><a href="#cb5-2" aria-hidden="true" tabindex="-1"></a><span class="ex">./anon</span> 3 3 3</span></code></pre></div>
|
||||
<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>This is supposed to happen. As is written in the <a
|
||||
href="http://catb.org/jargon/html/F/feature.html">The Jargon
|
||||
File</a>:</p>
|
||||
<pre><code>That's not a bug, that's a feature.</code></pre>
|
||||
<p>If you want to see this in action you can easily do this:</p>
|
||||
<div class="sourceCode" id="cb7"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb7-1"><a href="#cb7-1" aria-hidden="true" tabindex="-1"></a><span class="fu">yes</span> <span class="st">'please crash on me :-)'</span> <span class="kw">|</span> <span class="ex">./anon</span> 4 4</span></code></pre></div>
|
||||
<p>What happens if you specify a larger board? For instance:</p>
|
||||
<div class="sourceCode" id="cb8"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb8-1"><a href="#cb8-1" aria-hidden="true" tabindex="-1"></a><span class="fu">yes</span> <span class="st">'please crash on me :-)'</span> <span class="kw">|</span> <span class="ex">./anon</span> 10 10 10</span></code></pre></div>
|
||||
<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>
|
||||
<div class="sourceCode" id="cb9"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb9-1"><a href="#cb9-1" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> alt</span></code></pre></div>
|
||||
<p>To compile the version without <code>stty(1)</code>:</p>
|
||||
<div class="sourceCode" id="cb10"><pre
|
||||
class="sourceCode sh"><code class="sourceCode bash"><span id="cb10-1"><a href="#cb10-1" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> alt-no_stty</span></code></pre></div>
|
||||
<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>
|
||||
<div class="sourceCode" id="cb12"><pre
|
||||
class="sourceCode sh"><code class="sourceCode bash"><span id="cb12-1"><a href="#cb12-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./anon</span> 4 4</span></code></pre></div>
|
||||
<p>To play with a 3D board, do something like this:</p>
|
||||
<div class="sourceCode" id="cb13"><pre
|
||||
class="sourceCode sh"><code class="sourceCode bash"><span id="cb13-1"><a href="#cb13-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./anon</span> 3 3 3</span></code></pre></div>
|
||||
<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>
|
||||
<div class="sourceCode" id="cb17"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb17-1"><a href="#cb17-1" aria-hidden="true" tabindex="-1"></a><span class="cf">if</span> <span class="op">(</span>p<span class="op">)</span> <span class="op">{</span> q<span class="op">;</span> r <span class="op">}</span> <span class="cf">else</span> <span class="op">{</span>s<span class="op">}</span></span></code></pre></div>
|
||||
<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>
|
||||
<div class="sourceCode" id="cb18"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb18-1"><a href="#cb18-1" aria-hidden="true" tabindex="-1"></a><span class="cf">for</span><span class="op">(</span>s<span class="op">,</span>i<span class="op">,</span> <span class="dv">0</span><span class="op">,</span> <span class="dv">10</span><span class="op">,</span></span>
|
||||
<span id="cb18-2"><a href="#cb18-2" aria-hidden="true" tabindex="-1"></a>some_code <span class="op">,</span></span>
|
||||
<span id="cb18-3"><a href="#cb18-3" aria-hidden="true" tabindex="-1"></a>other_code<span class="op">)</span></span></code></pre></div>
|
||||
<p>is equivalent to:</p>
|
||||
<div class="sourceCode" id="cb19"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb19-1"><a href="#cb19-1" aria-hidden="true" tabindex="-1"></a><span class="cf">for</span> <span class="op">(</span>i<span class="op">=</span><span class="dv">0</span><span class="op">;</span> i<span class="op">&</span>lt<span class="op">;</span><span class="dv">10</span><span class="op">;</span> i<span class="op">++)</span> <span class="op">{</span></span>
|
||||
<span id="cb19-2"><a href="#cb19-2" aria-hidden="true" tabindex="-1"></a> some_code<span class="op">;</span></span>
|
||||
<span id="cb19-3"><a href="#cb19-3" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span>
|
||||
<span id="cb19-4"><a href="#cb19-4" aria-hidden="true" tabindex="-1"></a>other_code<span class="op">;</span></span></code></pre></div>
|
||||
<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>
|
||||
<h2 id="copyright-and-cc-by-sa-4.0-license">Copyright and CC BY-SA 4.0
|
||||
License:</h2>
|
||||
<p>This file is Copyright (c) 2023 by Landon Curt Noll. All Rights
|
||||
Reserved. You are free to share and adapt this file under the terms of
|
||||
this license:</p>
|
||||
<pre><code>Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)</code></pre>
|
||||
<p>For more information, see:
|
||||
https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
<!-- START: this line starts content generated by: bin/gen-inventory.sh -->
|
||||
|
||||
<h1 id="inventory-for-2005anon"><a name="inventory"></a>Inventory for
|
||||
2005/anon</h1>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - winner home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/anon/anon.c">anon.c</a>
|
||||
- winning source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/anon/Makefile">Makefile</a>
|
||||
- winner Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/anon/anon.alt.c">anon.alt.c</a>
|
||||
- alternative source</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>
|
||||
<li><a href="2005_anon.tar.bz2">2005_anon.tar.bz2</a> - download winning
|
||||
source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<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=".path">.path</a> - directory path from top directory</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/anon/.winner.json">.winner.json</a>
|
||||
- description of winner in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/anon/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/gen-inventory.sh -->
|
||||
<!-- START: this line starts content from: inc/after-content.default.html -->
|
||||
|
||||
<!-- END: this line ends content from: inc/after-content.default.html -->
|
||||
<!-- START: this line starts content from: inc/end-rightcolumn.default.html -->
|
||||
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/end-rightcolumn.default.html -->
|
||||
<!-- START: this line starts content from: inc/end-row.default.html -->
|
||||
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/end-row.default.html -->
|
||||
<!-- START: this line starts content from: inc/footer.default.html -->
|
||||
|
||||
<div class="footer">
|
||||
<hr>
|
||||
<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 -->
|
||||
Reference in new issue
Block a user