force use of pandoc version >= 3.1.12.2
The `bin/pandoc-wrapper.sh` tool will verify that the ssytem has a recent enough version of `pandoc(1)`. We explain why we insist on `pandoc(1)`. version >= 3.1.12.2 in comments where the $PANDOC_MIN_VERSION is set. Added `--wrap=preserve` as a default argument to `pandoc(1)`. While this change will impact every HTML file generated, we believe this will improve the ability of someone to look at the generated HTML and correlate with the original markdown. Changed `bin/pandoc-wrapper.sh` VERSION from "1.4.2 2024-03-17" to "1.4.3 2024-03-18". Performed `make www` to achieve all of the above and to generate HTML using the new `--wrap=preserve` `pandoc(1)` mode.
This commit is contained in:
Landon Curt Noll committed
1 parent
9eb7a54e9f
commit
b0b212acb1
402 files changed
+37061
-55132
No files matched your search
+144
-195
@@ -130,8 +130,8 @@
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Carl_Banks">Carl Banks</a><br>
|
||||
Location: <a href="../../location.html#US">US</a> - <em>United States of
|
||||
America</em> (<em>United States</em>) <br><br></li>
|
||||
Location: <a href="../../location.html#US">US</a> - <em>United States of America</em> (<em>United States</em>)
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -141,12 +141,11 @@ America</em> (<em>United States</em>) <br><br></li>
|
||||
|
||||
<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> all</span></code></pre></div>
|
||||
<p>If you do not have a page up or page down key you might wish to see
|
||||
the <a href="#alternate-code">Alternate code</a> section below. You may
|
||||
redefine all the keys and the time step with predefined macros, however,
|
||||
so one lacking page up / page down does not strictly need the alternate
|
||||
code; it jut gives those controls a default value. The author provided
|
||||
the following table:</p>
|
||||
<p>If you do not have a page up or page down key you might wish to see the
|
||||
<a href="#alternate-code">Alternate code</a> section below. You may redefine all the keys
|
||||
and the time step with predefined macros, however, so one lacking page up / page
|
||||
down does not strictly need the alternate code; it jut gives those controls a
|
||||
default value. The author provided the following table:</p>
|
||||
<pre><code>Control Description Default Key
|
||||
------- ------------------------- -----------
|
||||
IT Increase throttle XK_Page_Up
|
||||
@@ -156,124 +155,109 @@ the following table:</p>
|
||||
LT Move stick left XK_Left
|
||||
RT Move stick right XK_Right
|
||||
CS Center stick XK_Enter</code></pre>
|
||||
<p>There is another macro, <code>dt</code>, which is the time step. See
|
||||
some important points on this in the author’s comments in the <a
|
||||
href="#alternate-build-instructions">Alternate Build Instructions</a>
|
||||
section.</p>
|
||||
<p>There is another macro, <code>dt</code>, which is the time step. See some important points
|
||||
on this in the author’s comments in the <a href="#alternate-build-instructions">Alternate Build
|
||||
Instructions</a> section.</p>
|
||||
<p>If however you wish to change the above controls, see the header file
|
||||
<a href="keysym.h">keysym.h</a> for the definitions of other characters
|
||||
that you might wish to use. The name of the macro in the header file is
|
||||
what you need to set the macros to, depending on what controls you wish
|
||||
to redefine. For instance, to set the throttle up and down to
|
||||
<code>u</code> and <code>d</code>:</p>
|
||||
<a href="keysym.h">keysym.h</a> for the definitions of other characters that you might wish
|
||||
to use. The name of the macro in the header file is what you need to set the
|
||||
macros to, depending on what controls you wish to redefine. For instance, to set
|
||||
the throttle up and down to <code>u</code> and <code>d</code>:</p>
|
||||
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> clobber IT=XK_u DT=XK_d all</span></code></pre></div>
|
||||
<p>because in the header file you can see that <code>XK_u</code>
|
||||
corresponds to <code>u</code> and <code>XK_d</code> corresponds to
|
||||
<code>d</code>:</p>
|
||||
<p>because in the header file you can see that <code>XK_u</code> corresponds to <code>u</code> and <code>XK_d</code>
|
||||
corresponds to <code>d</code>:</p>
|
||||
<div class="sourceCode" id="cb4"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a><span class="pp">#define XK_d </span><span class="bn">0x0064</span><span class="pp"> </span><span class="co">/* U+0064 LATIN SMALL LETTER D */</span></span>
|
||||
<span id="cb4-2"><a href="#cb4-2" aria-hidden="true" tabindex="-1"></a><span class="pp">#define XK_u </span><span class="bn">0x0075</span><span class="pp"> </span><span class="co">/* U+0075 LATIN SMALL LETTER U */</span></span></code></pre></div>
|
||||
<p>Note that the <a href="keysym.h">keysym.h</a> file is not complete
|
||||
from X11; it’s just the more likely candidates (and some that are
|
||||
probably unlikely :-) ).</p>
|
||||
<p>The upper case letters would be <code>XK_U</code> and
|
||||
<code>XK_D</code> and you can search the header file for ‘LATIN CAPITAL
|
||||
D’, for example.</p>
|
||||
<p>For those who do not have a Page Up or Page Down key, see <a
|
||||
href="#alternate-code">alternate code</a> below. The difference from the
|
||||
alt build and the original entry is that the page up and page down keys
|
||||
are defined to a default but they are hard coded as doing otherwise
|
||||
would necessarily complicate the build instructions. Since you can use
|
||||
the original entry to redefine these this is not a problem and is purely
|
||||
a convenience .. if only for those who are okay with the preselected
|
||||
alternative keys.</p>
|
||||
<p>Note that the <a href="keysym.h">keysym.h</a> file is not complete from X11; it’s just the
|
||||
more likely candidates (and some that are probably unlikely :-) ).</p>
|
||||
<p>The upper case letters would be <code>XK_U</code> and <code>XK_D</code> and you can search the header
|
||||
file for ‘LATIN CAPITAL D’, for example.</p>
|
||||
<p>For those who do not have a Page Up or Page Down key, see <a href="#alternate-code">alternate
|
||||
code</a> below. The difference from the alt build and the original
|
||||
entry is that the page up and page down keys are defined to a default but they
|
||||
are hard coded as doing otherwise would necessarily complicate the build
|
||||
instructions. Since you can use the original entry to redefine these this is not
|
||||
a problem and is purely a convenience .. if only for those who are okay with the
|
||||
preselected alternative keys.</p>
|
||||
<h2 id="to-use">To use:</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="fu">cat</span> horizon.sc pittsburgh.sc <span class="kw">|</span> <span class="ex">./banks</span></span></code></pre></div>
|
||||
<p>See the author’s remarks in <a href="#scenery">scenery</a> for more
|
||||
details on the scenery files.</p>
|
||||
<p>See the author’s remarks in <a href="#scenery">scenery</a> for more details on the scenery
|
||||
files.</p>
|
||||
<h2 id="try">Try:</h2>
|
||||
<p>For a fun time after running the above command, hold down the up
|
||||
arrow and left arrow for about 10 seconds and see what happens. Or, if
|
||||
you wish to really use it in a non-silly way, see the author’s remarks
|
||||
for the real controls. Perhaps you can regain control?</p>
|
||||
<p>For a fun time after running the above command, hold down the up arrow and left
|
||||
arrow for about 10 seconds and see what happens. Or, if you wish to really use
|
||||
it in a non-silly way, see the author’s remarks for the real controls. Perhaps
|
||||
you can regain control?</p>
|
||||
<h2 id="alternate-code">Alternate code:</h2>
|
||||
<p>If you do not have access to a page up or page down key, for instance
|
||||
you’re using a Mac, you can use the alt code (though it actually uses
|
||||
the same code) that will redefine the keys to increase throttle and
|
||||
decrease throttle. This same method can be used with the original code
|
||||
but this sets up predefined keys in place of Page Up and Page Down.</p>
|
||||
<p>The keys were somewhat arbitrarily selected but it was decided to
|
||||
make them both on the left side of a QWERTY keyboard as one might have a
|
||||
harder time using the arrows at the same time as typing on the right
|
||||
side.</p>
|
||||
<p>If you do not have access to a page up or page down key, for instance you’re
|
||||
using a Mac, you can use the alt code (though it actually uses the same code)
|
||||
that will redefine the keys to increase throttle and decrease throttle. This
|
||||
same method can be used with the original code but this sets up predefined keys
|
||||
in place of Page Up and Page Down.</p>
|
||||
<p>The keys were somewhat arbitrarily selected but it was decided to make them both
|
||||
on the left side of a QWERTY keyboard as one might have a harder time using the
|
||||
arrows at the same time as typing on the right side.</p>
|
||||
<h3 id="alternate-build">Alternate build:</h3>
|
||||
<p>As the Makefile allows you to configure the keys to use you may
|
||||
redefine the keys but with the alt build you cannot, as described
|
||||
earlier, redefine the page up and page down replacement keys. The other
|
||||
controls you may redefine; this is just a convenience build. If you want
|
||||
to redefine the page up / page down keys you should use the original
|
||||
entry as described in the to build section above.</p>
|
||||
<p>In the alt build it is <code>f</code> (for page up) and
|
||||
<code>d</code> (for page down) as these are letters on the left side of
|
||||
the keyboard which is easier to use if one is using the right side for
|
||||
movement. These are hard coded, as noted.</p>
|
||||
<p>As the Makefile allows you to configure the keys to use you may redefine the
|
||||
keys but with the alt build you cannot, as described earlier, redefine the page
|
||||
up and page down replacement keys. The other controls you may redefine; this is
|
||||
just a convenience build. If you want to redefine the page up / page down keys
|
||||
you should use the original entry as described in the to build section above.</p>
|
||||
<p>In the alt build it is <code>f</code> (for page up) and <code>d</code> (for page down) as these are
|
||||
letters on the left side of the keyboard which is easier to use if one is using
|
||||
the right side for movement. These are hard coded, as noted.</p>
|
||||
<p>To use the default settings for the alternate build:</p>
|
||||
<div class="sourceCode" id="cb6"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> alt</span></code></pre></div>
|
||||
<p>You may change the other keys as described in the build instructions,
|
||||
above, but this alt code can be seen as an alternative for those who
|
||||
don’t have or don’t want to use page up and page down.</p>
|
||||
<p>You may change the other keys as described in the build instructions, above, but
|
||||
this alt code can be seen as an alternative for those who don’t have or don’t
|
||||
want to use page up and page down.</p>
|
||||
<h3 id="alternate-use">Alternate use:</h3>
|
||||
<p>Use <code>banks.alt</code> as you would <code>banks</code> but use
|
||||
the different keys as configured at compilation.</p>
|
||||
<p>Use <code>banks.alt</code> as you would <code>banks</code> but use the different keys as
|
||||
configured at compilation.</p>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>What can we say? It’s a flight sim done in 1536 bytes of real code.
|
||||
This one is a real marvel. When people say the size limits are too
|
||||
tight, well, we can just point them at this one. This program really
|
||||
pushes the envelope!</p>
|
||||
<p>The provided Makefile should work; you will need an X-ish system, and
|
||||
a <code>select(2)</code> system call. More on building in the author
|
||||
remarks.</p>
|
||||
<p>Carl Banks linked to (on his old website) an interesting article
|
||||
about this entry, a flight simulator in just 1536 bytes, which can be
|
||||
found at <a
|
||||
href="https://web.archive.org/web/20040201120708/http://www.idg.co.nz/magazine/pcworld/oct99/code.htm"
|
||||
class="uri">https://web.archive.org/web/20040201120708/http://www.idg.co.nz/magazine/pcworld/oct99/code.htm</a>.</p>
|
||||
a <code>select(2)</code> system call. More on building in the author remarks.</p>
|
||||
<p>Carl Banks linked to (on his old website) an interesting article about this
|
||||
entry, a flight simulator in just 1536 bytes, which can be found at
|
||||
<a href="https://web.archive.org/web/20040201120708/http://www.idg.co.nz/magazine/pcworld/oct99/code.htm" class="uri">https://web.archive.org/web/20040201120708/http://www.idg.co.nz/magazine/pcworld/oct99/code.htm</a>.</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<p>You have just stepped out of the real world and into the virtual. You
|
||||
are now sitting in the cockpit of a Piper Cherokee airplane, heading
|
||||
north, flying 1000 feet above ground level.</p>
|
||||
<p>Use the keyboard to fly the airplane. The arrow keys represent the
|
||||
control stick. Press the Up Arrow key to push the stick forward. Press
|
||||
the left arrow key to move the stick left, and so on. Press Enter to
|
||||
re-center the stick. Use Page Up and Page Down to increase and decrease
|
||||
the throttle, respectively. (The rudder is automatically coordinated
|
||||
with the turn rate, so rudder pedals are not represented.)</p>
|
||||
<p>You have just stepped out of the real world and into the
|
||||
virtual. You are now sitting in the cockpit of a Piper Cherokee
|
||||
airplane, heading north, flying 1000 feet above ground level.</p>
|
||||
<p>Use the keyboard to fly the airplane. The arrow keys represent
|
||||
the control stick. Press the Up Arrow key to push the stick
|
||||
forward. Press the left arrow key to move the stick left, and
|
||||
so on. Press Enter to re-center the stick. Use Page Up and Page
|
||||
Down to increase and decrease the throttle, respectively. (The
|
||||
rudder is automatically coordinated with the turn rate, so
|
||||
rudder pedals are not represented.)</p>
|
||||
<p>On your display, you will see on the bottom left corner three
|
||||
instruments. The first is the airspeed indicator; it tells you how fast
|
||||
you’re going in knots. The second is the heading indicator, or compass.
|
||||
0 is north, 90 is east, 180 is south, 270 is west. The third instrument
|
||||
is the altimeter, which measures your height above ground level in
|
||||
feet.</p>
|
||||
instruments. The first is the airspeed indicator; it tells you
|
||||
how fast you’re going in knots. The second is the heading
|
||||
indicator, or compass. 0 is north, 90 is east, 180 is south,
|
||||
270 is west. The third instrument is the altimeter, which
|
||||
measures your height above ground level in feet.</p>
|
||||
<h3 id="features">Features</h3>
|
||||
<ul>
|
||||
<li><p>Simulator models a <a
|
||||
href="https://en.wikipedia.org/wiki/Piper_PA-28_Cherokee">Piper
|
||||
Cherokee</a>, which is a light, single-engine propeller driven
|
||||
airplane.</p></li>
|
||||
<li><p>The airplane is modeled as a six degree-of-freedom rigid body,
|
||||
accurately reflecting its dynamics (for normal flight conditions, at
|
||||
least).</p></li>
|
||||
<li><p>Fly through a virtual 3D world, while sitting at your X
|
||||
console.</p></li>
|
||||
<li><p>Simulator models a <a href="https://en.wikipedia.org/wiki/Piper_PA-28_Cherokee">Piper
|
||||
Cherokee</a>, which is a light,
|
||||
single-engine propeller driven airplane.</p></li>
|
||||
<li><p>The airplane is modeled as a six degree-of-freedom rigid body, accurately
|
||||
reflecting its dynamics (for normal flight conditions, at least).</p></li>
|
||||
<li><p>Fly through a virtual 3D world, while sitting at your X console.</p></li>
|
||||
<li><p>Loadable scenery files.</p></li>
|
||||
<li><p>Head-up display contains three instruments: a true airspeed
|
||||
indicator, a heading indicator (compass), and an altimeter.</p></li>
|
||||
<li><p>Flight controls may be mapped to any keys at compile time by
|
||||
redefining the macros in the Makefile. Nice if your keyboard doesn’t
|
||||
have arrow keys. (Or if you still use vi. :-)</p></li>
|
||||
<li><p>Time step size can be set at compile time. This is useful to
|
||||
reduce flicker on network X connections. (But be careful: step sizes
|
||||
longer than about 0.03 seconds tend to have numerical stability
|
||||
problems.)</p></li>
|
||||
<li><p>Head-up display contains three instruments: a true airspeed indicator, a
|
||||
heading indicator (compass), and an altimeter.</p></li>
|
||||
<li><p>Flight controls may be mapped to any keys at compile time by redefining the
|
||||
macros in the Makefile. Nice if your keyboard doesn’t have arrow keys. (Or
|
||||
if you still use vi. :-)</p></li>
|
||||
<li><p>Time step size can be set at compile time. This is useful to reduce flicker
|
||||
on network X connections. (But be careful: step sizes longer than about 0.03
|
||||
seconds tend to have numerical stability problems.)</p></li>
|
||||
<li><p>Airplane never stalls!</p></li>
|
||||
<li><p>Airplane never runs out of fuel!</p></li>
|
||||
<li><p>Fly underground!</p></li>
|
||||
@@ -281,25 +265,25 @@ problems.)</p></li>
|
||||
</ul>
|
||||
<h3 id="scenery">Scenery</h3>
|
||||
<p>Each of the <code>*.sc</code> files is a scenery file. The simulator
|
||||
program reads in the scenery from standard input on startup. You may
|
||||
input more than one scenery file, as long as there are less than 1000
|
||||
total lines of input.</p>
|
||||
program reads in the scenery from standard input on startup.
|
||||
You may input more than one scenery file, as long as there are
|
||||
less than 1000 total lines of input.</p>
|
||||
<p>Here is a brief description of the scenery files:</p>
|
||||
<ul>
|
||||
<li><p><a href="horizon.sc">horizon.sc</a></p>
|
||||
<p>A horizon, nothing more. You will probably always want to input this
|
||||
piece of scenery.</p></li>
|
||||
<p>A horizon, nothing more. You will probably always want to input this piece
|
||||
of scenery.</p></li>
|
||||
<li><p><a href="mountains.sc">mountains.sc</a></p>
|
||||
<p>An alternate horizon; a little more mountainous.</p></li>
|
||||
<li><p><a href="%5Bpittsburgh.sc%5D">pittsburgh.sc</a></p>
|
||||
<p>Scenery of downtown Pittsburgh. The downtown area is initially
|
||||
located to your right.</p></li>
|
||||
<p>Scenery of downtown Pittsburgh. The downtown area is initially located
|
||||
to your right.</p></li>
|
||||
<li><p><a href="bb.sc">bb.sc</a></p>
|
||||
<p>Simple obstacle course. Try to fly over the buildings and under the
|
||||
bridges.</p></li>
|
||||
<li><p><a href="pyramids.sc">pyramids.sc</a></p>
|
||||
<p>Fly over the tombs of the ancient Pharaohs, in this (fictitious)
|
||||
Egyptian landscape.</p></li>
|
||||
<p>Fly over the tombs of the ancient Pharaohs, in this (fictitious) Egyptian
|
||||
landscape.</p></li>
|
||||
<li><p><a href="river.sc">river.sc</a></p>
|
||||
<p>Follow a flowing river from the sky.</p></li>
|
||||
</ul>
|
||||
@@ -310,24 +294,22 @@ Egyptian landscape.</p></li>
|
||||
<p>You can simulate flying through a cloud bank as well:</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="ex">./banks</span> <span class="op"><</span> /dev/null</span></code></pre></div>
|
||||
<p>You will usually want at least a horizon, though.</p>
|
||||
<p>The format of scenery files is simple, by the way. They’re just a
|
||||
list of 3D coordinates, and the simulator simply draws line segments
|
||||
from point to point as listed in the scenery file. <code>0 0 0</code> is
|
||||
used to end a series of consecutive line segments. Note that in the
|
||||
coordinate system used, <em>the third coordinate represents
|
||||
<strong>altitude</strong> in a negative sense: negative numbers are
|
||||
<p>The format of scenery files is simple, by the way. They’re just
|
||||
a list of 3D coordinates, and the simulator simply draws line
|
||||
segments from point to point as listed in the scenery file. <code>0 0 0</code> is used to end a series of consecutive line segments. Note
|
||||
that in the coordinate system used, <em>the third coordinate
|
||||
represents <strong>altitude</strong> in a negative sense: negative numbers are
|
||||
positive altitudes</em>.</p>
|
||||
<p>I’m sure you’ll be making your own scenery files very soon!!!</p>
|
||||
<h3 id="alternate-build-instructions">Alternate Build Instructions</h3>
|
||||
<p>Several options must be passed to the compiler to make the build
|
||||
work. The provided <a href="Makefile">Makefile</a> has the appropriate
|
||||
options set to default values. Use this section if you want to compile
|
||||
with different options.</p>
|
||||
<p>To map a key to a control, you must pass an option to the compiler in
|
||||
the format <code>-Dcontrol=key</code> or if you use the Makefile you can
|
||||
do <code>make control=key</code>.</p>
|
||||
<p>The possible controls you can map are described in the table
|
||||
below:</p>
|
||||
work. The provided <a href="Makefile">Makefile</a> has the appropriate options set
|
||||
to default values. Use this section if you want to compile with
|
||||
different options.</p>
|
||||
<p>To map a key to a control, you must pass an option to the
|
||||
compiler in the format <code>-Dcontrol=key</code> or if you use the Makefile you can do
|
||||
<code>make control=key</code>.</p>
|
||||
<p>The possible controls you can map are described in the table below:</p>
|
||||
<pre><code>Control Description Default Key
|
||||
------- ------------------------- -----------
|
||||
IT Increase throttle XK_Page_Up
|
||||
@@ -337,91 +319,58 @@ below:</p>
|
||||
LT Move stick left XK_Left
|
||||
RT Move stick right XK_Right
|
||||
CS Center stick XK_Enter</code></pre>
|
||||
<p>Values for the possible keys can be found in the X Windows header
|
||||
file <code><X11/keysym.h></code>. This file is most likely a
|
||||
cross-reference to another header,
|
||||
<code><X11/keysymdef.h></code>.</p>
|
||||
<p>For example, to map Center Stick to the space-bar, the compile option
|
||||
would be <code>-DCS=XK_space</code> or
|
||||
<code>make CS=XK_space</code>.</p>
|
||||
<p>To set the time step size, you must pass the following option to the
|
||||
compiler: <code>-Ddt=duration</code>, where <code>dt</code> is literal,
|
||||
and where <code>duration</code> is the time in seconds you want the time
|
||||
step to be. Alternatively, if you use the provided Makefile, you may
|
||||
just do <code>make dt=time</code>.</p>
|
||||
<p>Two things to keep in mind when selecting a time step. Time steps
|
||||
that are too large (more than about <code>0.03</code>) will cause
|
||||
numerical stability problems and should be avoided. Setting the time
|
||||
step to be smaller than your clock resolution will slow down the
|
||||
simulator, because the system pauses for more time than the simulator
|
||||
expects.</p>
|
||||
<p>Values for the possible keys can be found in the X Windows
|
||||
header file <code><X11/keysym.h></code>. This file is most likely a
|
||||
cross-reference to another header, <code><X11/keysymdef.h></code>.</p>
|
||||
<p>For example, to map Center Stick to the space-bar, the compile
|
||||
option would be <code>-DCS=XK_space</code> or <code>make CS=XK_space</code>.</p>
|
||||
<p>To set the time step size, you must pass the following option to
|
||||
the compiler: <code>-Ddt=duration</code>, where <code>dt</code> is literal, and where
|
||||
<code>duration</code> is the time in seconds you want the time step to be. Alternatively,
|
||||
if you use the provided Makefile, you may just do <code>make dt=time</code>.</p>
|
||||
<p>Two things to keep in mind when selecting a time step. Time
|
||||
steps that are too large (more than about <code>0.03</code>) will cause
|
||||
numerical stability problems and should be avoided. Setting the
|
||||
time step to be smaller than your clock resolution will slow
|
||||
down the simulator, because the system pauses for more time than
|
||||
the simulator expects.</p>
|
||||
<p>The best advice is to set time step size to your system timer
|
||||
resolution. Try a longer period if you’re getting too much flicker.</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>
|
||||
resolution. Try a longer period if you’re getting too much
|
||||
flicker.</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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998banks"><a name="inventory"></a>Inventory for
|
||||
1998/banks</h1>
|
||||
<h1 id="inventory-for-1998banks"><a name="inventory"></a>Inventory for 1998/banks</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/banks.c">banks.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/banks.orig.c">banks.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/keysym.h">keysym.h</a>
|
||||
- included header file</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/bb.sc">bb.sc</a>
|
||||
- scenery file</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/horizon.sc">horizon.sc</a>
|
||||
- scenery file</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/mountains.sc">mountains.sc</a>
|
||||
- scenery file</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/pittsburgh.sc">pittsburgh.sc</a>
|
||||
- scenery file</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/pyramids.sc">pyramids.sc</a>
|
||||
- scenery file</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/river.sc">river.sc</a>
|
||||
- scenery file</li>
|
||||
<li><a href="1998_banks.tar.bz2">1998_banks.tar.bz2</a> - download entry
|
||||
source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/banks.c">banks.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/banks.orig.c">banks.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/keysym.h">keysym.h</a> - included header file</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/bb.sc">bb.sc</a> - scenery file</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/horizon.sc">horizon.sc</a> - scenery file</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/mountains.sc">mountains.sc</a> - scenery file</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/pittsburgh.sc">pittsburgh.sc</a> - scenery file</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/pyramids.sc">pyramids.sc</a> - scenery file</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/river.sc">river.sc</a> - scenery file</li>
|
||||
<li><a href="1998_banks.tar.bz2">1998_banks.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/.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/1998/banks/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/.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/1998/banks/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/banks/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+48
-72
@@ -129,9 +129,9 @@
|
||||
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Bas_de_Bakker">Bas de
|
||||
Bakker</a><br> Location: <a href="../../location.html#NL">NL</a> -
|
||||
<em>Kingdom of the Netherlands</em> (<em>Netherlands</em>) <br><br></li>
|
||||
<li>Name: <a href="../../authors.html#Bas_de_Bakker">Bas de Bakker</a><br>
|
||||
Location: <a href="../../location.html#NL">NL</a> - <em>Kingdom of the Netherlands</em> (<em>Netherlands</em>)
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -144,96 +144,72 @@ Bakker</a><br> Location: <a href="../../location.html#NL">NL</a> -
|
||||
<h2 id="to-use">To use:</h2>
|
||||
<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="ex">./bas1.sh</span></span></code></pre></div>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>The output is supposed to be a 3D maze, but it is somewhat more than
|
||||
that. If you’ve seen any of the <a
|
||||
href="https://en.wikipedia.org/wiki/M._C._Escher">Maurits Escher’s</a>
|
||||
<a href="https://mcescher.com/gallery/">works</a>, you’ll know what
|
||||
we’re talking about.</p>
|
||||
<p>When trying to run the program with command line arguments, be
|
||||
generous.</p>
|
||||
<p>The output is supposed to be a 3D maze, but it is somewhat more
|
||||
than that. If you’ve seen any of the <a href="https://en.wikipedia.org/wiki/M._C._Escher">Maurits
|
||||
Escher’s</a>
|
||||
<a href="https://mcescher.com/gallery/">works</a>, you’ll know what we’re talking about.</p>
|
||||
<p>When trying to run the program with command line arguments, be generous.</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<h3 id="bemazing">BEMAZING</h3>
|
||||
<p>“You’re in a twisty little maze of beams, all different.”</p>
|
||||
<p><code>Bemazing</code> is “amazing” taken one step (letter) further.
|
||||
<code>Bemazing</code> creates a 3D maze of beams. Try to go from the
|
||||
entrance (the unfinished beam in one corner) to the exit (the unfinished
|
||||
beam in the opposite corner) or vice versa.</p>
|
||||
<p>For maximum portability, <code>Bemazing</code> is not tied to any
|
||||
window system, but creates postscript output. The picture it makes will
|
||||
fit on either A4 or letter size paper.</p>
|
||||
<p>In addition, because postscript is rather verbose,
|
||||
<code>Bemazing</code> creates the postscript in <code>gzip(1)</code>
|
||||
format, in order to save precious bits on your hard disk for the latest
|
||||
version of <a href="https://www.gnu.org/software/emacs/">GNU Emacs</a>
|
||||
(after all, you wouldn’t want to use an editor without a
|
||||
psychoanalyze-pinhead function, now would you). Again for maximum
|
||||
portability, <code>Bemazing</code> will take special care that the
|
||||
binary output will not contain any newline or return characters that may
|
||||
get weird treatment on systems that do not use the One True Line
|
||||
Separator.</p>
|
||||
<p><code>Bemazing</code> is “amazing” taken one step (letter) further. <code>Bemazing</code>
|
||||
creates a 3D maze of beams. Try to go from the entrance (the
|
||||
unfinished beam in one corner) to the exit (the unfinished beam in the
|
||||
opposite corner) or vice versa.</p>
|
||||
<p>For maximum portability, <code>Bemazing</code> is not tied to any window system, but
|
||||
creates postscript output. The picture it makes will fit on either A4 or letter
|
||||
size paper.</p>
|
||||
<p>In addition, because postscript is rather verbose, <code>Bemazing</code> creates
|
||||
the postscript in <code>gzip(1)</code> format, in order to save precious bits on your
|
||||
hard disk for the latest version of <a href="https://www.gnu.org/software/emacs/">GNU
|
||||
Emacs</a> (after all, you wouldn’t
|
||||
want to use an editor without a psychoanalyze-pinhead function, now
|
||||
would you). Again for maximum portability, <code>Bemazing</code> will take special
|
||||
care that the binary output will not contain any newline or return
|
||||
characters that may get weird treatment on systems that do not use the
|
||||
One True Line Separator.</p>
|
||||
<h3 id="notes">NOTES</h3>
|
||||
<p>Be sure to view the source with something that can display characters
|
||||
<code>\240-\377</code>. Use <code>LESSCHARSET=latin1</code>,
|
||||
<code>M-x</code> <code>standard-display-european</code> in GNU Emacs
|
||||
etc. The source does not use characters in the range
|
||||
<code>\200-\237</code> (we are not an unnamed word processor that tends
|
||||
to create HTML containing these control characters).</p>
|
||||
<code>\240-\377</code>. Use <code>LESSCHARSET=latin1</code>, <code>M-x</code> <code>standard-display-european</code> in
|
||||
GNU Emacs etc. The source does not use characters in the range
|
||||
<code>\200-\237</code> (we are not an unnamed word processor that tends to create
|
||||
HTML containing these control characters).</p>
|
||||
<p>Because this is not the obfuscated postscript contest, the postscript
|
||||
does not contain any <code>for</code>, <code>if</code> or other control
|
||||
structures. All the logic is in the C code. There are only a few
|
||||
straightforward <code>def</code>s, because otherwise the output would
|
||||
become much larger.</p>
|
||||
<p>Try running <code>Bemazing</code> with command line arguments and see
|
||||
what happens. (But note that the program only guarantees that there
|
||||
actually is a route from entrance to exit if you run it without command
|
||||
line arguments.)</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>
|
||||
does not contain any <code>for</code>, <code>if</code> or other control structures. All the
|
||||
logic is in the C code. There are only a few straightforward <code>def</code>s,
|
||||
because otherwise the output would become much larger.</p>
|
||||
<p>Try running <code>Bemazing</code> with command line arguments and see what
|
||||
happens. (But note that the program only guarantees that there
|
||||
actually is a route from entrance to exit if you run it without
|
||||
command line arguments.)</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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998bas1"><a name="inventory"></a>Inventory for
|
||||
1998/bas1</h1>
|
||||
<h1 id="inventory-for-1998bas1"><a name="inventory"></a>Inventory for 1998/bas1</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas1/bas1.c">bas1.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas1/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas1/bas1.orig.c">bas1.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas1/bas1.sh">bas1.sh</a>
|
||||
- how to run bas1</li>
|
||||
<li><a href="1998_bas1.tar.bz2">1998_bas1.tar.bz2</a> - download entry
|
||||
source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas1/bas1.c">bas1.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas1/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas1/bas1.orig.c">bas1.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas1/bas1.sh">bas1.sh</a> - how to run bas1</li>
|
||||
<li><a href="1998_bas1.tar.bz2">1998_bas1.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas1/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas1/.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/1998/bas1/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas1/.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/1998/bas1/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas1/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+28
-47
@@ -129,9 +129,9 @@
|
||||
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Bas_de_Bakker">Bas de
|
||||
Bakker</a><br> Location: <a href="../../location.html#NL">NL</a> -
|
||||
<em>Kingdom of the Netherlands</em> (<em>Netherlands</em>) <br><br></li>
|
||||
<li>Name: <a href="../../authors.html#Bas_de_Bakker">Bas de Bakker</a><br>
|
||||
Location: <a href="../../location.html#NL">NL</a> - <em>Kingdom of the Netherlands</em> (<em>Netherlands</em>)
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -152,73 +152,54 @@ Bakker</a><br> Location: <a href="../../location.html#NL">NL</a> -
|
||||
<span id="cb3-5"><a href="#cb3-5" aria-hidden="true" tabindex="-1"></a><span class="ex">./try.sh</span> try.sh <span class="st">"bas2.c"</span> bas2.orig.c</span></code></pre></div>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<h3 id="questions-to-ponder">Questions to ponder:</h3>
|
||||
<p>Can you determine the relationship between the input and the
|
||||
resulting numeric output?</p>
|
||||
<p>The program was not designed to process files with a certain octet
|
||||
value, what value is that?</p>
|
||||
<p>Can you determine the relationship between the input and the resulting numeric
|
||||
output?</p>
|
||||
<p>The program was not designed to process files with a certain octet value, what
|
||||
value is that?</p>
|
||||
<h3 id="hint-and-extra-credit">Hint and Extra Credit:</h3>
|
||||
<p>This entry points out a minor flaw in the IOCCC rules that has been
|
||||
around since 1992. It processes a certain octet value in a way that
|
||||
differs from a strict reading of one of the official IOCCC rules. What
|
||||
is the rule and what is the octet value?</p>
|
||||
<p>This entry points out a minor flaw in the IOCCC rules that has
|
||||
been around since 1992. It processes a certain octet value in
|
||||
a way that differs from a strict reading of one of the
|
||||
official IOCCC rules. What is the rule and what is the octet
|
||||
value?</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<p>The main obfuscation is the way characters are recognized, which is
|
||||
done by matching the bit patterns. Minor obfuscations are:</p>
|
||||
<ul>
|
||||
<li><p>Useless layout.</p></li>
|
||||
<li><p>Useless variable names.</p></li>
|
||||
<li><p>Recursive <code>main()</code> instead of 2 loops (over input
|
||||
characters and over bits in the character).</p></li>
|
||||
<li><p><code>?:</code> and <code>||</code> instead of if
|
||||
statements.</p></li>
|
||||
<li><p>Recursive <code>main()</code> instead of 2 loops (over input characters and over bits in
|
||||
the character).</p></li>
|
||||
<li><p><code>?:</code> and <code>||</code> instead of if statements.</p></li>
|
||||
</ul>
|
||||
<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>
|
||||
<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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998bas2"><a name="inventory"></a>Inventory for
|
||||
1998/bas2</h1>
|
||||
<h1 id="inventory-for-1998bas2"><a name="inventory"></a>Inventory for 1998/bas2</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas2/bas2.c">bas2.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas2/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas2/bas2.orig.c">bas2.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas2/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a href="1998_bas2.tar.bz2">1998_bas2.tar.bz2</a> - download entry
|
||||
source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas2/bas2.c">bas2.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas2/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas2/bas2.orig.c">bas2.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas2/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="1998_bas2.tar.bz2">1998_bas2.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas2/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas2/.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/1998/bas2/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas2/.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/1998/bas2/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/bas2/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+55
-88
@@ -130,8 +130,8 @@
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Alan_De_Smet">Alan De Smet</a><br>
|
||||
Location: <a href="../../location.html#US">US</a> - <em>United States of
|
||||
America</em> (<em>United States</em>) <br><br></li>
|
||||
Location: <a href="../../location.html#US">US</a> - <em>United States of America</em> (<em>United States</em>)
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -141,120 +141,87 @@ America</em> (<em>United States</em>) <br><br></li>
|
||||
|
||||
<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> chaos</span></code></pre></div>
|
||||
<p>NOTE: Some systems do not implement <code>halfdelay()</code> in their
|
||||
<code>libcurses</code>. You might try compiling with -lncurses if you
|
||||
have that library. Or you can build this entry without the
|
||||
<code>halfdelay()</code> call by:</p>
|
||||
<p>NOTE: Some systems do not implement <code>halfdelay()</code> in their <code>libcurses</code>.
|
||||
You might try compiling with -lncurses if you have that library.
|
||||
Or you can build this entry without the <code>halfdelay()</code> call by:</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> chaos_nohalf</span></code></pre></div>
|
||||
<h2 id="to-use">To use:</h2>
|
||||
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./chaos</span></span></code></pre></div>
|
||||
<h2 id="try">Try:</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">./try.sh</span></span></code></pre></div>
|
||||
<p>This script will run the program on each data file. To quit the
|
||||
program hit <code>q</code>. If not all files have been used it will go
|
||||
to the next one; otherwise the script will be finished. To end the
|
||||
script early send intr/ctrl-c.</p>
|
||||
<p>The script will give you instructions on how to use the program and
|
||||
things to try each time it is run, as a helpful reminder.</p>
|
||||
<p>This script will run the program on each data file. To quit the program hit <code>q</code>.
|
||||
If not all files have been used it will go to the next one; otherwise the script
|
||||
will be finished. To end the script early send intr/ctrl-c.</p>
|
||||
<p>The script will give you instructions on how to use the program and things to
|
||||
try each time it is run, as a helpful reminder.</p>
|
||||
<h2 id="judges-comments">Judge’s Comments:</h2>
|
||||
<p>This is the author’s first IOCCC entry. We thought the entry was a
|
||||
nice example of a compact collection of obfuscations.</p>
|
||||
<p>This is the author’s first IOCCC entry. We thought the entry was
|
||||
a nice example of a compact collection of obfuscations.</p>
|
||||
<p>Can you figure out why, in some cases, it wants to read itself?</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<h3 id="usage">Usage</h3>
|
||||
<p>The executable takes a single argument for the data file to use. If
|
||||
no argument is given, it will find a data file by itself, don’t worry
|
||||
about it…</p>
|
||||
<p>The executable takes a single argument for the data file to use.
|
||||
If no argument is given, it will find a data file by itself, don’t
|
||||
worry about it…</p>
|
||||
<h3 id="summary">Summary</h3>
|
||||
<p>This is a simple ncurses 3D object viewer. The keys <code>y</code>,
|
||||
<code>u</code>, <code>i</code>, <code>h</code>, <code>j</code>, and
|
||||
<code>k</code> rotate. <code>a</code> and <code>z</code> zoom in and
|
||||
out. <code>q</code> quits. Given about 3 seconds of no input, it will
|
||||
start rotating until interrupted by user input.</p>
|
||||
<p>This is a simple ncurses 3D object viewer. The keys <code>y</code>, <code>u</code>, <code>i</code>,
|
||||
<code>h</code>, <code>j</code>, and <code>k</code> rotate. <code>a</code> and <code>z</code> zoom in and out. <code>q</code> quits.
|
||||
Given about 3 seconds of no input, it will start rotating until
|
||||
interrupted by user input.</p>
|
||||
<h3 id="features-aka-bugs">Features (aka Bugs):</h3>
|
||||
<p>Memory <code>malloc(3)</code>ed is never freed. This shouldn’t be a
|
||||
big deal, since only one block is ever allocated, and the OS should
|
||||
recover it.</p>
|
||||
<p>Memory <code>malloc(3)</code>ed is never freed. This shouldn’t be a big deal,
|
||||
since only one block is ever allocated, and the OS should recover it.</p>
|
||||
<p>My local flavor of lint doesn’t seem to like the fact that I never
|
||||
<code>return</code> from <code>main()</code>. Feh, what does it know?
|
||||
Otherwise, ignoring lint’s over protectiveness (“Of course I’m not using
|
||||
all of the functions defined in <code>curses.h</code>!”), it’s lint
|
||||
clean.</p>
|
||||
<p>If the compiler happens to generate the byte sequence “AlWuzEre” in
|
||||
the executable by chance, the program may be unable to locate the
|
||||
embedded string. As a result, running the program without an external
|
||||
data file may act in undefined ways.</p>
|
||||
<p>If the compiler doesn’t store <code>char * P</code>’s data in a nice
|
||||
contiguous stream, it would be bad. As above, it would break running the
|
||||
<code>return</code> from <code>main()</code>. Feh, what does it know? Otherwise, ignoring
|
||||
lint’s over protectiveness (“Of course I’m not using all of the
|
||||
functions defined in <code>curses.h</code>!”), it’s lint clean.</p>
|
||||
<p>If the compiler happens to generate the byte sequence “AlWuzEre”
|
||||
in the executable by chance, the program may be unable to locate
|
||||
the embedded string. As a result, running the program without an
|
||||
external data file may act in undefined ways.</p>
|
||||
<p>If the compiler doesn’t store <code>char * P</code>’s data in a nice contiguous
|
||||
stream, it would be bad. As above, it would break running the
|
||||
program without an external data file.</p>
|
||||
<p>If the incoming data is corrupt, the results are undefined. (Although
|
||||
dumping core is a popular result.)</p>
|
||||
<p>When a point passes behind the camera, it is still plotted. The
|
||||
object will “bounce” off the camera, but the result (some points in
|
||||
front, some reflected from the rear) looks really odd. And it sometimes
|
||||
hangs. So just don’t fly through objects. You’ll be happier.</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>
|
||||
<p>If the incoming data is corrupt, the results are undefined.
|
||||
(Although dumping core is a popular result.)</p>
|
||||
<p>When a point passes behind the camera, it is still plotted.
|
||||
The object will “bounce” off the camera, but the result (some points
|
||||
in front, some reflected from the rear) looks really odd. And it
|
||||
sometimes hangs. So just don’t fly through objects. You’ll be
|
||||
happier.</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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998chaos"><a name="inventory"></a>Inventory for
|
||||
1998/chaos</h1>
|
||||
<h1 id="inventory-for-1998chaos"><a name="inventory"></a>Inventory for 1998/chaos</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/chaos.c">chaos.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/chaos.orig.c">chaos.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/cube.data">cube.data</a>
|
||||
- data file</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/desk.data">desk.data</a>
|
||||
- data file</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/ioccc.data">ioccc.data</a>
|
||||
- data file</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/pyramid.data">pyramid.data</a>
|
||||
- data file</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/xwing.data">xwing.data</a>
|
||||
- data file</li>
|
||||
<li><a href="1998_chaos.tar.bz2">1998_chaos.tar.bz2</a> - download entry
|
||||
source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/chaos.c">chaos.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/chaos.orig.c">chaos.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/cube.data">cube.data</a> - data file</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/desk.data">desk.data</a> - data file</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/ioccc.data">ioccc.data</a> - data file</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/pyramid.data">pyramid.data</a> - data file</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/xwing.data">xwing.data</a> - data file</li>
|
||||
<li><a href="1998_chaos.tar.bz2">1998_chaos.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/.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/1998/chaos/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/.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/1998/chaos/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/chaos/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+89
-117
@@ -129,9 +129,9 @@
|
||||
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Daniel_Fischer">Daniel
|
||||
Fischer</a><br> Location: <a href="../../location.html#ZZ">ZZ</a> -
|
||||
<em>Unknown location</em> <br><br></li>
|
||||
<li>Name: <a href="../../authors.html#Daniel_Fischer">Daniel Fischer</a><br>
|
||||
Location: <a href="../../location.html#ZZ">ZZ</a> - <em>Unknown location</em>
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -145,8 +145,8 @@ Fischer</a><br> Location: <a href="../../location.html#ZZ">ZZ</a> -
|
||||
<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="ex">./df</span></span></code></pre></div>
|
||||
<h2 id="try">Try:</h2>
|
||||
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./try.sh</span></span></code></pre></div>
|
||||
<p>This will run the program in a loop until you exit (<code>q</code>
|
||||
when prompted or ctrl-c/intr).</p>
|
||||
<p>This will run the program in a loop until you exit (<code>q</code> when prompted or
|
||||
ctrl-c/intr).</p>
|
||||
<p>Can you figure out a very simple pipeline to cheat?</p>
|
||||
<h2 id="judges-remarks">Judges’ remarks;</h2>
|
||||
<p>Everyone talks about how data hiding can produce clearer code; I am
|
||||
@@ -156,10 +156,10 @@ game has some data - but where? It’s unclear which of the contents of
|
||||
the program are used.</p>
|
||||
<p>Curiously, the program only works if its source is in the directory
|
||||
it’s run in. More curiously, the program would fail if the program’s
|
||||
name’s second letter wasn’t <code>r</code> (the source has been changed
|
||||
for your convenience and this restriction no longer exist).</p>
|
||||
<p>Modern design has come a long way since the unreadable,
|
||||
tightly-coupled systems we used to have.</p>
|
||||
name’s second letter wasn’t <code>r</code> (the source has been changed for your
|
||||
convenience and this restriction no longer exist).</p>
|
||||
<p>Modern design has come a long way since the unreadable, tightly-coupled
|
||||
systems we used to have.</p>
|
||||
<p>Extra credit questions:</p>
|
||||
<ul>
|
||||
<li>Where are the words stored?</li>
|
||||
@@ -169,68 +169,62 @@ tightly-coupled systems we used to have.</p>
|
||||
</ul>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<p>This program lets you guess English words. It displays an underscore
|
||||
for each letter in the word; guessing a letter that actually is in the
|
||||
word replaces the corresponding underscores with the letter itself. You
|
||||
can guess a letter simply by typing it in. If your C implementation
|
||||
requires it, you may have to hit Return before it is recognized. In this
|
||||
case, you can also type multiple guesses on the same line (completely
|
||||
solve it by entering <code>abcdefghijklmnopqrstuvwxyz</code>). Execution
|
||||
stops when all underscores have been replaced.</p>
|
||||
<p>The program offers a number of different words to guess,
|
||||
<code>time()</code> is used to pick one at random. All words are eight
|
||||
characters long.</p>
|
||||
<p>The source should compile with any ANSI C compiler (I used
|
||||
CodeWarrior w/ ANSI strict). Using non-ANSI compilers that implement the
|
||||
ANSI features it uses will not work (unless they defined
|
||||
<code>__STDC__ 1</code> which they shouldn’t). Due to space
|
||||
restrictions, I did not use any trigraph sequences. It does not require
|
||||
any special <code>-D</code> defines.</p>
|
||||
for each letter in the word; guessing a letter that actually is in
|
||||
the word replaces the corresponding underscores with the letter
|
||||
itself. You can guess a letter simply by typing it in. If your C
|
||||
implementation requires it, you may have to hit Return before it
|
||||
is recognized. In this case, you can also type multiple guesses
|
||||
on the same line (completely solve it by entering
|
||||
<code>abcdefghijklmnopqrstuvwxyz</code>). Execution stops when all underscores
|
||||
have been replaced.</p>
|
||||
<p>The program offers a number of different words to guess, <code>time()</code> is
|
||||
used to pick one at random. All words are eight characters long.</p>
|
||||
<p>The source should compile with any ANSI C compiler (I used CodeWarrior
|
||||
w/ ANSI strict). Using non-ANSI compilers that implement the ANSI
|
||||
features it uses will not work (unless they defined <code>__STDC__ 1</code>
|
||||
which they shouldn’t). Due to space restrictions, I did not use
|
||||
any trigraph sequences. It does not require any special <code>-D</code> defines.</p>
|
||||
<p>The source passes lint without any complaint (if invoked with
|
||||
<code>>/dev/null</code>). (My lclint is unable to recover from some
|
||||
parts of it.)</p>
|
||||
<p>Actually, the code not only is compliant with the ANSI
|
||||
specifications, but uses a near minimum subset of them. C keywords that
|
||||
were not used have been re(de)fined to avoid unnecessary introduction of
|
||||
new, unknown character patterns. The source also includes all ANSI
|
||||
headers it needs (after most of the functions have been used), and the
|
||||
declaration of <code>main()</code> follows the guidelines (but the
|
||||
return type has a different meaning and the arguments are either misused
|
||||
or unused). There also may be some compiler warnings. These are not
|
||||
bugs, but features. The more warnings, the better the compiler. There
|
||||
wouldn’t be any if I had been allowed to use some extra space for
|
||||
prototypes etc.</p>
|
||||
<p>Multiple defines are used (but not all of them define), and
|
||||
<code>#define y define</code> is used with <code>#y</code> but the code
|
||||
doesn’t assume <code>#y</code> to expand to <code>#define</code>. I have
|
||||
also included comments in the code, and vital code in the comments. And
|
||||
of course there is code that doesn’t do anything but will crash the
|
||||
program if it is removed (just like those comments I mentioned above).
|
||||
Additionally, since you said you’d be preprocessing entries ignoring
|
||||
<code>#include</code>s I figured I should use some more of them instead
|
||||
of other obfuscation methods. Did I mention that preprocessed or
|
||||
beautified sources will crash or hang your system? The program will also
|
||||
crash on non-ASCII machines.</p>
|
||||
<code>>/dev/null</code>). (My lclint is unable to recover from some parts of it.)</p>
|
||||
<p>Actually, the code not only is compliant with the ANSI specifications, but uses
|
||||
a near minimum subset of them. C keywords that were not used have been
|
||||
re(de)fined to avoid unnecessary introduction of new, unknown character
|
||||
patterns. The source also includes all ANSI headers it needs (after most of the
|
||||
functions have been used), and the declaration of <code>main()</code> follows the
|
||||
guidelines (but the return type has a different meaning and the arguments are
|
||||
either misused or unused). There also may be some compiler warnings. These are
|
||||
not bugs, but features. The more warnings, the better the compiler. There
|
||||
wouldn’t be any if I had been allowed to use some extra space for prototypes
|
||||
etc.</p>
|
||||
<p>Multiple defines are used (but not all of them define), and <code>#define y define</code> is used with <code>#y</code> but the code doesn’t assume <code>#y</code> to expand
|
||||
to <code>#define</code>. I have also included comments in the code, and vital
|
||||
code in the comments. And of course there is code that doesn’t do
|
||||
anything but will crash the program if it is removed (just like
|
||||
those comments I mentioned above). Additionally, since you said
|
||||
you’d be preprocessing entries ignoring <code>#include</code>s I figured I should
|
||||
use some more of them instead of other obfuscation methods. Did
|
||||
I mention that preprocessed or beautified sources will crash or
|
||||
hang your system? The program will also crash on non-ASCII machines.</p>
|
||||
<p>The executable needs its source file present in the current directory
|
||||
or, depending on your system, in your path. The name of the source file
|
||||
is not hard-coded, <code>__FILE__</code> is used instead.</p>
|
||||
or, depending on your system, in your path. The name of the source
|
||||
file is not hard-coded, <code>__FILE__</code> is used instead.</p>
|
||||
<p>In the original version which was sent in to the contest, there were
|
||||
some restrictions on the file name:</p>
|
||||
<ul>
|
||||
<li>The second letter had to be a lowercase <code>r</code>.</li>
|
||||
<li>The third letter could never be a <code>+</code> or a
|
||||
<code>b</code>.</li>
|
||||
<li>The third letter could never be a <code>+</code> or a <code>b</code>.</li>
|
||||
</ul>
|
||||
<p>Valid names would have been <code>pr4.c</code>, <code>pr.c</code>,
|
||||
<code>prog.c</code>, <code>brownie.c</code> etc. My first private
|
||||
version would only run when compiled on a Friday. I decided it would be
|
||||
better this way… These restrictions have been removed for your
|
||||
convenience.</p>
|
||||
<p>Valid names would have been <code>pr4.c</code>, <code>pr.c</code>, <code>prog.c</code>, <code>brownie.c</code> etc.
|
||||
My first private version would only run when compiled on a Friday.
|
||||
I decided it would be better this way…
|
||||
These restrictions have been removed for your convenience.</p>
|
||||
<p>The following lines describe how this program works; if you don’t
|
||||
want to know it at this time, please skip them. If this entry would by
|
||||
some mistake win the contest, please do not rot13 this - I hate rot13
|
||||
spoilers since it is somewhat complicated on a Mac to reverse them.
|
||||
Anyone out there should have enough discipline and rot13 shouldn’t be
|
||||
required, really. After all, we are not children anymore :-)</p>
|
||||
want to know it at this time, please skip them. If this entry would
|
||||
by some mistake win the contest, please do not rot13 this - I hate
|
||||
rot13 spoilers since it is somewhat complicated on a Mac to
|
||||
reverse them. Anyone out there should have enough discipline and
|
||||
rot13 shouldn’t be required, really. After all, we are not children
|
||||
anymore :-)</p>
|
||||
<hr />
|
||||
<p>This paragraph is not part of the author’s remarks, but is a helpful
|
||||
gift from the judges; if you read too fast to stop yourself, this should
|
||||
@@ -239,79 +233,57 @@ you don’t want to read the spoilers, which really do spoil everything,
|
||||
we mean it.</p>
|
||||
<hr />
|
||||
<p>The source file needs to be present because the words are read from
|
||||
it. The wordlist is encoded within the source using a 24 entry sliding
|
||||
dictionary where lowercase letters are offsets into the dictionary,
|
||||
uppercase letters are new letters not yet in the dictionary, and all
|
||||
other characters are ignored. The words are spread over six lines in the
|
||||
source; decoding starts on a line after a tab and a whitespace have been
|
||||
found, and stops on a newline. The grin after the “Demonic Smiley”
|
||||
actually is one encoded letter while the string is completely ignored;
|
||||
and the <code>cut</code> in “cut here” is required while
|
||||
<code>here</code> is not.</p>
|
||||
it. The wordlist is encoded within the source using a 24 entry
|
||||
sliding dictionary where lowercase letters are offsets into the
|
||||
dictionary, uppercase letters are new letters not yet in the
|
||||
dictionary, and all other characters are ignored. The words are
|
||||
spread over six lines in the source; decoding starts on a line
|
||||
after a tab and a whitespace have been found, and stops on a newline.
|
||||
The grin after the “Demonic Smiley” actually is one encoded letter
|
||||
while the string is completely ignored; and the <code>cut</code> in “cut here”
|
||||
is required while <code>here</code> is not.</p>
|
||||
<p>“For extra credit”, explain why the words are sorted alphabetically
|
||||
(because I extracted them from a dictionary :-) )</p>
|
||||
<p>The file name had to fulfill the restrictions mentioned above because
|
||||
<code>__FILE__+1</code> was used as a second parameter to
|
||||
<code>fopen()</code>. (It essentially was
|
||||
<code>fopen(__FILE__,__FILE__+1)</code> ). This was an extra joke that
|
||||
doesn’t exist in the released version.</p>
|
||||
<p>You probably discovered that the <code>while(FILE)</code> in
|
||||
<code>main()</code> is not a while loop but the statement that opens the
|
||||
file and initializes the dictionary. Similarly, <code>int</code> and
|
||||
<code>signed</code> have been redefined (to save space, of course).</p>
|
||||
<p>The main function (the guessing part) is between the last
|
||||
<code>#else..#endif</code>, but still is declared before
|
||||
<code>main()</code>. The <code>5[O]()</code> in <code>main()</code>
|
||||
calls this function. Similarly, most indexing operations have been
|
||||
<p>The file name had to fulfill the restrictions mentioned above
|
||||
because <code>__FILE__+1</code> was used as a second parameter to <code>fopen()</code>. (It
|
||||
essentially was <code>fopen(__FILE__,__FILE__+1)</code> ). This was an extra joke
|
||||
that doesn’t exist in the released version.</p>
|
||||
<p>You probably discovered that the <code>while(FILE)</code> in <code>main()</code> is not a while loop
|
||||
but the statement that opens the file and initializes the dictionary.
|
||||
Similarly, <code>int</code> and <code>signed</code> have been redefined (to save space, of course).</p>
|
||||
<p>The main function (the guessing part) is between the last <code>#else..#endif</code>,
|
||||
but still is declared before <code>main()</code>. The <code>5[O]()</code> in <code>main()</code> calls
|
||||
this function. Similarly, most indexing operations have been
|
||||
changed to this form and I tried to write each such operation
|
||||
different.</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>
|
||||
<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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998df"><a name="inventory"></a>Inventory for
|
||||
1998/df</h1>
|
||||
<h1 id="inventory-for-1998df"><a name="inventory"></a>Inventory for 1998/df</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/df/df.c">df.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/df/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/df/df.orig.c">df.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/df/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a href="1998_df.tar.bz2">1998_df.tar.bz2</a> - download entry
|
||||
source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/df/df.c">df.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/df/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/df/df.orig.c">df.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/df/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="1998_df.tar.bz2">1998_df.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/df/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/df/.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/1998/df/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/df/.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/1998/df/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/df/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+58
-94
@@ -129,9 +129,9 @@
|
||||
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#J_David_Lowe">J. David
|
||||
Lowe</a><br> Location: <a href="../../location.html#US">US</a> -
|
||||
<em>United States of America</em> (<em>United States</em>) <br><br></li>
|
||||
<li>Name: <a href="../../authors.html#J_David_Lowe">J. David Lowe</a><br>
|
||||
Location: <a href="../../location.html#US">US</a> - <em>United States of America</em> (<em>United States</em>)
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -141,8 +141,8 @@ Lowe</a><br> Location: <a href="../../location.html#US">US</a> -
|
||||
|
||||
<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> all</span></code></pre></div>
|
||||
<p>There is an alternate version available. See <a
|
||||
href="#alternate-code">Alternate code</a> below for more details.</p>
|
||||
<p>There is an alternate version available. See <a href="#alternate-code">Alternate code</a>
|
||||
below for more details.</p>
|
||||
<h2 id="to-use">To use:</h2>
|
||||
<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="ex">./dlowe</span> <span class="op"><</span> file <span class="op">></span> pootfile</span>
|
||||
<span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a></span>
|
||||
@@ -150,8 +150,7 @@ href="#alternate-code">Alternate code</a> below for more details.</p>
|
||||
<h3 id="bugs-and-misfeatures">Bugs and (Mis)features:</h3>
|
||||
<p>The current status of this entry is:</p>
|
||||
<pre><code>STATUS: missing or dead link - please provide them</code></pre>
|
||||
<p>For more detailed information see <a
|
||||
href="../../bugs.html#1998_dlowe">1998 dlowe bugs</a>.</p>
|
||||
<p>For more detailed information see <a href="../../bugs.html#1998_dlowe">1998 dlowe bugs</a>.</p>
|
||||
<h2 id="try">Try:</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">./dlowe</span> <span class="op"><</span> README.md</span>
|
||||
<span id="cb4-2"><a href="#cb4-2" aria-hidden="true" tabindex="-1"></a><span class="ex">./dlowe</span> <span class="op"><</span> README.md <span class="op">></span> README.poot.md</span></code></pre></div>
|
||||
@@ -160,8 +159,8 @@ href="../../bugs.html#1998_dlowe">1998 dlowe bugs</a>.</p>
|
||||
<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">./try.sh</span></span></code></pre></div>
|
||||
<p>Did you spot the Easter egg there?</p>
|
||||
<h2 id="alternate-code">Alternate code:</h2>
|
||||
<p>The original entry was just a text based pootifier. This alternate
|
||||
version is that program.</p>
|
||||
<p>The original entry was just a text based pootifier. This alternate version is
|
||||
that program.</p>
|
||||
<h3 id="alternate-build">Alternate build:</h3>
|
||||
<div class="sourceCode" id="cb6"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> alt</span></code></pre></div>
|
||||
<h3 id="alternate-use">Alternate use:</h3>
|
||||
@@ -171,14 +170,12 @@ version is that program.</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="ex">./try.alt.sh</span></span></code></pre></div>
|
||||
<p>Did you spot the Easter egg there?</p>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>Why could this this entry be considered a utility? Well because it is
|
||||
able to convert content-free web pages into useful web pages.</p>
|
||||
<p>To see why, try using an online version, modified for use as a CGI
|
||||
program: <a
|
||||
href="https://web.archive.org/web/20001025182142/http://pootpoot.com/poot/pootify?URL=http://www.microsoft.com"
|
||||
class="uri">https://web.archive.org/web/20001025182142/http://pootpoot.com/poot/pootify?URL=http://www.microsoft.com</a></p>
|
||||
<p>We are sure that you will find that new web page to make a much more
|
||||
consistent level of quality. :-)</p>
|
||||
<p>Why could this this entry be considered a utility? Well because it
|
||||
is able to convert content-free web pages into useful web pages.</p>
|
||||
<p>To see why, try using an online version, modified for use as
|
||||
a CGI program: <a href="https://web.archive.org/web/20001025182142/http://pootpoot.com/poot/pootify?URL=http://www.microsoft.com" class="uri">https://web.archive.org/web/20001025182142/http://pootpoot.com/poot/pootify?URL=http://www.microsoft.com</a></p>
|
||||
<p>We are sure that you will find that new web page to make a much
|
||||
more consistent level of quality. :-)</p>
|
||||
<h3 id="historical-remarks">Historical remarks:</h3>
|
||||
<p>A CGI script such as:</p>
|
||||
<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="co">#!/bin/sh</span></span>
|
||||
@@ -202,102 +199,69 @@ consistent level of quality. :-)</p>
|
||||
<span id="cb9-19"><a href="#cb9-19" aria-hidden="true" tabindex="-1"></a> <span class="va">${LYNX}</span> <span class="at">-restrictions</span><span class="op">=</span>all <span class="at">-source</span> <span class="st">"</span><span class="va">${URL}</span><span class="st">"</span> <span class="kw">|</span> <span class="va">${POOT}</span></span>
|
||||
<span id="cb9-20"><a href="#cb9-20" aria-hidden="true" tabindex="-1"></a> <span class="cf">fi</span></span>
|
||||
<span id="cb9-21"><a href="#cb9-21" aria-hidden="true" tabindex="-1"></a><span class="cf">fi</span></span></code></pre></div>
|
||||
<p>can be used to pootify web pages. This has been added as <a
|
||||
href="pootify.cgi.sh">pootify.cgi.sh</a> which forbids
|
||||
<code>file://</code> based URLs and which uses <code>lynx(1)</code> with
|
||||
the option referred to above. This will not, of course, render it as
|
||||
html but rather show the modified html. Nevertheless, this has
|
||||
<strong>NOT</strong> been tested as a CGI script with a webserver to
|
||||
display a pootified web page.</p>
|
||||
<p>The <a href="pootify.sh">pootify.sh</a> script has also been added
|
||||
which is a modification to the above script which can be used to render
|
||||
html files locally with the added bonus that one can use
|
||||
<code>file://</code> URLs. If one wants a CGI script they should use the
|
||||
above one instead. You can use the script <a
|
||||
href="pootify.sh">pootify.sh</a>, however, to download and generate html
|
||||
files that you can look at locally in a browser or pipe through
|
||||
<code>less(1)</code>. For instance:</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="ex">./pootify.sh</span> URL=https://microsoft.com <span class="kw">|</span> <span class="fu">less</span></span>
|
||||
<p>can be used to pootify web pages. This has been added as
|
||||
<a href="pootify.cgi.sh">pootify.cgi.sh</a> which forbids <code>file://</code> based URLs and which
|
||||
uses <code>lynx(1)</code> with the option referred to above. This will not, of course,
|
||||
render it as html but rather show the modified html. Nevertheless, this has
|
||||
<strong>NOT</strong> been tested as a CGI script with a webserver to display a pootified web
|
||||
page.</p>
|
||||
<p>The <a href="pootify.sh">pootify.sh</a> script has also been added which is a modification
|
||||
to the above script which can be used to render html files locally with the
|
||||
added bonus that one can use <code>file://</code> URLs. If one wants a CGI script they
|
||||
should use the above one instead. You can use the script
|
||||
<a href="pootify.sh">pootify.sh</a>, however, to download and generate html files that you
|
||||
can look at locally in a browser or pipe through <code>less(1)</code>. For instance:</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="ex">./pootify.sh</span> URL=https://microsoft.com <span class="kw">|</span> <span class="fu">less</span></span>
|
||||
<span id="cb10-2"><a href="#cb10-2" aria-hidden="true" tabindex="-1"></a></span>
|
||||
<span id="cb10-3"><a href="#cb10-3" aria-hidden="true" tabindex="-1"></a><span class="ex">./pootify.sh</span> <span class="at">-r</span> URL=https://microsoft.com <span class="op">></span> ms.html</span></code></pre></div>
|
||||
<p>where the first one would show the text as rendered but without
|
||||
links, images etc. and the second one would write the html to
|
||||
<code>ms.html</code> so that you could open it in a browser.</p>
|
||||
<p>where the first one would show the text as rendered but without links, images
|
||||
etc. and the second one would write the html to <code>ms.html</code> so that you could open
|
||||
it in a browser.</p>
|
||||
<p>For an old example of it working as a CGI script see:</p>
|
||||
<div class="sourceCode" id="cb11"><pre
|
||||
class="sourceCode sh"><code class="sourceCode bash"><span id="cb11-1"><a href="#cb11-1" aria-hidden="true" tabindex="-1"></a><span class="ex">https://web.archive.org/web/20040326083431/http://www.pootpoot.com/poot/pootify/?URL=http%3A%2F%2Fwww.ioccc.org</span></span></code></pre></div>
|
||||
<div class="sourceCode" id="cb11"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb11-1"><a href="#cb11-1" aria-hidden="true" tabindex="-1"></a><span class="ex">https://web.archive.org/web/20040326083431/http://www.pootpoot.com/poot/pootify/?URL=http%3A%2F%2Fwww.ioccc.org</span></span></code></pre></div>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<p>This program is a text filter, it reads <code>stdin</code> and
|
||||
outputs the “corrected” text to <code>stdout</code>.</p>
|
||||
<p>It is obfuscated in that the code is painful to look at and its
|
||||
purpose and mode of operation are not terribly obvious. More
|
||||
importantly, it is a tool for further obfuscation, in that it can take
|
||||
any text and render it unintelligible.</p>
|
||||
<p>Suggested uses: add to your <code>MANROFFSEQ</code> environment
|
||||
variable for man page enjoyment; use it to turn the GPL into the
|
||||
<code>PPL</code>; see what happens when you run <code>perl4</code>
|
||||
programs after they’ve been run through it; “encrypt” sensitive (but
|
||||
unnecessary) documents…</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>
|
||||
<p>This program is a text filter, it reads <code>stdin</code> and outputs the
|
||||
“corrected” text to <code>stdout</code>.</p>
|
||||
<p>It is obfuscated in that the code is painful to look at and
|
||||
its purpose and mode of operation are not terribly obvious.
|
||||
More importantly, it is a tool for further obfuscation, in that it
|
||||
can take any text and render it unintelligible.</p>
|
||||
<p>Suggested uses: add to your <code>MANROFFSEQ</code> environment variable for man page
|
||||
enjoyment; use it to turn the GPL into the <code>PPL</code>; see what happens when you
|
||||
run <code>perl4</code> programs after they’ve been run through it; “encrypt” sensitive
|
||||
(but unnecessary) documents…</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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998dlowe"><a name="inventory"></a>Inventory for
|
||||
1998/dlowe</h1>
|
||||
<h1 id="inventory-for-1998dlowe"><a name="inventory"></a>Inventory for 1998/dlowe</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/dlowe.c">dlowe.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/dlowe.alt.c">dlowe.alt.c</a>
|
||||
- alternative source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/dlowe.orig.c">dlowe.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/pootify.cgi.sh">pootify.cgi.sh</a>
|
||||
- pootify CGI</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/pootify.sh">pootify.sh</a>
|
||||
- pootify tool</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/try.alt.sh">try.alt.sh</a>
|
||||
- how to run alternative code</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a href="1998_dlowe.tar.bz2">1998_dlowe.tar.bz2</a> - download entry
|
||||
source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/dlowe.c">dlowe.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/dlowe.alt.c">dlowe.alt.c</a> - alternative source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/dlowe.orig.c">dlowe.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/pootify.cgi.sh">pootify.cgi.sh</a> - pootify CGI</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/pootify.sh">pootify.sh</a> - pootify tool</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/try.alt.sh">try.alt.sh</a> - how to run alternative code</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="1998_dlowe.tar.bz2">1998_dlowe.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/.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/1998/dlowe/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/.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/1998/dlowe/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dlowe/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+76
-112
@@ -129,12 +129,12 @@
|
||||
|
||||
<h2 id="authors"><a name="author"></a>Authors:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#J_David_Lowe">J. David
|
||||
Lowe</a><br> Location: <a href="../../location.html#US">US</a> -
|
||||
<em>United States of America</em> (<em>United States</em>) <br><br></li>
|
||||
<li>Name: <a href="../../authors.html#J_David_Lowe">J. David Lowe</a><br>
|
||||
Location: <a href="../../location.html#US">US</a> - <em>United States of America</em> (<em>United States</em>)
|
||||
<br><br></li>
|
||||
<li>Name: <a href="../../authors.html#Neil_Mix">Neil Mix</a><br>
|
||||
Location: <a href="../../location.html#ZZ">ZZ</a> - <em>Unknown
|
||||
location</em> <br><br></li>
|
||||
Location: <a href="../../location.html#ZZ">ZZ</a> - <em>Unknown location</em>
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -144,37 +144,33 @@ location</em> <br><br></li>
|
||||
|
||||
<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> all</span></code></pre></div>
|
||||
<p>There is an alternate version available that has a key configuration
|
||||
that will be more familiar to vi(m) users and also allows one to quit.
|
||||
See <a href="#alternate-code">alternate code</a> below.</p>
|
||||
<p>There is an alternate version available that has a key configuration that will
|
||||
be more familiar to vi(m) users and also allows one to quit. See <a href="#alternate-code">alternate
|
||||
code</a> below.</p>
|
||||
<h3 id="bugs-and-misfeatures">Bugs and (Mis)features:</h3>
|
||||
<p>The current status of this entry is:</p>
|
||||
<pre><code>STATUS: missing or dead link - please provide them</code></pre>
|
||||
<p>For more detailed information see <a
|
||||
href="../../bugs.html#1998_dloweneil">1998 dloweneil bugs</a>.</p>
|
||||
<p>For more detailed information see <a href="../../bugs.html#1998_dloweneil">1998 dloweneil bugs</a>.</p>
|
||||
<h2 id="to-use">To use:</h2>
|
||||
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a></span>
|
||||
<span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a><span class="ex">./pootris</span> [X size of board] [Y size of board]</span></code></pre></div>
|
||||
<p>Pressing <code>a</code> moves the current letter position
|
||||
counterclockwise/anticlockwise (a)round the border of the playing
|
||||
field.</p>
|
||||
<p>Pressing <code>s</code> moves the current letter one position
|
||||
clockwise around the border of the playing field.</p>
|
||||
<p>Pressing <code>a</code> moves the current letter position counterclockwise/anticlockwise
|
||||
(a)round the border of the playing field.</p>
|
||||
<p>Pressing <code>s</code> moves the current letter one position clockwise around the border
|
||||
of the playing field.</p>
|
||||
<p>Pressing <code>d</code> drops the current letter onto the board.</p>
|
||||
<h2 id="alternate-code">Alternate code:</h2>
|
||||
<p>This version has it so that where in addition to <code>a</code>
|
||||
moving you counterclockwise/anticlockwise <code>h</code> does as well;
|
||||
and in addition to <code>s</code> moving clockwise <code>l</code> does
|
||||
as well. Instead of using <code>d</code> to drop the letter you can do
|
||||
<code>j</code> or space. Finally to quit this version you can press
|
||||
<code>q</code>.</p>
|
||||
<p>This version has it so that where in addition to <code>a</code> moving you
|
||||
counterclockwise/anticlockwise <code>h</code> does as well; and in addition to <code>s</code> moving
|
||||
clockwise <code>l</code> does as well. Instead of using <code>d</code> to drop the letter you can do
|
||||
<code>j</code> or space. Finally to quit this version you can press <code>q</code>.</p>
|
||||
<h3 id="alternate-build">Alternate build:</h3>
|
||||
<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="fu">make</span> alt</span></code></pre></div>
|
||||
<h3 id="alternate-use">Alternate use:</h3>
|
||||
<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">./pootris.alt</span> [X size of board] [Y size of board]</span></code></pre></div>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>Read the authors’ remarks below to find out how to play. We believe
|
||||
that your experience may mirror one of our experiences:</p>
|
||||
<p>Read the authors’ remarks below to find out how to play. We believe that your
|
||||
experience may mirror one of our experiences:</p>
|
||||
<pre><code>Originally, I didn't appreciate the game. Then I actually read the
|
||||
description of the controls. I started playing. I struggled.
|
||||
I spelled my first "poot". I was hooked ...</code></pre>
|
||||
@@ -182,82 +178,69 @@ I spelled my first "poot". I was hooked ...</code></pre>
|
||||
<h3 id="usage">Usage</h3>
|
||||
<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="ex">./pootris</span> [X size of board] [Y size of board]</span></code></pre></div>
|
||||
<h3 id="synopsis">Synopsis</h3>
|
||||
<p>The object of this game is to spell <code>POOT</code> as much as
|
||||
possible. There is no time pressure. You’re given one letter at a time
|
||||
(sort of randomly chosen from the set ‘P’, ‘O’, and ‘T’) and you get to
|
||||
move it freely around the border of the playing board, and decide when
|
||||
and where to drop it into the board. Sound easy? Of course, there’s a
|
||||
catch…</p>
|
||||
<p>The object of this game is to spell <code>POOT</code> as much as possible. There
|
||||
is no time pressure. You’re given one letter at a time (sort of randomly
|
||||
chosen from the set ‘P’, ‘O’, and ‘T’) and you get to move it freely
|
||||
around the border of the playing board, and decide when and where to drop
|
||||
it into the board. Sound easy? Of course, there’s a catch…</p>
|
||||
<h3 id="controls">Controls</h3>
|
||||
<p>Only three controls:</p>
|
||||
<p><code>a</code>: moves the current letter one position
|
||||
counterclockwise around the border of the playing field.</p>
|
||||
<p><code>s</code>: moves the current letter one position clockwise
|
||||
around the border of the playing field.</p>
|
||||
<p><code>a</code>: moves the current letter one position counterclockwise around
|
||||
the border of the playing field.</p>
|
||||
<p><code>s</code>: moves the current letter one position clockwise around the border
|
||||
of the playing field.</p>
|
||||
<p><code>d</code>: drops the current letter onto the board.</p>
|
||||
<p>To quit, send a fatal signal to the process.</p>
|
||||
<h3 id="rules-of-motion">Rules of motion</h3>
|
||||
<p>The different letters move in different directions once dropped onto
|
||||
the board:</p>
|
||||
<p><code>P</code> moves diagonally, at a 45 degree angle and in a
|
||||
clockwise direction around the board once dropped.</p>
|
||||
<p><code>O</code> moves in a straight line perpendicular to the border
|
||||
from which it is dropped.</p>
|
||||
<p><code>T</code> moves diagonally, at a 45 degree angle and in a
|
||||
counterclockwise direction around the board once dropped.</p>
|
||||
<p>The letters bounce off the top and sides of the board. They bounce in
|
||||
a ‘natural’ way, with the exception that <code>O</code>s will fall
|
||||
straight down if they hit a side wall.</p>
|
||||
<p>The letters stop when they hit another letter or the bottom of the
|
||||
board.</p>
|
||||
<p>The different letters move in different directions once dropped onto the board:</p>
|
||||
<p><code>P</code> moves diagonally, at a 45 degree angle and in a clockwise direction around
|
||||
the board once dropped.</p>
|
||||
<p><code>O</code> moves in a straight line perpendicular to the border from which it is
|
||||
dropped.</p>
|
||||
<p><code>T</code> moves diagonally, at a 45 degree angle and in a counterclockwise direction
|
||||
around the board once dropped.</p>
|
||||
<p>The letters bounce off the top and sides of the board. They bounce in a
|
||||
‘natural’ way, with the exception that <code>O</code>s will fall straight down if they hit
|
||||
a side wall.</p>
|
||||
<p>The letters stop when they hit another letter or the bottom of the board.</p>
|
||||
<h3 id="rules-of-spelling">Rules of spelling</h3>
|
||||
<ul>
|
||||
<li><p>When you spell <code>POOT</code> on the board, in any direction,
|
||||
the letters comprising the word will disappear, and any letters which
|
||||
may have accumulated above the disappeared letters will ‘fall’.</p></li>
|
||||
<li><p>Letters can be used in multiple spellings of
|
||||
<code>POOT</code>.</p></li>
|
||||
<li><p>When you spell <code>POOT</code> on the board, in any direction, the letters comprising
|
||||
the word will disappear, and any letters which may have accumulated above the
|
||||
disappeared letters will ‘fall’.</p></li>
|
||||
<li><p>Letters can be used in multiple spellings of <code>POOT</code>.</p></li>
|
||||
<li><p>Chain reactions are possible.</p></li>
|
||||
</ul>
|
||||
<h3 id="rules-of-scoring">Rules of scoring</h3>
|
||||
<ul>
|
||||
<li><p>You get one (1) point for each letter you drop onto the
|
||||
board.</p></li>
|
||||
<li><p>You get a bunch of points for spelling <code>POOT</code>. More if
|
||||
you spell it in more than one way simultaneously.</p></li>
|
||||
<li><p>You get one (1) point for each letter you drop onto the board.</p></li>
|
||||
<li><p>You get a bunch of points for spelling <code>POOT</code>. More if you spell it in more
|
||||
than one way simultaneously.</p></li>
|
||||
</ul>
|
||||
<h3 id="some-of-the-obfuscations">Some of the obfuscations</h3>
|
||||
<ul>
|
||||
<li><p>Several different coordinate systems are used. There’s the “real”
|
||||
X by Y system used for curses, the “inside the box” X by Y system used
|
||||
for moving things around and finding instances of <code>POOT</code>
|
||||
inside the box, and the position of the current letter, which is a
|
||||
single value from <code>0</code> to
|
||||
<li><p>Several different coordinate systems are used. There’s the “real” X by Y
|
||||
system used for curses, the “inside the box” X by Y system used for moving
|
||||
things around and finding instances of <code>POOT</code> inside the box, and the position
|
||||
of the current letter, which is a single value from <code>0</code> to
|
||||
<code>2 * xsize + 2 * ysize - 1</code>.</p></li>
|
||||
<li><p>The fact that <code>x%3</code> is a perfect hash function for
|
||||
<code>x</code> values <code>P</code>, <code>O</code> and <code>T</code>
|
||||
<li><p>The fact that <code>x%3</code> is a perfect hash function for <code>x</code> values <code>P</code>, <code>O</code> and <code>T</code>
|
||||
is used.</p></li>
|
||||
<li><p>Of course, the code is as hideous as possible, and spells
|
||||
<code>poot</code> for fun (It’s also exactly 3217 bytes in length, with
|
||||
exactly 1536 counted characters for purposes of this contest..</p></li>
|
||||
<li><p>Of course, the code is as hideous as possible, and spells <code>poot</code> for fun (It’s
|
||||
also exactly 3217 bytes in length, with exactly 1536 counted characters for
|
||||
purposes of this contest..</p></li>
|
||||
<li><p>Love that modulus operator! Mmmm…</p></li>
|
||||
<li><p>There are some equations used which are really unnecessarily
|
||||
ugly, which served the dual purposes of compacting the code and making
|
||||
it trickier to understand. I’m thinking of the equations used to convert
|
||||
between coordinate systems when dropping pieces into the game
|
||||
board.</p></li>
|
||||
<li><p>Simple and silly ones: short, meaningless (and sometimes
|
||||
misleading (see <code>x</code>)) variable names; hard-coded ASCII
|
||||
numeric values used for character constants; using <code>goto</code> for
|
||||
fun and profit; reusing and re-purposing variables in different
|
||||
<li><p>There are some equations used which are really unnecessarily ugly, which
|
||||
served the dual purposes of compacting the code and making it trickier to
|
||||
understand. I’m thinking of the equations used to convert between coordinate
|
||||
systems when dropping pieces into the game board.</p></li>
|
||||
<li><p>Simple and silly ones: short, meaningless (and sometimes misleading (see <code>x</code>))
|
||||
variable names; hard-coded ASCII numeric values used for character constants;
|
||||
using <code>goto</code> for fun and profit; reusing and re-purposing variables in different
|
||||
places.</p></li>
|
||||
<li><p>The game itself is simple, but still weird and quite
|
||||
difficult.</p></li>
|
||||
<li><p>The game itself is simple, but still weird and quite difficult.</p></li>
|
||||
</ul>
|
||||
<h3
|
||||
id="some-things-i-wish-i-could-have-fit-into-this-but-didnt-have-the-space">Some
|
||||
things I wish I could have fit into this, but didn’t have the
|
||||
space:</h3>
|
||||
<h3 id="some-things-i-wish-i-could-have-fit-into-this-but-didnt-have-the-space">Some things I wish I could have fit into this, but didn’t have the space:</h3>
|
||||
<ul>
|
||||
<li><p>Seeding the random number generator (doh!).</p></li>
|
||||
<li><p>Something to detect when the game is over.</p></li>
|
||||
@@ -266,53 +249,34 @@ space:</h3>
|
||||
<li><p>Some way of quitting gracefully.</p></li>
|
||||
</ul>
|
||||
<p>Good Luck!</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>
|
||||
<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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998dloweneil"><a name="inventory"></a>Inventory
|
||||
for 1998/dloweneil</h1>
|
||||
<h1 id="inventory-for-1998dloweneil"><a name="inventory"></a>Inventory for 1998/dloweneil</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dloweneil/dloweneil.c">dloweneil.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dloweneil/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dloweneil/dloweneil.alt.c">dloweneil.alt.c</a>
|
||||
- alternative source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dloweneil/dloweneil.orig.c">dloweneil.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a href="1998_dloweneil.tar.bz2">1998_dloweneil.tar.bz2</a> -
|
||||
download entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dloweneil/dloweneil.c">dloweneil.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dloweneil/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dloweneil/dloweneil.alt.c">dloweneil.alt.c</a> - alternative source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dloweneil/dloweneil.orig.c">dloweneil.orig.c</a> - original source</li>
|
||||
<li><a href="1998_dloweneil.tar.bz2">1998_dloweneil.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dloweneil/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dloweneil/.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/1998/dloweneil/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dloweneil/.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/1998/dloweneil/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dloweneil/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+78
-96
@@ -121,57 +121,52 @@
|
||||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
|
||||
<h1 id="information-about-this-entry">Information about this entry</h1>
|
||||
<p>Morse codes for letters and digits use sequences of 1 to 5
|
||||
(inclusive) Morse symbols (denoted as <code>.</code> or <code>-</code>),
|
||||
e.g.</p>
|
||||
<p>Morse codes for letters and digits use sequences of 1 to 5 (inclusive)
|
||||
Morse symbols (denoted as <code>.</code> or <code>-</code>), e.g.</p>
|
||||
<pre><code>E .
|
||||
Z --..
|
||||
3 ...--</code></pre>
|
||||
<p>(BTW: digits always have 5 symbols, letters 1 to 4. I didn’t use this
|
||||
fact.)</p>
|
||||
<p>Of course we can encode these symbols with bits in a byte. I chose
|
||||
<code>-</code> to be a bit set to 0, <code>.</code> to be a bit set to
|
||||
1. Characters in C are at least 8 bits, but they are either signed or
|
||||
unsigned. To be portable, I’ve used only values from 0 to 127
|
||||
(inclusive) (both in the encoding of Morse codes, as well as in
|
||||
subexpressions in the program). Hence we can use type <code>char</code>
|
||||
(using <code>unsigned char</code> for an extra bit would have made the
|
||||
source code excessively large ;-)</p>
|
||||
<p>The least significant bit contains the first symbol of a Morse code,
|
||||
so we have</p>
|
||||
<p>(BTW: digits always have 5 symbols, letters 1 to 4. I didn’t use this fact.)</p>
|
||||
<p>Of course we can encode these symbols with bits in a byte. I chose <code>-</code>
|
||||
to be a bit set to 0, <code>.</code> to be a bit set to 1. Characters in C are at
|
||||
least 8 bits, but they are either signed or unsigned. To be portable,
|
||||
I’ve used only values from 0 to 127 (inclusive) (both in the encoding
|
||||
of Morse codes, as well as in subexpressions in the program). Hence we
|
||||
can use type <code>char</code> (using <code>unsigned char</code> for an extra bit would have made
|
||||
the source code excessively large ;-)</p>
|
||||
<p>The least significant bit contains the first symbol of a Morse code, so
|
||||
we have</p>
|
||||
<pre><code>E > 0......1
|
||||
Z > 0...1100
|
||||
3 > 0..00111</code></pre>
|
||||
<p>The dots still have to be determined. But we also need to encode the
|
||||
length of the sequence. Since there are only 4 different kind of
|
||||
lengths, two bits would suffice, e.g.</p>
|
||||
length of the sequence. Since there are only 4 different kind of lengths,
|
||||
two bits would suffice, e.g.</p>
|
||||
<pre><code>E > 000....1
|
||||
Z > 010.1100
|
||||
3 > 01100111</code></pre>
|
||||
<p>That means bits 6 and 5 set to 00 is length 1, set to 01 is length 2,
|
||||
etc. But this would mean that we would have to extract the length into a
|
||||
<p>That means bits 6 and 5 set to 00 is length 1, set to 01 is length 2, etc.
|
||||
But this would mean that we would have to extract the length into a
|
||||
counter before shifting out each symbol, such as</p>
|
||||
<div class="sourceCode" id="cb4"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a>length <span class="op">=</span> <span class="op">(</span>encoding <span class="op">&</span> <span class="dv">96</span><span class="op">)</span> <span class="op">>></span> <span class="dv">5</span><span class="op">;</span></span>
|
||||
<span id="cb4-2"><a href="#cb4-2" aria-hidden="true" tabindex="-1"></a><span class="cf">do</span> <span class="op">{</span></span>
|
||||
<span id="cb4-3"><a href="#cb4-3" aria-hidden="true" tabindex="-1"></a> putchar<span class="op">(</span>encoding <span class="op">&</span> <span class="dv">1</span> <span class="op">?</span> <span class="ch">'-'</span> <span class="op">:</span> <span class="ch">'.'</span><span class="op">);</span></span>
|
||||
<span id="cb4-4"><a href="#cb4-4" aria-hidden="true" tabindex="-1"></a> encoding <span class="op">>>=</span> <span class="dv">1</span><span class="op">;</span></span>
|
||||
<span id="cb4-5"><a href="#cb4-5" aria-hidden="true" tabindex="-1"></a><span class="op">}</span> <span class="cf">while</span> <span class="op">(</span>length<span class="op">--);</span></span></code></pre></div>
|
||||
<p>We can also use the remaining bits to <em>include</em> the
|
||||
counter</p>
|
||||
<p>We can also use the remaining bits to <em>include</em> the counter</p>
|
||||
<pre><code>length 1: 00000.1x E > 00000.11
|
||||
length 2: 0000.1xx
|
||||
length 3: 000.1xxx
|
||||
length 4: 00.1xxxx Z > 00.11100
|
||||
length 5: 0.1xxxxx 3 > 0.100111</code></pre>
|
||||
<p>with 1 bit still to be chosen freely (let’s assume it is 0). Now we
|
||||
can do</p>
|
||||
<p>with 1 bit still to be chosen freely (let’s assume it is 0). Now we can do</p>
|
||||
<div class="sourceCode" id="cb6"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="cf">do</span> <span class="op">{</span></span>
|
||||
<span id="cb6-2"><a href="#cb6-2" aria-hidden="true" tabindex="-1"></a> putchar<span class="op">(</span>encoding <span class="op">&</span> <span class="dv">1</span> <span class="op">?</span> <span class="ch">'-'</span> <span class="op">:</span> <span class="ch">'.'</span><span class="op">);</span></span>
|
||||
<span id="cb6-3"><a href="#cb6-3" aria-hidden="true" tabindex="-1"></a> encoding <span class="op">>>=</span> <span class="dv">1</span><span class="op">;</span></span>
|
||||
<span id="cb6-4"><a href="#cb6-4" aria-hidden="true" tabindex="-1"></a><span class="cf">while</span> <span class="op">(</span>encoding <span class="op">></span> <span class="dv">1</span><span class="op">);</span></span></code></pre></div>
|
||||
<p>As you see, the encoded Morse sequence can be the counter itself. But
|
||||
this is not very pleasant, as some Morse sequences will end up having an
|
||||
ASCII value < 32, i.e. they will be control codes. This would make
|
||||
this is not very pleasant, as some Morse sequences will end up having
|
||||
an ASCII value < 32, i.e. they will be control codes. This would make
|
||||
the initializing (encoding) string awkward. Hence I came up with the
|
||||
following</p>
|
||||
<pre><code>length 1: 0010010x E > 00100101 (= '%')
|
||||
@@ -179,55 +174,47 @@ length 2: 001010xx
|
||||
length 3: 00110xxx
|
||||
length 4: 0100xxxx Z > 01001100 (= 'L')
|
||||
length 5: 011xxxxx 3 > 01100111 (= 'g')</code></pre>
|
||||
<p>Notice these encodings in the initialization string. Only the coding
|
||||
for <code>5</code> needs an escape
|
||||
(<code>5 = ..... > 01111111 = '\177'</code>). The way the length is
|
||||
encoded still allows the encoding to be its own counter:</p>
|
||||
<p>Notice these encodings in the initialization string. Only the coding for
|
||||
<code>5</code> needs an escape (<code>5 = ..... > 01111111 = '\177'</code>). The way the length
|
||||
is encoded still allows the encoding to be its own counter:</p>
|
||||
<div class="sourceCode" id="cb8"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb8-1"><a href="#cb8-1" aria-hidden="true" tabindex="-1"></a><span class="cf">do</span> <span class="op">{</span></span>
|
||||
<span id="cb8-2"><a href="#cb8-2" aria-hidden="true" tabindex="-1"></a> putchar<span class="op">(</span>encoding <span class="op">&</span> <span class="dv">1</span> <span class="op">?</span> <span class="ch">'-'</span> <span class="op">:</span> <span class="ch">'.'</span><span class="op">);</span></span>
|
||||
<span id="cb8-3"><a href="#cb8-3" aria-hidden="true" tabindex="-1"></a> encoding <span class="op">=</span> <span class="op">(</span>encoding <span class="op">+</span> <span class="dv">32</span><span class="op">)</span> <span class="op">>></span> <span class="dv">1</span><span class="op">;</span></span>
|
||||
<span id="cb8-4"><a href="#cb8-4" aria-hidden="true" tabindex="-1"></a><span class="op">}</span> <span class="cf">while</span> <span class="op">(</span>encoding <span class="op">></span> <span class="dv">35</span><span class="op">);</span></span></code></pre></div>
|
||||
<p>The last shift will always result in <code>00100010</code>, hence the
|
||||
test for <code>>35</code>. Note that the calculation for the next
|
||||
value of <code>encoding</code> is done at <code>int</code> precision, so
|
||||
that the actual value of the <code>char</code> remains
|
||||
<code><= 127</code>.</p>
|
||||
<p>The character <code>'-'</code> (ASCII 45) and <code>'.'</code> (ASCII
|
||||
46) are conveniently in sequence, so the putchar can simply be</p>
|
||||
<p>The last shift will always result in <code>00100010</code>, hence the test for <code>>35</code>.
|
||||
Note that the calculation for the next value of <code>encoding</code> is done at <code>int</code>
|
||||
precision, so that the actual value of the <code>char</code> remains <code><= 127</code>.</p>
|
||||
<p>The character <code>'-'</code> (ASCII 45) and <code>'.'</code> (ASCII 46) are conveniently in
|
||||
sequence, so the putchar can simply be</p>
|
||||
<div class="sourceCode" id="cb9"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb9-1"><a href="#cb9-1" aria-hidden="true" tabindex="-1"></a>putchar<span class="op">(</span><span class="dv">45</span> <span class="op">+</span> encoding <span class="op">%</span> <span class="dv">2</span><span class="op">);</span></span></code></pre></div>
|
||||
<p>I used the modulo operator this time, because <code>+</code> takes
|
||||
precedence over <code>&</code>. The assignment can be incorporated
|
||||
into the <code>while</code> control test, and a <code>do-while</code>
|
||||
loop with a body of a single expression statement can be written as a
|
||||
<code>while</code> loop with a comma operator in the test:</p>
|
||||
<p>I used the modulo operator this time, because <code>+</code> takes precedence over <code>&</code>.
|
||||
The assignment can be incorporated into the <code>while</code> control test, and a
|
||||
<code>do-while</code> loop with a body of a single expression statement can be written
|
||||
as a <code>while</code> loop with a comma operator in the test:</p>
|
||||
<div class="sourceCode" id="cb10"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb10-1"><a href="#cb10-1" aria-hidden="true" tabindex="-1"></a><span class="cf">while</span><span class="op">(</span>putchar<span class="op">(</span><span class="dv">45</span> <span class="op">+</span> encoding <span class="op">%</span> <span class="dv">2</span><span class="op">),</span> encoding <span class="op">=</span> encoding <span class="op">+</span> <span class="dv">32</span> <span class="op">>></span> <span class="dv">1</span><span class="op">);</span></span></code></pre></div>
|
||||
<p>Voila.</p>
|
||||
<p>Now, the decoding of Morse codes is just the reverse. We shift in
|
||||
<code>0</code>s and <code>1</code>s as we scan the line. But: we have to
|
||||
scan from back to front (the left most Morse symbol is in the least
|
||||
significant bit, and thus has to shifted in last). The test for the
|
||||
scanning while loop must stop when there are no more <code>.</code> or
|
||||
<code>-</code> on the left. Hence we need a terminating character in
|
||||
front of the line. The input line is read one past the encoding string
|
||||
(into the same character array) the terminating character for the
|
||||
reverse scan is therefore provided by the implicit <code>'\0'</code> of
|
||||
the array initializer ! The test also stops when at most 5 symbols have
|
||||
been shifted in.</p>
|
||||
<p>Now, the decoding of Morse codes is just the reverse. We shift in <code>0</code>s
|
||||
and <code>1</code>s as we scan the line. But: we have to scan from back to front
|
||||
(the left most Morse symbol is in the least significant bit, and thus
|
||||
has to shifted in last). The test for the scanning while loop must
|
||||
stop when there are no more <code>.</code> or <code>-</code> on the left. Hence we need a
|
||||
terminating character in front of the line. The input line is read one
|
||||
past the encoding string (into the same character array) the terminating
|
||||
character for the reverse scan is therefore provided by the implicit <code>'\0'</code>
|
||||
of the array initializer ! The test also stops when at most 5 symbols
|
||||
have been shifted in.</p>
|
||||
<p>The encoded character is then looked up in the encoding string with
|
||||
<code>memchr(3)</code> (why <code>memchr(3)</code> is explained later).
|
||||
Either a <code>?</code> (when there are more than 5 consecutive Morse
|
||||
symbols, or if the sequence is unknown) or the decoded character is
|
||||
printed. Or a <code>' '</code> if there was an extra space in the source
|
||||
line. Note the use of “or” in these last sentences, as they explain the
|
||||
use of the conditional operator.</p>
|
||||
<p>The <code>strspn(3)</code> calls need either <code>" .-"</code> or
|
||||
<code>".-"</code> as argument. Of course they are overlapped. I put
|
||||
these strings between the encodings for digits and letters. This is OK,
|
||||
since neither of these characters, or the <code>'\0'</code>, is a valid
|
||||
encoding ! We must, however, use <code>memchr(3)</code> instead of
|
||||
<code>strchr(3)</code> in the decoding lookup because of this
|
||||
<code>'\0'</code>. Since it is far more obscure this way, I hope you’ll
|
||||
forgive me.</p>
|
||||
<code>memchr(3)</code> (why <code>memchr(3)</code> is explained later). Either a <code>?</code> (when there are
|
||||
more than 5 consecutive Morse symbols, or if the sequence is unknown)
|
||||
or the decoded character is printed. Or a <code>' '</code> if there was an extra
|
||||
space in the source line. Note the use of “or” in these last sentences,
|
||||
as they explain the use of the conditional operator.</p>
|
||||
<p>The <code>strspn(3)</code> calls need either <code>" .-"</code> or <code>".-"</code> as argument. Of course they
|
||||
are overlapped. I put these strings between the encodings for digits
|
||||
and letters. This is OK, since neither of these characters, or the <code>'\0'</code>,
|
||||
is a valid encoding ! We must, however, use <code>memchr(3)</code> instead of <code>strchr(3)</code> in
|
||||
the decoding lookup because of this <code>'\0'</code>. Since it is far more obscure
|
||||
this way, I hope you’ll forgive me.</p>
|
||||
<p>The outline of the program is roughly as follows</p>
|
||||
<pre><code>while (more lines) {
|
||||
if (line is in morse) {
|
||||
@@ -245,21 +232,17 @@ forgive me.</p>
|
||||
putchar(' ');
|
||||
}
|
||||
}</code></pre>
|
||||
<p>Because of the <em>two</em> <code>while(more characters)</code> loops
|
||||
are the same, I’ve exchanged the <code>if(line is in morse)</code> and
|
||||
the two <code>while</code> loops (so there is <em>single</em>
|
||||
<code>while</code> loop). However, we must now store the
|
||||
<code>if(line is in morse)</code> test for efficiency (it would be
|
||||
stupid to test the entire line for every character). This is done in
|
||||
<code>l[0]</code> ! (the first encoding is thus in <code>l[1]</code>).
|
||||
The <code>memchr(3)</code> decoding lookup is not disturbed, because the
|
||||
test is always <code>0</code> for Morse lines, and <code>'\0'</code> is
|
||||
not a possible encoding. <code>l[0]</code> is also used as the temporary
|
||||
shift character while encoding a line of text. This does not disturb the
|
||||
<code>if (line is in morse)</code> test, as the temporary
|
||||
<code>l[0]</code> will remain <code>!= 0</code>.</p>
|
||||
<p>I’ve put the <code>if</code>s in the above layout into a single
|
||||
switch. Hope you don’t mind ;-)</p>
|
||||
<p>Because of the <em>two</em> <code>while(more characters)</code> loops are the same, I’ve
|
||||
exchanged the <code>if(line is in morse)</code> and the two <code>while</code> loops (so there
|
||||
is <em>single</em> <code>while</code> loop). However, we must now store the <code>if(line is in morse)</code> test for efficiency (it would be stupid to test the entire line
|
||||
for every character). This is done in <code>l[0]</code> ! (the first encoding is
|
||||
thus in <code>l[1]</code>). The <code>memchr(3)</code> decoding lookup is not disturbed, because the
|
||||
test is always <code>0</code> for Morse lines, and <code>'\0'</code> is not a possible encoding.
|
||||
<code>l[0]</code> is also used as the temporary shift character while encoding a
|
||||
line of text. This does not disturb the <code>if (line is in morse)</code> test,
|
||||
as the temporary <code>l[0]</code> will remain <code>!= 0</code>.</p>
|
||||
<p>I’ve put the <code>if</code>s in the above layout into a single switch. Hope you don’t
|
||||
mind ;-)</p>
|
||||
<p>Summary of the use of l[999]:</p>
|
||||
<pre><code>l[0] result of "is this line in morse" test
|
||||
l[0] temporary shift during encoding
|
||||
@@ -269,22 +252,21 @@ l[12] - l[14] strspn argument
|
||||
l[34] terminator for backward decoding
|
||||
l[35] - l[998] input line</code></pre>
|
||||
<hr />
|
||||
<p>Selected notes: - We don’t need to declare <code>isalnum(3)</code>
|
||||
(or include ctype.h) as its implicit declaration is correct (int
|
||||
argument, int result). This is not so for <code>strlen(3)</code>,
|
||||
<code>strspn(3)</code>, and <code>memchr(3)</code> as they use
|
||||
<code>size_t</code>. - During development, my gcc 2.7.2.3 had an
|
||||
internal compiler error (signal 6) on code that was correct ! - lclint
|
||||
2.4b thinks that “the observer is modified” a couple of times, whereas
|
||||
it is not. Well, it is, but there is a sequence point in between. -
|
||||
lclint 2.4b parses line 13 as <error>, whereas it is correct code. -
|
||||
lclint 2.4b is positive the second <code>while</code> loop is infinite,
|
||||
whereas it is not.</p>
|
||||
<p>Selected notes:
|
||||
- We don’t need to declare <code>isalnum(3)</code> (or include ctype.h) as its implicit
|
||||
declaration is correct (int argument, int result). This is not so for
|
||||
<code>strlen(3)</code>, <code>strspn(3)</code>, and <code>memchr(3)</code> as they use <code>size_t</code>.
|
||||
- During development, my gcc 2.7.2.3 had an internal compiler error (signal
|
||||
6) on code that was correct !
|
||||
- lclint 2.4b thinks that “the observer is modified” a couple of times,
|
||||
whereas it is not. Well, it is, but there is a sequence point in between.
|
||||
- lclint 2.4b parses line 13 as <error>, whereas it is correct code.
|
||||
- lclint 2.4b is positive the second <code>while</code> loop is infinite, whereas it is
|
||||
not.</p>
|
||||
<hr />
|
||||
<p>.. - …. .. -. -.- - …. .. … … .–. — .. .-.. . .-. .. … – — .-. . — -…
|
||||
..-. ..- … -.-. .- - . -.. - …. .- -. - …. . .–. .-. — –. .-. .- –</p>
|
||||
<p>. -..- . .-. -.-. .. … . -.-. …. .- -. –. . - …. . .–. .-. — –. .-.
|
||||
.- – … — .. - -.. — . … -. — - … …. — ..- -</p>
|
||||
<p>.. - …. .. -. -.- - …. .. … … .–. — .. .-.. . .-. .. … – — .-. . — -… ..-. ..- … -.-. .- - . -.. - …. .- -. - …. . .–. .-. — –. .-. .- –</p>
|
||||
<p>. -..- . .-. -.-. .. … .
|
||||
-.-. …. .- -. –. . - …. . .–. .-. — –. .-. .- – … — .. - -.. — . … -. — - … …. — ..- -</p>
|
||||
|
||||
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
<!-- START: this line starts content from: inc/after-content.default.html -->
|
||||
|
||||
+47
-78
@@ -129,9 +129,9 @@
|
||||
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Frans_van_Dorsselaer">Frans van
|
||||
Dorsselaer</a><br> Location: <a href="../../location.html#ZZ">ZZ</a> -
|
||||
<em>Unknown location</em> <br><br></li>
|
||||
<li>Name: <a href="../../authors.html#Frans_van_Dorsselaer">Frans van Dorsselaer</a><br>
|
||||
Location: <a href="../../location.html#ZZ">ZZ</a> - <em>Unknown location</em>
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -150,51 +150,43 @@ Dorsselaer</a><br> Location: <a href="../../location.html#ZZ">ZZ</a> -
|
||||
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./try.sh</span></span></code></pre></div>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>How does the program decide which way to convert?</p>
|
||||
<p>What obsolescent feature are we talking about? (No, it’s not a C
|
||||
language feature.)</p>
|
||||
<p>The author suggests that you try to answer the following
|
||||
questions:</p>
|
||||
<p>What obsolescent feature are we talking about? (No, it’s not a
|
||||
C language feature.)</p>
|
||||
<p>The author suggests that you try to answer the following questions:</p>
|
||||
<ul>
|
||||
<li><p>Which character in the initializing string is totally
|
||||
irrelevant?</p></li>
|
||||
<li><p>Which two relevant characters in the initializing string may be
|
||||
exchanged without altering the behavior?</p></li>
|
||||
<li><p>Which characters in the initializing string are somewhat
|
||||
irrelevant, and to what values may they be changed without altering the
|
||||
behavior?</p></li>
|
||||
<li><p>Which characters may be used to enlarge the initializing string
|
||||
by one without altering the behavior ?</p></li>
|
||||
<li><p>Which character in the initializing string is totally irrelevant?</p></li>
|
||||
<li><p>Which two relevant characters in the initializing string may be exchanged
|
||||
without altering the behavior?</p></li>
|
||||
<li><p>Which characters in the initializing string are somewhat irrelevant, and to
|
||||
what values may they be changed without altering the behavior?</p></li>
|
||||
<li><p>Which characters may be used to enlarge the initializing string by one without
|
||||
altering the behavior ?</p></li>
|
||||
</ul>
|
||||
<h3 id="extra-credit">Extra credit:</h3>
|
||||
<p>Try doing what the last part of the last command in <a
|
||||
href="try.sh">try.sh</a> suggests. As in, do the following:</p>
|
||||
<p>Try doing what the last part of the last command in <a href="try.sh">try.sh</a> suggests.
|
||||
As in, do the following:</p>
|
||||
<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="bu">echo</span> <span class="st">". -..- . .-. -.-. .. ... .</span></span>
|
||||
<span id="cb4-2"><a href="#cb4-2" aria-hidden="true" tabindex="-1"></a><span class="st">-.-. .... .- -. --. . - .... . .--. .-. --- --. .-. .- -- ... --- .. - -.. --- . ... -. --- - ... .... --- ..- -"</span> <span class="kw">|</span> <span class="ex">./dorssel</span></span></code></pre></div>
|
||||
<p>and make the necessary adjustments.</p>
|
||||
<p>You might also want to read the <a
|
||||
href="dorssel.html">dorssel.html</a> file.</p>
|
||||
<p>You might also want to read the <a href="dorssel.html">dorssel.html</a> file.</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<h3 id="usage">Usage</h3>
|
||||
<p>This program converts ASCII to <a
|
||||
href="https://en.wikipedia.org/wiki/Morse_code">Morse code</a>, and vice
|
||||
versa.</p>
|
||||
<p>The program reads in lines from standard input and writes its result
|
||||
to standard output. The direction of conversion is determined on a per
|
||||
<p>This program converts ASCII to <a href="https://en.wikipedia.org/wiki/Morse_code">Morse
|
||||
code</a>, and vice versa.</p>
|
||||
<p>The program reads in lines from standard input and writes its result to
|
||||
standard output. The direction of conversion is determined on a per
|
||||
line basis. Each line must consist of a maximum of 952 characters
|
||||
followed by a new line character and they must not contain any NUL
|
||||
characters. Otherwise, some characters may be lost in the
|
||||
conversion.</p>
|
||||
characters. Otherwise, some characters may be lost in the conversion.</p>
|
||||
<ul>
|
||||
<li><p>Encoding to Morse code: The program knows the Morse codes for all
|
||||
Latin letters (a-z, case insensitive) and decimal digits (0-9). Any
|
||||
other characters are replaced by an ASCII space, <code>' '</code>. Morse
|
||||
code per converted character is written as a sequence of <code>.</code>
|
||||
and <code>-</code> characters, each sequence followed by a
|
||||
<li><p>Encoding to Morse code: The program knows the Morse codes for all Latin
|
||||
letters (a-z, case insensitive) and decimal digits (0-9). Any other characters
|
||||
are replaced by an ASCII space, <code>' '</code>. Morse code per converted character is
|
||||
written as a sequence of <code>.</code> and <code>-</code> characters, each sequence followed by a
|
||||
space.</p></li>
|
||||
<li><p>Decoding from Morse code: Morse code should be typed as sequences
|
||||
of <code>.</code> and <code>-</code> characters, separated by a space.
|
||||
Extra spaces will be echoed back (to separate words). Unknown sequences
|
||||
will be converted to a <code>?</code> character.</p></li>
|
||||
<li><p>Decoding from Morse code: Morse code should be typed as sequences of <code>.</code> and
|
||||
<code>-</code> characters, separated by a space. Extra spaces will be echoed back (to
|
||||
separate words). Unknown sequences will be converted to a <code>?</code> character.</p></li>
|
||||
</ul>
|
||||
<h3 id="notes">Notes</h3>
|
||||
<p>The program assumes both source and execution character sets to be
|
||||
@@ -206,70 +198,47 @@ invoke undefined behavior.</p>
|
||||
<p>to see what variables, numbers, and functions are used. (Does a
|
||||
better job than most C beautifiers).</p>
|
||||
<ul>
|
||||
<li>Filter your text twice (as in the previous sample) to obtain a
|
||||
version of your text that can be reversibly Morsified, i.e.</li>
|
||||
<li>Filter your text twice (as in the previous sample) to obtain a version of your
|
||||
text that can be reversibly Morsified, i.e.</li>
|
||||
</ul>
|
||||
<div class="sourceCode" id="cb6"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./dorssel</span> <span class="op"><</span> dorssel.c <span class="kw">|</span> <span class="ex">./dorssel</span> <span class="kw">|</span> <span class="ex">./dorssel</span> <span class="kw">|</span> <span class="ex">./dorssel</span></span></code></pre></div>
|
||||
<p>is the same as</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="ex">./dorssel</span> <span class="op"><</span> dorssel.c <span class="kw">|</span> <span class="ex">./dorssel</span></span></code></pre></div>
|
||||
<ul>
|
||||
<li>The file <a href="dorssel.md">dorssel.md</a> contains all the
|
||||
information needed to understand this program. For an obfuscated
|
||||
spoiler, try</li>
|
||||
<li>The file <a href="dorssel.md">dorssel.md</a> contains all the information needed to
|
||||
understand this program. For an obfuscated spoiler, try</li>
|
||||
</ul>
|
||||
<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="ex">./dorssel</span> <span class="op"><</span> dorssel.md</span></code></pre></div>
|
||||
<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>
|
||||
<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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998dorssel"><a name="inventory"></a>Inventory for
|
||||
1998/dorssel</h1>
|
||||
<h1 id="inventory-for-1998dorssel"><a name="inventory"></a>Inventory for 1998/dorssel</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/dorssel.c">dorssel.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/dorssel.orig.c">dorssel.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a href="dorssel.html">dorssel.html</a> - author description of
|
||||
entry</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a href="1998_dorssel.tar.bz2">1998_dorssel.tar.bz2</a> - download
|
||||
entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/dorssel.c">dorssel.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/dorssel.orig.c">dorssel.orig.c</a> - original source</li>
|
||||
<li><a href="dorssel.html">dorssel.html</a> - author description of entry</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="1998_dorssel.tar.bz2">1998_dorssel.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/.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/1998/dorssel/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/.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/1998/dorssel/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/dorssel.md">dorssel.md</a>
|
||||
- markdown source for dorssel.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/README.md">README.md</a> - markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/dorssel.md">dorssel.md</a> - markdown source for dorssel.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+170
-220
@@ -130,8 +130,7 @@
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Tony_Finch">Tony Finch</a><br>
|
||||
Location: <a href="../../location.html#GB">GB</a> - <em>United Kingdom
|
||||
of Great Britain and Northern Ireland</em> (<em>United Kingdom</em>)
|
||||
Location: <a href="../../location.html#GB">GB</a> - <em>United Kingdom of Great Britain and Northern Ireland</em> (<em>United Kingdom</em>)
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
@@ -147,38 +146,35 @@ this entry because of the system resources it requires.</p>
|
||||
<h2 id="to-use">To use:</h2>
|
||||
<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="ex">./fanf</span></span></code></pre></div>
|
||||
<h2 id="try">Try:</h2>
|
||||
<p>Enter an expression on standard input. To try some we have
|
||||
selected:</p>
|
||||
<p>Enter an expression on standard input. To try some we have selected:</p>
|
||||
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./try.sh</span></span></code></pre></div>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<h3 id="historical-aside">Historical aside:</h3>
|
||||
<p>At a time the code in <a href="fanf.c">fanf.c</a> was that of <a
|
||||
href="fanf.orig.c">fanf.orig.c</a> but to get this to compile in modern
|
||||
systems it had to be translated to what you now see. The intermediate
|
||||
steps can still be performed but they might be different from the past.
|
||||
This should be kept in mind as you read the below remarks.</p>
|
||||
<p>At a time the code in <a href="fanf.c">fanf.c</a> was that of <a href="fanf.orig.c">fanf.orig.c</a>
|
||||
but to get this to compile in modern systems it had to be translated to what you
|
||||
now see. The intermediate steps can still be performed but they might be
|
||||
different from the past. This should be kept in mind as you read the below
|
||||
remarks.</p>
|
||||
<p>This program translates lambda expressions into combinator
|
||||
expressions. But you do not need to know Lambda Calculus to be impressed
|
||||
by this program!</p>
|
||||
<p>See the file <a href="fanf.lambda">fanf.lambda</a> for more examples
|
||||
of lambda calculus source.</p>
|
||||
<p>Notice how large the code grows from the <a href="fanf.c">fanf.c</a>
|
||||
into the final <code>fanftmp2.c</code> C program. Take a look at that
|
||||
final C program again, can you begin to understand what it is doing?</p>
|
||||
<p>Look at the first stage of the C pre-processing which was done
|
||||
like:</p>
|
||||
expressions. But you do not need to know Lambda Calculus to be
|
||||
impressed by this program!</p>
|
||||
<p>See the file <a href="fanf.lambda">fanf.lambda</a> for more examples of lambda calculus
|
||||
source.</p>
|
||||
<p>Notice how large the code grows from the <a href="fanf.c">fanf.c</a> into the final
|
||||
<code>fanftmp2.c</code> C program. Take a look at that final C program again,
|
||||
can you begin to understand what it is doing?</p>
|
||||
<p>Look at the first stage of the C pre-processing which was done like:</p>
|
||||
<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="fu">cc</span> fanf.c <span class="at">-E</span> <span class="op">></span> fanftmp1.c</span></code></pre></div>
|
||||
<p>Skip to the bottom of <code>fanftmp1.c</code> (after all of the C
|
||||
pre-processor header stuff … look for a line of the form:
|
||||
<code># 38 "fanf.c"</code> near the bottom) and look at the resulting
|
||||
code. This code, when C pre-processed will expand into over 342 times
|
||||
the original code (ignoring <code>#include</code> headers) to produce
|
||||
<code>fanftmp2.c</code>. That program in turn, when compiled translates
|
||||
a single lambda expression on standard input into combinator expressions
|
||||
on standard output.</p>
|
||||
<p>Skip to the bottom of <code>fanftmp1.c</code> (after all of the C pre-processor header
|
||||
stuff … look for a line of the form: <code># 38 "fanf.c"</code> near the bottom)
|
||||
and look at the resulting code. This code, when C pre-processed
|
||||
will expand into over 342 times the original code (ignoring <code>#include</code>
|
||||
headers) to produce <code>fanftmp2.c</code>. That program in turn, when compiled
|
||||
translates a single lambda expression on standard input into
|
||||
combinator expressions on standard output.</p>
|
||||
<h3 id="extra-credit-question">Extra credit question:</h3>
|
||||
<p>What do you have to do to make this program work with an old non-ANSI
|
||||
C preprocessor?</p>
|
||||
<p>What do you have to do to make this program work with an old non-ANSI C
|
||||
preprocessor?</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<p>My program is a demonstration of some practical applications of
|
||||
theoretical computer science. The application it implements is a program
|
||||
@@ -186,33 +182,28 @@ for translating lambda expressions into combinator expressions.</p>
|
||||
<h3 id="what-the-program-does">What the program does</h3>
|
||||
<p>The syntax of lambda expressions recognised by the program is as
|
||||
follows: The basic atoms are variables which are single characters other
|
||||
than backslash or parentheses, e.g. <code>a</code> or <code>b</code> or
|
||||
<code>@</code>. Variables are combined by function application which is
|
||||
written as e.g. <code>(f a)</code> which is the function <code>f</code>
|
||||
applied to the argument <code>a</code>. Application groups to the left,
|
||||
so <code>(f a b c)</code> is equivalent to <code>(((f a) b) c)</code>.
|
||||
Functions are created from lambda terms which are written in the form
|
||||
<code>\a(expr)</code> which is the function taking argument
|
||||
<code>a</code> and having value <code>expr</code>. Lambda is spelt
|
||||
<code>\</code> because ASCII isn’t good enough. Lambda binds tightly, so
|
||||
<code>\a\bcd</code> is equivalent to <code>((\a(\b(c))) d)</code>.
|
||||
Whitespace is ignored.</p>
|
||||
<p>For example, the identity function, called <code>I</code>, is written
|
||||
<code>\x(x)</code>. A simple expression is <code>(I a)</code> which is
|
||||
equivalent to <code>(\x(x) a)</code>, which has the value
|
||||
<code>a</code>. Another function called <code>K</code> is defined as
|
||||
<code>\x\y(x)</code> and it evaluates as follows:</p>
|
||||
than backslash or parentheses, e.g. <code>a</code> or <code>b</code> or <code>@</code>. Variables are
|
||||
combined by function application which is written as e.g. <code>(f a)</code> which is
|
||||
the function <code>f</code> applied to the argument <code>a</code>. Application groups to the
|
||||
left, so <code>(f a b c)</code> is equivalent to <code>(((f a) b) c)</code>. Functions are
|
||||
created from lambda terms which are written in the form <code>\a(expr)</code> which
|
||||
is the function taking argument <code>a</code> and having value <code>expr</code>. Lambda is
|
||||
spelt <code>\</code> because ASCII isn’t good enough. Lambda binds tightly, so
|
||||
<code>\a\bcd</code> is equivalent to <code>((\a(\b(c))) d)</code>. Whitespace is ignored.</p>
|
||||
<p>For example, the identity function, called <code>I</code>, is written <code>\x(x)</code>. A
|
||||
simple expression is <code>(I a)</code> which is equivalent to <code>(\x(x) a)</code>, which
|
||||
has the value <code>a</code>. Another function called <code>K</code> is defined as <code>\x\y(x)</code>
|
||||
and it evaluates as follows:</p>
|
||||
<pre><code> K p q
|
||||
-> \x\y(x) p q
|
||||
-> \y(p) q
|
||||
-> p</code></pre>
|
||||
<p>Another function of interest is <code>S</code>, defined as
|
||||
<code>\f\g\x((f x) (g x))</code>. My program demonstrates the fact that
|
||||
any lambda expression can be translated into an equivalent “combinator
|
||||
expression” which involves only <code>S</code>, <code>K</code>,
|
||||
<code>I</code> (the combinators), and application, with no variables or
|
||||
lambda abstractions. In fact, even <code>I</code> is unnecessary, since
|
||||
it is equivalent to <code>S K K</code>:</p>
|
||||
<p>Another function of interest is <code>S</code>, defined as <code>\f\g\x((f x) (g x))</code>.
|
||||
My program demonstrates the fact that any lambda expression can be
|
||||
translated into an equivalent “combinator expression” which involves
|
||||
only <code>S</code>, <code>K</code>, <code>I</code> (the combinators), and application, with no
|
||||
variables or lambda abstractions. In fact, even <code>I</code> is unnecessary,
|
||||
since it is equivalent to <code>S K K</code>:</p>
|
||||
<pre><code> I z
|
||||
-> \a(a) z
|
||||
-> z
|
||||
@@ -234,9 +225,8 @@ variables.</p>
|
||||
<pre><code>abs a f x -> S (abs a f) (abs a x)
|
||||
abs a b -> K b (b != a)
|
||||
abs a a -> I</code></pre>
|
||||
<p>E.g. suppose we had combinator expressions for <code>+</code> and
|
||||
<code>3</code> and we wanted to see what the combinator expression for
|
||||
doubling 3 looked like:</p>
|
||||
<p>E.g. suppose we had combinator expressions for <code>+</code> and <code>3</code> and we wanted
|
||||
to see what the combinator expression for doubling 3 looked like:</p>
|
||||
<pre><code> trans \x(+ x x) 3
|
||||
-> (trans \x(+ x x)) (trans 3)
|
||||
-> (abs x (trans + x x)) 3
|
||||
@@ -252,128 +242,113 @@ doubling 3 looked like:</p>
|
||||
-> + (I 3) (I 3)
|
||||
-> + 3 3</code></pre>
|
||||
<p>It is possible to perform a slightly more compact translation with a
|
||||
couple of simple optimisations. For example, note that
|
||||
<code>K (a b)</code> is the same as <code>S (K a) (K b)</code>,
|
||||
because</p>
|
||||
couple of simple optimisations. For example, note that <code>K (a b)</code> is the
|
||||
same as <code>S (K a) (K b)</code>, because</p>
|
||||
<pre><code> K (a b) x
|
||||
-> a b</code></pre>
|
||||
<p>and</p>
|
||||
<pre><code> S (K a) (K b) x
|
||||
-> K a x (K b x)
|
||||
-> a b</code></pre>
|
||||
<p>Also, <code>S (K a) I</code> is the same as just <code>a</code>
|
||||
because</p>
|
||||
<p>Also, <code>S (K a) I</code> is the same as just <code>a</code> because</p>
|
||||
<pre><code> S (K a) I x
|
||||
-> K a x (I x)
|
||||
-> a x</code></pre>
|
||||
<p>The program simply reads a lambda expression from the standard input,
|
||||
translates it into a combinator expression using the transformation and
|
||||
optimisations described above, and prints out the result.</p>
|
||||
<h3 id="why-this-is-a-practical-application">Why this is a practical
|
||||
application</h3>
|
||||
<h3 id="why-this-is-a-practical-application">Why this is a practical application</h3>
|
||||
<p>Combinator expressions are easier to evaluate than lambda expressions
|
||||
because there are no problems with variables. For example, if I naively
|
||||
evaluated the expression <code>\x\y(x y) y</code> I might get
|
||||
<code>\y(y y)</code> which is not the same as the correct result because
|
||||
the first <code>y</code> in the body should refer to a global
|
||||
<code>y</code> rather than the local one. David Turner was the first
|
||||
person to realise that because of this fact, SK combinators provide a
|
||||
simple way to implement non-strict functional programming languages,
|
||||
either in software or directly in hardware.</p>
|
||||
<p>My program demonstrates this by being based on a combinator
|
||||
evaluation engine which is used to implement a language called
|
||||
<code>OFL</code> (pronounced like “offal” and short for “Obfuscated
|
||||
Functional Language”). I then used <code>OFL</code> to implement all the
|
||||
high-level functionality described above. This contributes a lot to the
|
||||
obfuscation because even small amounts of <code>OFL</code> are quite
|
||||
unpalatable, and large expressions are completely incomprehensible.</p>
|
||||
evaluated the expression <code>\x\y(x y) y</code> I might get <code>\y(y y)</code> which is
|
||||
not the same as the correct result because the first <code>y</code> in the body
|
||||
should refer to a global <code>y</code> rather than the local one. David Turner was
|
||||
the first person to realise that because of this fact, SK combinators
|
||||
provide a simple way to implement non-strict functional programming
|
||||
languages, either in software or directly in hardware.</p>
|
||||
<p>My program demonstrates this by being based on a combinator evaluation
|
||||
engine which is used to implement a language called <code>OFL</code> (pronounced
|
||||
like “offal” and short for “Obfuscated Functional Language”). I then
|
||||
used <code>OFL</code> to implement all the high-level functionality described above.
|
||||
This contributes a lot to the obfuscation because even small amounts of
|
||||
<code>OFL</code> are quite unpalatable, and large expressions are completely
|
||||
incomprehensible.</p>
|
||||
<p>It is fairly well known that the lambda calculus (and hence SK
|
||||
combinators) can compute anything, but mere computation is no use if you
|
||||
cannot communicate with the world. This is why <code>OFL</code> includes
|
||||
a few concessions to reality: a combinator <code>E</code> for
|
||||
representing characters and testing them for equality, two I/O
|
||||
combinators, <code>G</code> and <code>P</code>, for reading and writing
|
||||
characters respectively, and a combinator <code>J</code> for
|
||||
representing <code>false</code>. I also implemented the <code>Y</code>
|
||||
combinator directly rather than in terms of the primitive combinators,
|
||||
since it only required five characters to do so
|
||||
(viz. <code>Y W q Q g</code>). However this code is not enabled because
|
||||
the definition of <code>Y</code> in terms of other combinators is more
|
||||
cute.</p>
|
||||
<p>The <code>E</code> combinator comes in a large number of forms, one
|
||||
for each character and one for end of file. It is written
|
||||
<code>E(c)</code> for the variant of <code>E</code> corresponding to the
|
||||
character <code>c</code>. An expression of the form <code>E(c) x</code>
|
||||
is evaluated by first evaluating <code>x</code>. If <code>x</code>
|
||||
doesn’t evaluate to some form of <code>E</code>, then evaluation of the
|
||||
expression terminates. If <code>x</code> evaluates to <code>E(c)</code>,
|
||||
then the expression evaluates to <code>K</code>. If <code>x</code>
|
||||
evaluates to <code>E(d)</code> (where <code>d</code> is a different
|
||||
character to <code>c</code>), then the expression evaluates to
|
||||
<code>J</code>.</p>
|
||||
<p><code>K</code> and <code>J</code> are used to represent
|
||||
<code>true</code> and <code>false</code> respectively; they correspond
|
||||
exactly to the standard lambda calculus representations of
|
||||
<code>true</code> and <code>false</code>, viz. <code>\t\f(t)</code> and
|
||||
<code>\t\f(f)</code> respectively. In this way a conditional expression
|
||||
can just be written <code>cond then else</code>, which is even more
|
||||
terse than C <code>cond ? then : else</code>. An expression that
|
||||
compares a character with <code>a</code>, say, can be written in the
|
||||
rather obfuscated form <code>E('a') char then else</code>.</p>
|
||||
<p>The <code>P</code> combinator, like the <code>E</code> combinator,
|
||||
starts off by evaluating its first argument and checking that it is some
|
||||
form of <code>E</code>. It then writes that character on
|
||||
<code>stdout</code>, and finally it calls its second argument as a
|
||||
function with the argument <code>I</code>, i.e.</p>
|
||||
cannot communicate with the world. This is why <code>OFL</code> includes a few
|
||||
concessions to reality: a combinator <code>E</code> for representing characters and
|
||||
testing them for equality, two I/O combinators, <code>G</code> and <code>P</code>, for reading
|
||||
and writing characters respectively, and a combinator <code>J</code> for
|
||||
representing <code>false</code>. I also implemented the <code>Y</code> combinator directly
|
||||
rather than in terms of the primitive combinators, since it only
|
||||
required five characters to do so (viz. <code>Y W q Q g</code>). However this code
|
||||
is not enabled because the definition of <code>Y</code> in terms of other combinators
|
||||
is more cute.</p>
|
||||
<p>The <code>E</code> combinator comes in a large number of forms, one for each
|
||||
character and one for end of file. It is written <code>E(c)</code> for the variant
|
||||
of <code>E</code> corresponding to the character <code>c</code>. An expression of the form
|
||||
<code>E(c) x</code> is evaluated by first evaluating <code>x</code>. If <code>x</code> doesn’t evaluate
|
||||
to some form of <code>E</code>, then evaluation of the expression terminates. If
|
||||
<code>x</code> evaluates to <code>E(c)</code>, then the expression evaluates to <code>K</code>. If <code>x</code>
|
||||
evaluates to <code>E(d)</code> (where <code>d</code> is a different character to <code>c</code>), then
|
||||
the expression evaluates to <code>J</code>.</p>
|
||||
<p><code>K</code> and <code>J</code> are used to represent <code>true</code> and <code>false</code> respectively; they
|
||||
correspond exactly to the standard lambda calculus representations of
|
||||
<code>true</code> and <code>false</code>, viz. <code>\t\f(t)</code> and <code>\t\f(f)</code> respectively. In this way a
|
||||
conditional expression can just be written <code>cond then else</code>, which is
|
||||
even more terse than C <code>cond ? then : else</code>. An expression that
|
||||
compares a character with <code>a</code>, say, can be written in the rather
|
||||
obfuscated form <code>E('a') char then else</code>.</p>
|
||||
<p>The <code>P</code> combinator, like the <code>E</code> combinator, starts off by evaluating
|
||||
its first argument and checking that it is some form of <code>E</code>. It then
|
||||
writes that character on <code>stdout</code>, and finally it calls its second
|
||||
argument as a function with the argument <code>I</code>, i.e.</p>
|
||||
<pre><code>P x f -> f I</code></pre>
|
||||
<p>with a side-effect.</p>
|
||||
<p>The <code>G</code> combinator just reads a character from
|
||||
<code>stdin</code> then calls its argument as a function with the
|
||||
appropriate <code>E</code> combinator as an argument, i.e.</p>
|
||||
<p>The <code>G</code> combinator just reads a character from <code>stdin</code> then calls its
|
||||
argument as a function with the appropriate <code>E</code> combinator as an
|
||||
argument, i.e.</p>
|
||||
<pre><code>G f -> f E(c)</code></pre>
|
||||
<p>with a side-effect.</p>
|
||||
<p>One of the problems with non-strict languages is that it is hard to
|
||||
predict in advance in which order side-effects will occur. In my program
|
||||
I used a monadic I/O structure like that used by the programming
|
||||
language Haskell; this allows one to write programs that manipulate
|
||||
external state in a manner remarkably similar to imperative programming
|
||||
languages like C. An examination of my program should provide an
|
||||
illustration of how well this technique works in practice. (In
|
||||
particular, I used the CPS form of the I/O monad from page 6 of
|
||||
“Imperative Functional Programming”.)</p>
|
||||
<p>The <code>Y</code> combinator is used for implementing recursive
|
||||
functions. It has the evaluation rule</p>
|
||||
I used a monadic I/O structure like that used by the programming language
|
||||
Haskell; this allows one to write programs that manipulate external
|
||||
state in a manner remarkably similar to imperative programming languages
|
||||
like C. An examination of my program should provide an illustration of
|
||||
how well this technique works in practice. (In particular, I used the
|
||||
CPS form of the I/O monad from page 6 of “Imperative Functional
|
||||
Programming”.)</p>
|
||||
<p>The <code>Y</code> combinator is used for implementing recursive functions. It has
|
||||
the evaluation rule</p>
|
||||
<pre><code>Y f -> f (Y f)</code></pre>
|
||||
<p>so that it can be used to call a function with itself as an argument.
|
||||
For example, if I had the appropriate arithmetic operators defined, I
|
||||
could write a factorial function in the lambda calculus like this:</p>
|
||||
<pre><code>Y \f\n((= n 0) 1 (* n (f (- n 1))))</code></pre>
|
||||
<p><code>OFL</code> provides a facility for naming expressions so that
|
||||
they can be used more than once without writing them in full. A
|
||||
definition must be written on one line in the form
|
||||
<code>l name b expression</code> where <code>l</code> is short for “let”
|
||||
and <code>b</code> is short for “be”. Names must be more than one
|
||||
character long. A complete <code>OFL</code> program starts off by
|
||||
defining the primitives it will use with likes of the form
|
||||
<code>p (S)</code> etc., then goes on to define the names it will use,
|
||||
and finishes off with the main expression followed by a single
|
||||
<code>e</code> short for “end”. <code>OFL</code> expressions must use
|
||||
the minimum number of brackets needed to be unambiguous, except that the
|
||||
whole expression must be surrounded by brackets.</p>
|
||||
<p><code>OFL</code> has a standard library which adds another five
|
||||
combinators to the basic eight. These combinators provide greater scope
|
||||
for optimisation when translating an expression from the lambda calculus
|
||||
to combinators, and therefore more compact programs. Their evaluation
|
||||
rules are:</p>
|
||||
<p><code>OFL</code> provides a facility for naming expressions so that they can be used
|
||||
more than once without writing them in full. A definition must be written
|
||||
on one line in the form <code>l name b expression</code> where <code>l</code> is short for
|
||||
“let” and <code>b</code> is short for “be”. Names must be more than one character
|
||||
long. A complete <code>OFL</code> program starts off by defining the primitives it
|
||||
will use with likes of the form <code>p (S)</code> etc., then goes on to define the
|
||||
names it will use, and finishes off with the main expression followed by
|
||||
a single <code>e</code> short for “end”. <code>OFL</code> expressions must use the minimum
|
||||
number of brackets needed to be unambiguous, except that the whole
|
||||
expression must be surrounded by brackets.</p>
|
||||
<p><code>OFL</code> has a standard library which adds another five combinators to the
|
||||
basic eight. These combinators provide greater scope for optimisation
|
||||
when translating an expression from the lambda calculus to combinators,
|
||||
and therefore more compact programs. Their evaluation rules are:</p>
|
||||
<pre><code>B f g x -> f (g x)
|
||||
C f g x -> (f x) g
|
||||
BB c f g x -> c (f (g x))
|
||||
CC c f g x -> c (f x) g
|
||||
SS c f g x -> c (f x) (g x)</code></pre>
|
||||
<p>I used them to help fit my program into the required space;
|
||||
unfortunately I couldn’t fit the version that fully optimises the lambda
|
||||
expressions it reads into the required space. The complete optimisation
|
||||
rules including the ones it doesn’t use are:</p>
|
||||
<p>I used them to help fit my program into the required space; unfortunately
|
||||
I couldn’t fit the version that fully optimises the lambda expressions
|
||||
it reads into the required space. The complete optimisation rules
|
||||
including the ones it doesn’t use are:</p>
|
||||
<pre><code>S (K p) I -> p
|
||||
S (K p) (K r) -> K ( p r )
|
||||
S (K p) (B r s) -> BB p r s
|
||||
@@ -382,62 +357,58 @@ S (B p q) (K r) -> CC p q r
|
||||
S p (K r) -> C p r
|
||||
S (B p q) r -> SS p q r
|
||||
S p r -> S p r</code></pre>
|
||||
<h3 id="the-implementation-of-ofl">The implementation of
|
||||
<code>OFL</code></h3>
|
||||
<p>Although <code>OFL</code> has completely different syntax and
|
||||
semantics to C, all you need to compile <code>OFL</code> programs is a C
|
||||
compiler and a header file (which in my entry to the competition has
|
||||
been included in-line). The header file implements a two-pass optimising
|
||||
compiler which produces a representation of the program that is then
|
||||
interpreted.</p>
|
||||
<p>The first pass of the compiler is implemented via the C preprocessor.
|
||||
It implements one optimisation, namely function in-lining.
|
||||
Unfortunately, this optimisation always increases object code size and
|
||||
execution time. The opposite optimisation, common sub-expression
|
||||
elimination (which would offer improvements in code size and execution
|
||||
time), has not been implemented. The output of this pass is a C program
|
||||
that may be compiled by a normal C compiler.</p>
|
||||
<h3 id="the-implementation-of-ofl">The implementation of <code>OFL</code></h3>
|
||||
<p>Although <code>OFL</code> has completely different syntax and semantics to C, all you
|
||||
need to compile <code>OFL</code> programs is a C compiler and a header file (which in
|
||||
my entry to the competition has been included in-line). The header file
|
||||
implements a two-pass optimising compiler which produces a representation
|
||||
of the program that is then interpreted.</p>
|
||||
<p>The first pass of the compiler is implemented via the C preprocessor. It
|
||||
implements one optimisation, namely function in-lining. Unfortunately,
|
||||
this optimisation always increases object code size and execution time.
|
||||
The opposite optimisation, common sub-expression elimination (which
|
||||
would offer improvements in code size and execution time), has not been
|
||||
implemented. The output of this pass is a C program that may be compiled
|
||||
by a normal C compiler.</p>
|
||||
<p>The second pass is performed by the initialisation phase of the C
|
||||
program. It builds a data structure representing the abstract syntax
|
||||
tree of the program.</p>
|
||||
<p>The program is then executed by an interpreter. This operates by
|
||||
performing manipulations on the AST that correspond to the evaluation
|
||||
rules of the combinators that I described above.</p>
|
||||
<p>The first 54 lines of the program are mostly the interpreter; the
|
||||
next 8 lines are pass one of the compiler; the next nine declare the
|
||||
<code>OFL</code> primitives; the next five define the <code>OFL</code>
|
||||
standard library; and the rest implement the application described in
|
||||
the first part of this document. This part of the program is transformed
|
||||
into the second pass of the compiler by the first pass of the
|
||||
compiler.</p>
|
||||
<p>The first pass of the compiler relies on some magic macros that
|
||||
expand in a mutually-overlapping and almost recursive way in order to
|
||||
<p>The first 54 lines of the program are mostly the interpreter; the next 8
|
||||
lines are pass one of the compiler; the next nine declare the <code>OFL</code>
|
||||
primitives; the next five define the <code>OFL</code> standard library; and the rest
|
||||
implement the application described in the first part of this document.
|
||||
This part of the program is transformed into the second pass of the
|
||||
compiler by the first pass of the compiler.</p>
|
||||
<p>The first pass of the compiler relies on some magic macros that expand
|
||||
in a mutually-overlapping and almost recursive way in order to
|
||||
perpetrate a complete change of syntax. Interestingly enough, if I
|
||||
hadn’t used the same identifier for more than one thing in various
|
||||
places in the program this transformation would work with old-style cpp
|
||||
as well and ANSI cpp. It expands the program from about 2.2KB to about
|
||||
740KB. The resulting code does some tricky stuff to build a data
|
||||
structure of the same form as the code itself.</p>
|
||||
<p>The interpreter is written in fairly straightforward C, although it
|
||||
is highly compressed. The C itself is written in a fairly functional
|
||||
style, in that every function consists of a single expression. In the
|
||||
tradition of functional programming languages it assumes that memory is
|
||||
infinite and so never frees anything. It also assumes that the C
|
||||
compiler implements the tail recursion optimisation, which is probably
|
||||
not true.</p>
|
||||
<p>The interpreter is written in fairly straightforward C, although it is
|
||||
highly compressed. The C itself is written in a fairly functional style,
|
||||
in that every function consists of a single expression. In the tradition
|
||||
of functional programming languages it assumes that memory is infinite
|
||||
and so never frees anything. It also assumes that the C compiler
|
||||
implements the tail recursion optimisation, which is probably not true.</p>
|
||||
<h3 id="references">References</h3>
|
||||
<p>I used these references in the course of writing this program and
|
||||
they explain some of the ideas behind it in more detail. Arthur Norman
|
||||
(one of the authors of the first paper) did a lot to enthuse me about
|
||||
this topic.</p>
|
||||
<p>I used these references in the course of writing this program and they
|
||||
explain some of the ideas behind it in more detail. Arthur Norman (one
|
||||
of the authors of the first paper) did a lot to enthuse me about this
|
||||
topic.</p>
|
||||
<p>Clarke, T. J. W., et al., 1980. SKIM - the S, K, I Reduction Machine.
|
||||
Proceedings of the 1980 ACM LISP Conference, pp. 128-135.</p>
|
||||
<p>Curry, H. B. and Feys, R., 1958. Combinatory Logic, Vol. 1.
|
||||
North-Holland.</p>
|
||||
<p>Gordon, M. J. C., 1988. Programming Language Theory and its
|
||||
Implementation. Prentice-Hall.</p>
|
||||
<p>Peterson, J, et al., 1997. Report on the Programming Language
|
||||
Haskell, version 1.4.</p>
|
||||
<p>Peterson, J, et al., 1997. Report on the Programming Language Haskell,
|
||||
version 1.4.</p>
|
||||
<p>Peyton Jones, S. L., 1987. The implementation of Functional
|
||||
Programming Languages, Chapters 2, 11, 12, 16. Prentice-Hall.</p>
|
||||
<p>Peyton Jones, S. L., and Wadler, P., 1992. Imperative Functional
|
||||
@@ -445,62 +416,41 @@ Programming. Proceedings of the ACM Symposium on the Principles of
|
||||
Programming Languages 1993, pp. 71-84.</p>
|
||||
<p>Turner, D. A., 1979. A new implementation technique for applicative
|
||||
languages. Software- Practice and Experience. Vol. 9, pp. 31-49.</p>
|
||||
<p>Turner, D. A., 1979. Another algorithm for bracket abstraction.
|
||||
Journal of Symbolic Logic. Vol. 44, no. 2, pp. 67-270.</p>
|
||||
<p>Turner, D. A., 1979. Another algorithm for bracket abstraction. Journal
|
||||
of Symbolic Logic. Vol. 44, no. 2, pp. 67-270.</p>
|
||||
<p>Wadler, P., 1990. Comprehending Monads. Proceedings of the ACM
|
||||
conference on Lisp and Functional Programming, 1990.</p>
|
||||
<p>Wadler, P., 1995. How to Declare an Imperative. Proceedings of the
|
||||
ACM International Logic Programming Symposium, 1995.</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>
|
||||
<p>Wadler, P., 1995. How to Declare an Imperative. Proceedings of the ACM
|
||||
International Logic Programming Symposium, 1995.</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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998fanf"><a name="inventory"></a>Inventory for
|
||||
1998/fanf</h1>
|
||||
<h1 id="inventory-for-1998fanf"><a name="inventory"></a>Inventory for 1998/fanf</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/fanf.c">fanf.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/fanf.orig.c">fanf.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/fanf.lambda">fanf.lambda</a>
|
||||
- lambda expressions</li>
|
||||
<li><a href="1998_fanf.tar.bz2">1998_fanf.tar.bz2</a> - download entry
|
||||
source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/fanf.c">fanf.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/fanf.orig.c">fanf.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/fanf.lambda">fanf.lambda</a> - lambda expressions</li>
|
||||
<li><a href="1998_fanf.tar.bz2">1998_fanf.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/.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/1998/fanf/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/.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/1998/fanf/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/fanf/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+76
-101
@@ -123,19 +123,16 @@
|
||||
<!-- END: this line ends content from: inc/before-content.default.html -->
|
||||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
|
||||
<h1 id="fourteenth-international-obfuscated-c-code-contest">Fourteenth
|
||||
International Obfuscated C Code Contest</h1>
|
||||
<h1 id="fourteenth-international-obfuscated-c-code-contest">Fourteenth International Obfuscated C Code Contest</h1>
|
||||
<h2 id="standard-ioccc-stuff">Standard IOCCC stuff</h2>
|
||||
<p>View the <code>index.html</code> web page for the given winning entry
|
||||
for information on how on how to compile it and how to run the winning
|
||||
program. Look at the winning source and try to figure how it does what
|
||||
it does! You may then wish to look at the Author’s remarks for even more
|
||||
details.</p>
|
||||
<p>The IOCCC has its own domain. The IOCCC has an official home page: <a
|
||||
href="https://www.ioccc.org">www.ioccc.org</a>.</p>
|
||||
<p>Use <code>make</code> to compile entries. It is possible that on BSD
|
||||
or non-Unix systems the Makefile needs to be changed. See the Makefile
|
||||
for details.</p>
|
||||
<p>View the <code>index.html</code> web page for the given winning entry for information on how
|
||||
on how to compile it and how to run the winning program.
|
||||
Look at the winning source and try to figure how it does what it does!
|
||||
You may then wish to look at the Author’s remarks for even more details.</p>
|
||||
<p>The IOCCC has its own domain. The IOCCC has an official home page:
|
||||
<a href="https://www.ioccc.org">www.ioccc.org</a>.</p>
|
||||
<p>Use <code>make</code> to compile entries. It is possible that on BSD or non-Unix
|
||||
systems the Makefile needs to be changed. See the Makefile for details.</p>
|
||||
<p>Read over the Makefile for compile/build issues. Your system may
|
||||
require certain changes (add or remove a library, add or remove a
|
||||
<code>#define</code> i.e. the <code>-D</code> flag).</p>
|
||||
@@ -143,134 +140,112 @@ require certain changes (add or remove a library, add or remove a
|
||||
yours is lacking, you may need to compile using gcc instead of your
|
||||
local compiler.</p>
|
||||
<h2 id="new-judges">New Judges</h2>
|
||||
<p>Larry Bassel is now a graduate student in number theory at UC San
|
||||
Diego. Barbara Frezza also went to San Diego to enter into law school at
|
||||
the same time. Her cooking in the role of official chef was sorely
|
||||
missed. Both Larry and Barbara have taken important new steps in their
|
||||
lives. We wish them the best.</p>
|
||||
<p>Landon was unable to contact Sriram Srinivasan at the start of the
|
||||
1998 IOCCC season. Having not heard from Sriram, Landon put out a call
|
||||
for new IOCCC judges. A number of excellent people applied.</p>
|
||||
<p>Landon selected Leonid A. Broukhis, a two time IOCCC winning author,
|
||||
as a co-judge. Landon and Leo together selected Jeremy Horn and Peter
|
||||
Seebach. The four <a href="https://www.ioccc.org/judges.html">judges</a>
|
||||
together worked thru-out the 1998 IOCCC season.</p>
|
||||
<p>Larry Bassel is now a graduate student in number theory at UC San Diego.
|
||||
Barbara Frezza also went to San Diego to enter into law school at the
|
||||
same time. Her cooking in the role of official chef was sorely missed.
|
||||
Both Larry and Barbara have taken important new steps in their lives.
|
||||
We wish them the best.</p>
|
||||
<p>Landon was unable to contact Sriram Srinivasan at the start of
|
||||
the 1998 IOCCC season. Having not heard from Sriram, Landon put out
|
||||
a call for new IOCCC judges. A number of excellent people applied.</p>
|
||||
<p>Landon selected Leonid A. Broukhis, a two time IOCCC winning author, as a
|
||||
co-judge. Landon and Leo together selected Jeremy Horn and Peter
|
||||
Seebach. The four <a href="https://www.ioccc.org/judges.html">judges</a> together worked
|
||||
thru-out the 1998 IOCCC season.</p>
|
||||
<h3 id="note-about-judges">2023 note about judges:</h3>
|
||||
<p>The number of judges now is only 2, Landon Curt Noll and Leonid A.
|
||||
Broukhis.</p>
|
||||
<h2 id="remarks-on-some-of-the-entries">Remarks on some of the
|
||||
entries</h2>
|
||||
<p>This year, <a
|
||||
href="https://www.ioccc.org/authors.html#Jens_Schweikhardt">Jens
|
||||
Schweikhardt</a> won 3 times … AGAIN! He is the only person who was able
|
||||
to do this, let alone do it in two contests in a row. <a
|
||||
href="https://www.ioccc.org/authors.html#Bas_de_Bakker">Bas de
|
||||
Bakker</a> and <a
|
||||
href="https://www.ioccc.org/authors.html#J_David_Lowe">David Lowe</a>
|
||||
won twice this year as well.</p>
|
||||
<p>As we stated in the <a href="guidelines.txt">guidelines</a>, the
|
||||
authors of the winning entries are as much news to us as they are to you
|
||||
because we keep authorship separate from rest of the entry. Some people
|
||||
have it, we guess!</p>
|
||||
<p>The number of judges now is only 2, Landon Curt Noll and Leonid A. Broukhis.</p>
|
||||
<h2 id="remarks-on-some-of-the-entries">Remarks on some of the entries</h2>
|
||||
<p>This year, <a href="https://www.ioccc.org/authors.html#Jens_Schweikhardt">Jens
|
||||
Schweikhardt</a> won 3 times
|
||||
… AGAIN! He is the only person who was able to do this, let alone do it in
|
||||
two contests in a row. <a href="https://www.ioccc.org/authors.html#Bas_de_Bakker">Bas de
|
||||
Bakker</a> and <a href="https://www.ioccc.org/authors.html#J_David_Lowe">David
|
||||
Lowe</a> won twice this year as
|
||||
well.</p>
|
||||
<p>As we stated in the <a href="guidelines.txt">guidelines</a>, the authors of the winning entries are
|
||||
as much news to us as they are to you because we keep authorship separate from
|
||||
rest of the entry. Some people have it, we guess!</p>
|
||||
<p>There were a few very good entries that might have won if it were not
|
||||
for the fact that they didn’t work. If you didn’t win, but think you had
|
||||
a chance: test your program, fix it and submit it next year!</p>
|
||||
for the fact that they didn’t work. If you didn’t win, but think you
|
||||
had a chance: test your program, fix it and submit it next year!</p>
|
||||
<p>This year we awarded some outstanding entries. We recommend that you
|
||||
look at all of the winning entries. The list of winning entries is a bit
|
||||
too long to say something about every entry. On the other hand a partial
|
||||
mention of a few is in order:</p>
|
||||
look at all of the winning entries. The list of winning entries is a bit too long to
|
||||
say something about every entry. On the other hand a partial mention
|
||||
of a few is in order:</p>
|
||||
<ul>
|
||||
<li>Audiences were very impressed with the Best of Show entry.</li>
|
||||
<li>The judges were amused that for the first time we received an entry
|
||||
that caused gcc to give the assembler bad input in some cases.</li>
|
||||
<li>The poot entries got a good laugh from the USENIX IOCCC BOF (Birds
|
||||
Of a Feather) crowd.</li>
|
||||
<li>The poot entries got a good laugh from the USENIX IOCCC BOF (Birds Of a Feather) crowd.</li>
|
||||
<li>Those with Functional Programming knowledge as well as those
|
||||
impressed with CPP code expansion liked the entry that translated lambda
|
||||
expressions into combinator expressions.</li>
|
||||
impressed with CPP code expansion liked the entry that translated
|
||||
lambda expressions into combinator expressions.</li>
|
||||
<li>Logic minded folks will get somewhat twisted up while following the
|
||||
flow of the <a href="schnitzi/index.html">Best Flow Control
|
||||
entry</a>.</li>
|
||||
<li>Those who know the PostScript language will be ‘bemused’ by the <a
|
||||
href="bas1/index.html">Best Encapsulation entry</a>.</li>
|
||||
flow of the <a href="schnitzi/index.html">Best Flow Control entry</a>.</li>
|
||||
<li>Those who know the PostScript language will be ‘bemused’ by
|
||||
the <a href="bas1/index.html">Best Encapsulation entry</a>.</li>
|
||||
</ul>
|
||||
<p>There were some outstanding entries that did not win. Unfortunately
|
||||
some very good entries lost because they:</p>
|
||||
<ul>
|
||||
<li>depended too much on non-portable side effects in expressions;</li>
|
||||
<li>depended too much on a particular byte order;</li>
|
||||
<li>required the use of a special script, data file or pseudo-machine
|
||||
language that was not supplied with the entry.</li>
|
||||
<li>required the use of a special script, data file or pseudo-machine language
|
||||
that was not supplied with the entry.</li>
|
||||
</ul>
|
||||
<p>We hope the authors of some of those entries will fix and re-submit
|
||||
them for the next IOCCC.</p>
|
||||
<h2 id="there-was-no-1997-contest">There was no 1997 contest</h2>
|
||||
<p>So what happened to 1997? There was no summer USENIX Technical
|
||||
Conference. The Technical Conference was held Jun 15-19, 1998 instead …
|
||||
18 months later than the 1996 summer USENIX Technical Conference. In
|
||||
addition we had to select some new IOCCC judges. As a result the IOCCC
|
||||
Conference. The Technical Conference was held Jun 15-19, 1998 instead
|
||||
… 18 months later than the 1996 summer USENIX Technical Conference.
|
||||
In addition we had to select some new IOCCC judges. As a result the IOCCC
|
||||
skipped over 1997.</p>
|
||||
<h2 id="final-comments">Final Comments</h2>
|
||||
<p>Please send us comments and suggestions what we have expressed above.
|
||||
Also include anything else that you would like to see in future
|
||||
contests. Send such email to:</p>
|
||||
Also include anything else that you would like to see in future contests.
|
||||
Send such email to:</p>
|
||||
<pre><code>questions@ioccc.org</code></pre>
|
||||
<p><strong>IMPORTANT NOTE</strong>: The email addresses found above are
|
||||
for historical purposes only, and should not be used today. See <a
|
||||
href="../contact.html">contact.html</a> for up to date contact details
|
||||
as well as details on how to provide fixes to any of the entries. See
|
||||
also <a href="../faq.html">the IOCCC FAQ</a> for addition information on
|
||||
the IOCCC.</p>
|
||||
<p>If you use, distribute or publish these entries in some way, please
|
||||
drop us a line. We enjoy seeing who, where and how the contest is
|
||||
used.</p>
|
||||
<p>You must include the words ‘ioccc question’ in the subject of your
|
||||
email message when sending email to the judges.</p>
|
||||
<p>The next IOCCC is planned to start towards the end of 1999. Watch <a
|
||||
href="https://www.ioccc.org">www.ioccc.org</a> for news of the next
|
||||
contest.</p>
|
||||
<p><strong>IMPORTANT NOTE</strong>: The email addresses found above are for historical
|
||||
purposes only, and should not be used today. See
|
||||
<a href="../contact.html">contact.html</a> for up to date contact details
|
||||
as well as details on how to provide fixes to any of the entries.
|
||||
See also <a href="../faq.html">the IOCCC FAQ</a> for addition information on the IOCCC.</p>
|
||||
<p>If you use, distribute or publish these entries in some way, please drop
|
||||
us a line. We enjoy seeing who, where and how the contest is used.</p>
|
||||
<p>You must include the words ‘ioccc question’ in the subject of your email
|
||||
message when sending email to the judges.</p>
|
||||
<p>The next IOCCC is planned to start towards the end of 1999. Watch
|
||||
<a href="https://www.ioccc.org">www.ioccc.org</a> for news of the next contest.</p>
|
||||
<h1 id="copyright-and-license">Copyright and License</h1>
|
||||
<p>Copyright (c) 1999,2023, Landon Curt Noll, Jeremy Horn, Peter Seebach
|
||||
and Leonid A. Broukhis. All Rights Reserved. This work is licensed under
|
||||
a <a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative
|
||||
Commons CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International</a>
|
||||
license. If you do use this work in some form, the <a
|
||||
href="../judges.html">IOCCC judges</a> would appreciate (but does not
|
||||
require) if you were to <a href="../contact.html">send us a note about
|
||||
your use</a>.</p>
|
||||
<p>Copyright (c) 1999,2023, Landon Curt Noll, Jeremy Horn, Peter Seebach and Leonid A. Broukhis. All Rights Reserved.
|
||||
This work is licensed under a <a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons CC BY-SA 4.0 DEED Attribution-ShareAlike
|
||||
4.0 International</a> license.
|
||||
If you do use this work in some form, the <a href="../judges.html">IOCCC judges</a> would appreciate
|
||||
(but does not require) if you were to <a href="../contact.html">send us a note about your use</a>.</p>
|
||||
|
||||
<!-- 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-year-index.sh via bin/md2html.sh -->
|
||||
|
||||
<!-- START: this line starts content generated by: bin/output-year-index.sh -->
|
||||
|
||||
<h1
|
||||
id="winning-entries-of-1998---the-14th-ioccc"><a name=inventory></a><a name=1998></a>Winning
|
||||
Entries of 1998 - The 14th IOCCC</h1>
|
||||
<p><strong>Download IOCCC</strong> <a
|
||||
href="1998/ioccc.1998.tar.bz2">1998 entry source</a></p>
|
||||
<h1 id="winning-entries-of-1998---the-14th-ioccc"><a name=inventory></a><a name=1998></a>Winning Entries of 1998 - The 14th IOCCC</h1>
|
||||
<p><strong>Download IOCCC</strong> <a href="1998/ioccc.1998.tar.bz2">1998 entry source</a></p>
|
||||
<ul>
|
||||
<li><a href="banks/index.html">1998/banks</a> - Best of Show</li>
|
||||
<li><a href="bas1/index.html">1998/bas1</a> - Best Encapsulation</li>
|
||||
<li><a href="bas2/index.html">1998/bas2</a> - Best Small Program</li>
|
||||
<li><a href="chaos/index.html">1998/chaos</a> - Best Object
|
||||
Orientation</li>
|
||||
<li><a href="chaos/index.html">1998/chaos</a> - Best Object Orientation</li>
|
||||
<li><a href="df/index.html">1998/df</a> - Best Data Hiding</li>
|
||||
<li><a href="dlowe/index.html">1998/dlowe</a> - Best Utility</li>
|
||||
<li><a href="dloweneil/index.html">1998/dloweneil</a> - Most Fun</li>
|
||||
<li><a href="dorssel/index.html">1998/dorssel</a> - Obsolescent
|
||||
Feature</li>
|
||||
<li><a href="fanf/index.html">1998/fanf</a> - Most Obfuscated
|
||||
Translator</li>
|
||||
<li><a href="schnitzi/index.html">1998/schnitzi</a> - Best Flow
|
||||
Control</li>
|
||||
<li><a href="dorssel/index.html">1998/dorssel</a> - Obsolescent Feature</li>
|
||||
<li><a href="fanf/index.html">1998/fanf</a> - Most Obfuscated Translator</li>
|
||||
<li><a href="schnitzi/index.html">1998/schnitzi</a> - Best Flow Control</li>
|
||||
<li><a href="schweikh1/index.html">1998/schweikh1</a> - CPP Abuse</li>
|
||||
<li><a href="schweikh2/index.html">1998/schweikh2</a> - Most Erratic
|
||||
Behavior</li>
|
||||
<li><a href="schweikh3/index.html">1998/schweikh3</a> - Most Space
|
||||
Efficient</li>
|
||||
<li><a href="tomtorfs/index.html">1998/tomtorfs</a> - Best
|
||||
Self-Documenting</li>
|
||||
<li><a href="schweikh2/index.html">1998/schweikh2</a> - Most Erratic Behavior</li>
|
||||
<li><a href="schweikh3/index.html">1998/schweikh3</a> - Most Space Efficient</li>
|
||||
<li><a href="tomtorfs/index.html">1998/tomtorfs</a> - Best Self-Documenting</li>
|
||||
</ul>
|
||||
<p> <strong>Jump to:</strong> <a href="#">top</a></p>
|
||||
|
||||
|
||||
+59
-87
@@ -129,9 +129,9 @@
|
||||
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Mark_Schnitzius">Mark
|
||||
Schnitzius</a><br> Location: <a href="../../location.html#ZZ">ZZ</a> -
|
||||
<em>Unknown location</em> <br><br></li>
|
||||
<li>Name: <a href="../../authors.html#Mark_Schnitzius">Mark Schnitzius</a><br>
|
||||
Location: <a href="../../location.html#ZZ">ZZ</a> - <em>Unknown location</em>
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -144,8 +144,7 @@ Schnitzius</a><br> Location: <a href="../../location.html#ZZ">ZZ</a> -
|
||||
<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#1998_schnitzi">1998 schnitzi bugs</a>.</p>
|
||||
<p>For more detailed information see <a href="../../bugs.html#1998_schnitzi">1998 schnitzi bugs</a>.</p>
|
||||
<h2 id="to-use">To use:</h2>
|
||||
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./schnitzi</span> n <span class="op">></span> sort.c</span>
|
||||
<span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> sort</span>
|
||||
@@ -153,12 +152,11 @@ href="../../bugs.html#1998_schnitzi">1998 schnitzi bugs</a>.</p>
|
||||
<span id="cb3-4"><a href="#cb3-4" aria-hidden="true" tabindex="-1"></a><span class="co"># enter three numbers, space separated</span></span>
|
||||
<span id="cb3-5"><a href="#cb3-5" aria-hidden="true" tabindex="-1"></a></span>
|
||||
<span id="cb3-6"><a href="#cb3-6" aria-hidden="true" tabindex="-1"></a><span class="bu">echo</span> x y z <span class="kw">|</span> <span class="ex">./sort</span></span></code></pre></div>
|
||||
<p>where <code>n</code> and <code>x</code>, <code>y</code> and
|
||||
<code>z</code> are numbers.</p>
|
||||
<p>where <code>n</code> and <code>x</code>, <code>y</code> and <code>z</code> are numbers.</p>
|
||||
<h2 id="try">Try:</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">./try.sh</span></span></code></pre></div>
|
||||
<p>What happens if at the command line you don’t specify <code>n</code>
|
||||
numbers that the program expects? For instance try:</p>
|
||||
<p>What happens if at the command line you don’t specify <code>n</code> numbers that the
|
||||
program expects? For instance try:</p>
|
||||
<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">./schnitzi</span> 5 <span class="op">></span> sort.c</span>
|
||||
<span id="cb5-2"><a href="#cb5-2" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> sort</span>
|
||||
<span id="cb5-3"><a href="#cb5-3" aria-hidden="true" tabindex="-1"></a></span>
|
||||
@@ -166,111 +164,85 @@ numbers that the program expects? For instance try:</p>
|
||||
<span id="cb5-5"><a href="#cb5-5" aria-hidden="true" tabindex="-1"></a><span class="bu">echo</span> 2 5 3 1 <span class="kw">|</span> <span class="ex">./sort</span></span></code></pre></div>
|
||||
<p>Why does this happen?</p>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>This is a beautiful program. How can a program with no conditional
|
||||
(except for the fixes for modern systems) behavior at all have output
|
||||
which depends on anything?</p>
|
||||
<p>This is a beautiful program. How can a program with no conditional (except for
|
||||
the fixes for modern systems) behavior at all have output which
|
||||
depends on anything?</p>
|
||||
<p>For hints on deciphering this, see below past the Author’s remarks;
|
||||
they’re a nice summary, but they leave the mystery intact.</p>
|
||||
<p>BTW: the author notes an incredible lipogram story called <a
|
||||
href="https://www.gutenberg.org/cache/epub/47342/pg47342.txt">Gadsby</a>
|
||||
which has no letter E in the story. He did not note this but it has over
|
||||
50000 (50 thousand) (!!) words without the letter E which is one of the
|
||||
most common letters!</p>
|
||||
<p>BTW: the author notes an incredible lipogram story called
|
||||
<a href="https://www.gutenberg.org/cache/epub/47342/pg47342.txt">Gadsby</a> which has no
|
||||
letter E in the story. He did not note this but it has over 50000 (50 thousand)
|
||||
(!!) words without the letter E which is one of the most common letters!</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<p>In literary circles, there is a poetic form called a “lipogram”,
|
||||
which is a poem in which a specific letter has been distinctly avoided.
|
||||
This principle can be applied in other ways. For instance, in this
|
||||
paragraph, the vowel which immediately follows <code>t</code> in the
|
||||
alphabet is nowhere to be seen. There is even an entire novel (E. V.
|
||||
Wright’s “Gadsby”) in which no word contains the letter
|
||||
<code>e</code>.</p>
|
||||
<p>The IOCCC has been no stranger to this concept. Several winning
|
||||
entries from years past have accomplished interesting feats while
|
||||
completely avoiding the use of certain C constructs thought to be
|
||||
essential (e.g. <a
|
||||
href="../../1988/robison/robison.c">1988/robison.c</a>). If you have to
|
||||
ask why they would do it this way, then this contest just isn’t for
|
||||
you.</p>
|
||||
<p>In continuing with this fine tradition, this program suggests to the
|
||||
ANSI committee some new practical simplifications for the C language.
|
||||
For instance, it appears that CONDITIONAL BRANCHING isn’t really
|
||||
necessary. So, we can do away with <code>while</code>,
|
||||
<code>do...while</code>, <code>for</code>,
|
||||
<code>if</code>/<code>else</code>, <code>switch</code>, <code>?:</code>,
|
||||
or anything else that might cause any kind of non-deterministic jump in
|
||||
the code. There’s too much uncertainty in the world anyway.</p>
|
||||
which is a poem in which a specific letter has been distinctly
|
||||
avoided. This principle can be applied in other ways. For
|
||||
instance, in this paragraph, the vowel which immediately follows
|
||||
<code>t</code> in the alphabet is nowhere to be seen. There is even an
|
||||
entire novel (E. V. Wright’s “Gadsby”) in which no word contains
|
||||
the letter <code>e</code>.</p>
|
||||
<p>The IOCCC has been no stranger to this concept. Several winning entries from
|
||||
years past have accomplished interesting feats while completely avoiding the use
|
||||
of certain C constructs thought to be essential (e.g.
|
||||
<a href="../../1988/robison/robison.c">1988/robison.c</a>). If you have to ask why they would
|
||||
do it this way, then this contest just isn’t for you.</p>
|
||||
<p>In continuing with this fine tradition, this program suggests to the ANSI
|
||||
committee some new practical simplifications for the C language. For instance,
|
||||
it appears that CONDITIONAL BRANCHING isn’t really necessary. So, we can do
|
||||
away with <code>while</code>, <code>do...while</code>, <code>for</code>, <code>if</code>/<code>else</code>, <code>switch</code>, <code>?:</code>, or anything
|
||||
else that might cause any kind of non-deterministic jump in the code. There’s
|
||||
too much uncertainty in the world anyway.</p>
|
||||
<p>Function parameters and return types just confuse people anyway, so
|
||||
get rid of them. Same with local variables. In fact, all you really need
|
||||
are assignment statements, and maybe one <code>printf(3)</code> and one
|
||||
<code>goto</code>.</p>
|
||||
get rid of them. Same with local variables. In fact, all you really
|
||||
need are assignment statements, and maybe one <code>printf(3)</code> and one <code>goto</code>.</p>
|
||||
<p>This style of programming is also ideal for systems with limited
|
||||
memory capacity, since the function call stack never goes beyond a depth
|
||||
of one.</p>
|
||||
<p>So what does it do? Give it an integer
|
||||
<code>(1 < n < 27)</code> on the command line, such as</p>
|
||||
memory capacity, since the function call stack never goes beyond
|
||||
a depth of one.</p>
|
||||
<p>So what does it do? Give it an integer <code>(1 < n < 27)</code> on the command
|
||||
line, such as</p>
|
||||
<div class="sourceCode" id="cb6"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./schnitzi</span> 5</span></code></pre></div>
|
||||
<p>The output will itself be a lipographic program, one which expects
|
||||
input of (in this case) five numbers and prints them out sorted. It
|
||||
sorts them, however, using only <code>if/else</code> statements, without
|
||||
arrays or looping. To see the resulting program run, redirect the output
|
||||
from <code>schnitzi</code> into another file, like this</p>
|
||||
<p>The output will itself be a lipographic program, one which expects input of
|
||||
(in this case) five numbers and prints them out sorted. It sorts
|
||||
them, however, using only <code>if/else</code> statements, without arrays or
|
||||
looping. To see the resulting program run, redirect the output from
|
||||
<code>schnitzi</code> into another file, like 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="ex">./schnitzi</span> 4 <span class="op">></span> sort.c</span></code></pre></div>
|
||||
<p>and then compile it.</p>
|
||||
<h3 id="spoilers-and-hints">Spoilers And Hints:</h3>
|
||||
<p>The big key to this program is figuring out what the names of the
|
||||
functions ought to be; a bit of research may allow you to guess at a few
|
||||
crucial ones.</p>
|
||||
<p>The only function ever called is <code>O</code>, but <code>O</code>
|
||||
is just set to point to other functions all the time. Or, almost all the
|
||||
time.</p>
|
||||
functions ought to be; a bit of research may allow you to guess at
|
||||
a few crucial ones.</p>
|
||||
<p>The only function ever called is <code>O</code>, but <code>O</code> is just set to point to
|
||||
other functions all the time. Or, almost all the time.</p>
|
||||
<p>So how does <code>h</code> get set, and what to?</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>
|
||||
<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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998schnitzi"><a name="inventory"></a>Inventory
|
||||
for 1998/schnitzi</h1>
|
||||
<h1 id="inventory-for-1998schnitzi"><a name="inventory"></a>Inventory for 1998/schnitzi</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schnitzi/schnitzi.c">schnitzi.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schnitzi/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schnitzi/schnitzi.orig.c">schnitzi.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schnitzi/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a href="1998_schnitzi.tar.bz2">1998_schnitzi.tar.bz2</a> - download
|
||||
entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schnitzi/schnitzi.c">schnitzi.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schnitzi/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schnitzi/schnitzi.orig.c">schnitzi.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schnitzi/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="1998_schnitzi.tar.bz2">1998_schnitzi.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schnitzi/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schnitzi/.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/1998/schnitzi/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schnitzi/.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/1998/schnitzi/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schnitzi/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+128
-173
@@ -129,9 +129,9 @@
|
||||
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Jens_Schweikhardt">Jens
|
||||
Schweikhardt</a><br> Location: <a href="../../location.html#DE">DE</a> -
|
||||
<em>Federal Republic of Germany</em> (<em>Germany</em>) <br><br></li>
|
||||
<li>Name: <a href="../../authors.html#Jens_Schweikhardt">Jens Schweikhardt</a><br>
|
||||
Location: <a href="../../location.html#DE">DE</a> - <em>Federal Republic of Germany</em> (<em>Germany</em>)
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -141,58 +141,55 @@ Schweikhardt</a><br> Location: <a href="../../location.html#DE">DE</a> -
|
||||
|
||||
<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> all</span></code></pre></div>
|
||||
<p>There is an alternate version of this entry that will work with
|
||||
macOS. See the <a href="#alternate-code">Alternate code</a> section
|
||||
below. We recommend you look at it even if you don’t have a Mac, unless
|
||||
you want to figure it out yourself, as it includes some interesting
|
||||
details about the entry.</p>
|
||||
<p>There is an alternate version of this entry that will work with macOS. See the
|
||||
<a href="#alternate-code">Alternate code</a> section below. We recommend you look at it
|
||||
even if you don’t have a Mac, unless you want to figure it out yourself, as it
|
||||
includes some interesting details about the entry.</p>
|
||||
<h2 id="to-use">To use:</h2>
|
||||
<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="ex">./schweikh1</span></span></code></pre></div>
|
||||
<h2 id="alternate-code">Alternate code:</h2>
|
||||
<p>As noted above this entry will not work as it stands for macOS and
|
||||
there are some important notes as well as a description of how the fixed
|
||||
version works (the details of which are relevant to the original entry
|
||||
that no longer works as well as the fixed version but are described in
|
||||
the context of the macOS adjustments). For details of what had to
|
||||
change, see <a href="macos.html">macos.html</a>. Unless you wish to
|
||||
figure it out yourself, we recommend that you read this even if you
|
||||
don’t have a Mac as it has some interesting details about the entry.</p>
|
||||
<p>As noted above this entry will not work as it stands for macOS and there are
|
||||
some important notes as well as a description of how the fixed version works
|
||||
(the details of which are relevant to the original entry that no longer works as
|
||||
well as the fixed version but are described in the context of the macOS
|
||||
adjustments). For details of what had to change, see <a href="macos.html">macos.html</a>.
|
||||
Unless you wish to figure it out yourself, we recommend that you read this even
|
||||
if you don’t have a Mac as it has some interesting details about the entry.</p>
|
||||
<h3 id="alternate-build">Alternate build:</h3>
|
||||
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="fu">make</span> alt</span></code></pre></div>
|
||||
<h3 id="alternate-build-1">Alternate build:</h3>
|
||||
<p>Use <code>schweikh1.alt</code> as you would <code>schweikh1</code>
|
||||
above.</p>
|
||||
<p>Use <code>schweikh1.alt</code> as you would <code>schweikh1</code> above.</p>
|
||||
<h3 id="alternate-try">Alternate try:</h3>
|
||||
<p>Bonus exercise: modify the code to provide a different compiler.</p>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>What does it do? It seems to print a list of system headers, perhaps
|
||||
with words after them. Curiously, if you look at the list of words
|
||||
defined in a given standard header, they are never printed directly
|
||||
after that header’s name. Aha! It’s a conformance test for the standard
|
||||
headers.</p>
|
||||
after that header’s name. Aha! It’s a conformance test for the
|
||||
standard headers.</p>
|
||||
<p>This code is a wonder; it’s a wonder that it compiles. I wonder
|
||||
whether or not it should. The innovative realization that you can use
|
||||
special characters, such as <code>'\n'</code>, in <code>#file</code>
|
||||
directives alone merits some recognition.</p>
|
||||
whether or not it should. The innovative realization that you can
|
||||
use special characters, such as <code>'\n'</code>, in <code>#file</code> directives alone
|
||||
merits some recognition.</p>
|
||||
<p>I’ve included most of the author’s remarks; they’re fairly thorough.
|
||||
Do not read them if you want to figure this out yourself. “Amendment
|
||||
One” refers to “NA1”, the add-on to C89 which added some fairly crufty
|
||||
internationalization support.</p>
|
||||
One” refers to “NA1”, the add-on to C89 which added some fairly
|
||||
crufty internationalization support.</p>
|
||||
<h4 id="historical-note">Historical note:</h4>
|
||||
<p>Some non-gcc compilers that were not fully ANSI standard did not
|
||||
compile this entry correctly. Using cc by default was not helpful most
|
||||
of the time on this entry, because the program had a hardcoded gcc
|
||||
invocation anyway. Anyone who uses egcs and has no plain gcc will need
|
||||
to frob the source anyway and can be expected to do the right thing with
|
||||
<code>${CC}</code>. This limitation was removed in 2023 but in the past
|
||||
compile this entry correctly. Using cc by default was not helpful
|
||||
most of the time on this entry, because the program had a hardcoded
|
||||
gcc invocation anyway. Anyone who uses egcs and has no plain gcc
|
||||
will need to frob the source anyway and can be expected to do the
|
||||
right thing with <code>${CC}</code>. This limitation was removed in 2023 but in the past
|
||||
one should have used gcc.</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<p>Important! This program, if it compiles at all, is mis-compiled by
|
||||
many compilers due to compiler bugs. It could be the “least likely to
|
||||
compile and execute” in conjunction with preprocessor abuse. When run,
|
||||
it is likely to uncover bugs in your system headers.</p>
|
||||
<p>The program is run without arguments. If your compiler is buggy, the
|
||||
most likely result is no output and/or an exit status of 1.</p>
|
||||
<p>Important! This program, if it compiles at all, is mis-compiled by many
|
||||
compilers due to compiler bugs. It could be the “least likely
|
||||
to compile and execute” in conjunction with preprocessor abuse.
|
||||
When run, it is likely to uncover bugs in your system headers.</p>
|
||||
<p>The program is run without arguments. If your compiler is buggy,
|
||||
the most likely result is no output and/or an exit status of 1.</p>
|
||||
<p>If Amendment One headers are missing you will see something like:</p>
|
||||
<pre><code><iso646.h>:
|
||||
gcc: /usr/include/iso646.h: No such file or directory
|
||||
@@ -204,27 +201,24 @@ gcc: No input files specified
|
||||
gcc: /usr/include/wchar.h: No such file or directory
|
||||
gcc: No input files specified</code></pre>
|
||||
<p>Bug your vendor for an upgrade.</p>
|
||||
<p>The format of the info file is straightforward and described in the
|
||||
file itself. Just load it in your favorite editor.</p>
|
||||
<p>The format of the info file is straightforward and described in the file
|
||||
itself. Just load it in your favorite editor.</p>
|
||||
<h3 id="requirements">Requirements</h3>
|
||||
<p><code>gcc</code> (the GNU C compiler) must be available at runtime.
|
||||
It is assumed that your C implementation keeps headers as files in the
|
||||
<code>/usr/include</code> directory. The <a href="info">info</a> file
|
||||
must be readable and reside in the current working directory. The
|
||||
current working directory must be writable in order to create a
|
||||
temporary file (which is removed upon program termination). In case you
|
||||
don’t have gcc at runtime, not all is lost if your compiler or
|
||||
preprocessor can produce a list of defined macros in the format output
|
||||
by <code>gcc -dM</code>, i.e. lines of the form
|
||||
<p><code>gcc</code> (the GNU C compiler) must be available at runtime. It is assumed that your
|
||||
C implementation keeps headers as files in the <code>/usr/include</code> directory. The
|
||||
<a href="info">info</a> file must be readable and reside in the current working directory.
|
||||
The current working directory must be writable in order to create a temporary
|
||||
file (which is removed upon program termination). In case you don’t have gcc at
|
||||
runtime, not all is lost if your compiler or preprocessor can produce a list of
|
||||
defined macros in the format output by <code>gcc -dM</code>, i.e. lines of the form
|
||||
<code>#define MACRO value</code>.</p>
|
||||
<p>Edit the source at line 55 in this case.</p>
|
||||
<h3 id="background">Background</h3>
|
||||
<p>ISO C has a very strict idea of visibility of identifiers. All
|
||||
possible macros are explicitly enumerated. In a compliant implementation
|
||||
no other macros can be defined, because you could write strictly
|
||||
conforming programs that may fail to compile due to syntax errors:
|
||||
supposing that <code><stdio.h></code> defines
|
||||
<code>PIPE_BUF</code>, then the conforming</p>
|
||||
<p>ISO C has a very strict idea of visibility of identifiers. All possible
|
||||
macros are explicitly enumerated. In a compliant implementation no other
|
||||
macros can be defined, because you could write strictly conforming
|
||||
programs that may fail to compile due to syntax errors: supposing that
|
||||
<code><stdio.h></code> defines <code>PIPE_BUF</code>, then the conforming</p>
|
||||
<div class="sourceCode" id="cb5"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb5-1"><a href="#cb5-1" aria-hidden="true" tabindex="-1"></a><span class="pp">#include </span><span class="im"><assert.h></span></span>
|
||||
<span id="cb5-2"><a href="#cb5-2" aria-hidden="true" tabindex="-1"></a><span class="pp">#include </span><span class="im"><stdio.h></span><span class="pp"> </span><span class="co">/* <- or where the bogus macro is defined */</span></span>
|
||||
<span id="cb5-3"><a href="#cb5-3" aria-hidden="true" tabindex="-1"></a><span class="pp">#include </span><span class="im"><string.h></span></span>
|
||||
@@ -238,38 +232,36 @@ supposing that <code><stdio.h></code> defines
|
||||
<span id="cb5-11"><a href="#cb5-11" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
|
||||
<p>is expected to compile and meet the assertion. If it does not, your
|
||||
compiler compiles some other language than ISO C.</p>
|
||||
<h3 id="why-i-think-my-program-is-obfuscated">Why I think my program is
|
||||
obfuscated</h3>
|
||||
<h3 id="why-i-think-my-program-is-obfuscated">Why I think my program is obfuscated</h3>
|
||||
<p>Not only is the program’s purpose a thorough standard conformance
|
||||
test, the source itself is a beast and has uncovered bugs in many C
|
||||
compilers.</p>
|
||||
test, the source itself is a beast and has uncovered bugs in many
|
||||
C compilers.</p>
|
||||
<ol type="1">
|
||||
<li>The token sequence after <code>#include</code> can consist of
|
||||
pp-tokens and “are processed just as in normal text.” [ISO 6.8.2] The
|
||||
result must resemble one of the canonical forms, <code>"foo.h"</code> or
|
||||
<code><bar.h></code>. This lets us write things like</li>
|
||||
<li>The token sequence after <code>#include</code> can consist of pp-tokens and
|
||||
“are processed just as in normal text.” [ISO 6.8.2] The result
|
||||
must resemble one of the canonical forms, <code>"foo.h"</code> or <code><bar.h></code>.
|
||||
This lets us write things like</li>
|
||||
</ol>
|
||||
<div class="sourceCode" id="cb6"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="pp">#define HEADER </span><span class="st">"foo.h"</span></span>
|
||||
<span id="cb6-2"><a href="#cb6-2" aria-hidden="true" tabindex="-1"></a><span class="pp">#include HEADER</span></span></code></pre></div>
|
||||
<p>I could not find a compiler rejecting this. However, if we’re
|
||||
torturing the preprocessor a little more, by using token pasting, at
|
||||
least one compiler falls over.</p>
|
||||
torturing the preprocessor a little more, by using token pasting,
|
||||
at least one compiler falls over.</p>
|
||||
<div class="sourceCode" id="cb7"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb7-1"><a href="#cb7-1" aria-hidden="true" tabindex="-1"></a><span class="pp">#define H</span><span class="op">(</span><span class="pp">x</span><span class="op">)</span><span class="pp"> </span><span class="op"><</span><span class="pp">st</span><span class="op">##</span><span class="pp">x</span><span class="op">##.</span><span class="pp">h</span><span class="op">></span></span>
|
||||
<span id="cb7-2"><a href="#cb7-2" aria-hidden="true" tabindex="-1"></a><span class="pp">#include H(dio) </span><span class="co">/* expands to <stdio.h> */</span></span></code></pre></div>
|
||||
<p>is rejected by tcc version 4.1.2, the TenDRA compiler:
|
||||
<code>"t.c", line 3: Error:\ [ISO 6.8.3.3]: Invalid result for '##' operator in macro 'H'.</code></p>
|
||||
<p>To be honest, I don’t know if the rules for pp-tokens and token
|
||||
pasting don’t forbid what I do (and thus tcc is correct in rejecting
|
||||
it). In this case, all other compilers I tried are buggy, or the
|
||||
Standard itself :-)</p>
|
||||
pasting don’t forbid what I do (and thus tcc is correct in rejecting it).
|
||||
In this case, all other compilers I tried are buggy, or the Standard
|
||||
itself :-)</p>
|
||||
<ol start="2" type="1">
|
||||
<li>The <code>#line</code> directive allows to set a line number, and
|
||||
optionally a file name, i.e. modify <code>__LINE__</code> and
|
||||
<code>__FILE__</code>. Strange things happen if the file name contains a
|
||||
NUL byte – which the Standard allows: in <code>#line num "file"</code>
|
||||
the <code>"file"</code> is an s-char-sequence per ISO 6.8.4. ISO 6.1.4
|
||||
defines string literals as s-char-sequences, which may include octal
|
||||
escape sequences. Let’s look at</li>
|
||||
<li>The <code>#line</code> directive allows to set a line number, and optionally
|
||||
a file name, i.e. modify <code>__LINE__</code> and <code>__FILE__</code>. Strange things
|
||||
happen if the file name contains a NUL byte – which the Standard
|
||||
allows: in <code>#line num "file"</code> the <code>"file"</code> is an s-char-sequence per
|
||||
ISO 6.8.4. ISO 6.1.4 defines string literals as s-char-sequences,
|
||||
which may include octal escape sequences. Let’s look at</li>
|
||||
</ol>
|
||||
<div class="sourceCode" id="cb8"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb8-1"><a href="#cb8-1" aria-hidden="true" tabindex="-1"></a><span class="pp">#include </span><span class="im"><stdio.h></span></span>
|
||||
<span id="cb8-2"><a href="#cb8-2" aria-hidden="true" tabindex="-1"></a><span class="pp">#line 42 "foo\0bar"</span></span>
|
||||
@@ -277,22 +269,18 @@ escape sequences. Let’s look at</li>
|
||||
<span id="cb8-4"><a href="#cb8-4" aria-hidden="true" tabindex="-1"></a> printf <span class="op">(</span><span class="st">"</span><span class="sc">%s</span><span class="st"> </span><span class="sc">%d\n</span><span class="st">"</span><span class="op">,</span> __FILE__<span class="op">,</span> <span class="op">(</span><span class="dt">int</span><span class="op">)</span><span class="kw">sizeof</span> __FILE__<span class="op">);</span></span>
|
||||
<span id="cb8-5"><a href="#cb8-5" aria-hidden="true" tabindex="-1"></a> <span class="cf">return</span> <span class="dv">0</span><span class="op">;</span></span>
|
||||
<span id="cb8-6"><a href="#cb8-6" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
|
||||
<p>This is supposed to output <code>'foo 8'</code>. Here’s what happens
|
||||
in RL:</p>
|
||||
<p>This is supposed to output <code>'foo 8'</code>. Here’s what happens in RL:</p>
|
||||
<pre><code>foo 4 gcc 2.7.2.1, lcc
|
||||
foo\0bar 9 tcc 4.1.2, Sunsoft cc turn "\0" into "\\0", ugh!</code></pre>
|
||||
<p>(I have written a bug report for gcc. Newer versions and egcs are
|
||||
ok.)</p>
|
||||
<p>(I have written a bug report for gcc. Newer versions and egcs are ok.)</p>
|
||||
<ol start="3" type="1">
|
||||
<li><p>The <code>%:</code> and <code>%:%:</code> digraphs test for
|
||||
conformance to Amendment One.</p>
|
||||
<p>Ask your local guru if C allows the same case label in the same
|
||||
switch statement to appear more than once. Ask him/her to think real
|
||||
hard. The answer will be “no”. The true guru will cite a constraint in
|
||||
ISO 6.6.4.2. Then make fun of the guru’s answer by waving
|
||||
<code>case __LINE__:</code> under his/her nose. Easy money from a bet!
|
||||
Make sure your guru has no chance to use Standardese weasel words as an
|
||||
escape: can I have</p></li>
|
||||
<li><p>The <code>%:</code> and <code>%:%:</code> digraphs test for conformance to Amendment One.</p>
|
||||
<p>Ask your local guru if C allows the same case label in the same switch
|
||||
statement to appear more than once. Ask him/her to think real hard.
|
||||
The answer will be “no”. The true guru will cite a constraint in
|
||||
ISO 6.6.4.2. Then make fun of the guru’s answer by waving <code>case __LINE__:</code>
|
||||
under his/her nose. Easy money from a bet! Make sure your guru has
|
||||
no chance to use Standardese weasel words as an escape: can I have</p></li>
|
||||
</ol>
|
||||
<div class="sourceCode" id="cb10"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb10-1"><a href="#cb10-1" aria-hidden="true" tabindex="-1"></a> <span class="cf">case</span> <span class="op"><</span>some_token<span class="op">>:</span></span>
|
||||
<span id="cb10-2"><a href="#cb10-2" aria-hidden="true" tabindex="-1"></a> <span class="cf">case</span> <span class="op"><</span>some_token<span class="op">>:</span></span></code></pre></div>
|
||||
@@ -300,116 +288,83 @@ escape: can I have</p></li>
|
||||
can generously allow the additional constraint that no `#undef`s or
|
||||
`#define`s are allowed between the two cases.)</code></pre>
|
||||
<p>Lots of integer constants and string literals come into the source
|
||||
via <code>__LINE__</code> and <code>__FILE__</code> which are redefined
|
||||
at various places. Sometimes the <code>__FILE__</code> contains
|
||||
<code>\0</code> bytes; different strings or characters are then accessed
|
||||
with offsets, say <code>10+__FILE__</code> or
|
||||
<code>__LINE__+__FILE__</code> or <code>2[__FILE__]</code>. One integral
|
||||
constant in octal. This makes the source and header input depend on
|
||||
ASCII.</p>
|
||||
<p>A few old obfuscations, like one character identifiers, not too many
|
||||
macros, a <code>goto O</code>, “needless” assignments to satisfy lint
|
||||
with its “function value ignored” warnings. My lint has nothing to
|
||||
complain about.</p>
|
||||
<p>There’s more whitespace in the Standard than just space, tab and
|
||||
newline. In particular, there are vertical tab and form-feed that can be
|
||||
used in certain places (outside of preprocessing directives, i.e. they
|
||||
are not allowed from just after the <code>#</code> up to the final
|
||||
newline. See 6.8 for details.) On many implementations these appear as
|
||||
<code>^L</code> and <code>^K</code>. My source starts with an extremely
|
||||
uncommon 32bit word consisting of <code>^L</code>, <code>^K</code>,
|
||||
<code>%</code> and <code>:</code>. I have grepped old winning entries
|
||||
for ^K, none of them contains one, so this is something new – after 14
|
||||
years of IOCCC. Be sure to have enough paper in your printer when you
|
||||
make a hard copy of the source…</p>
|
||||
<p>While I’m at it, the rules state that only space, tab and newline are
|
||||
ignored for the count (plus ‘<code>{</code>’, ‘<code>}</code>’,
|
||||
‘<code>;</code>’ followed by whitespace). The <a
|
||||
href="../mkentry.c">mkentry.c</a> program, however, uses
|
||||
<code>isspace(3)</code> which returns nonzero for <code>\v</code> and
|
||||
<code>\f</code> and other characters as well. I could have used a lot
|
||||
more <code>^K</code> and <code>^L</code> probably undetected by your
|
||||
counter but decided to err on the side of safety. I use a perl script to
|
||||
compute the character count according to the rules. The advantages of an
|
||||
independent clean room approach…</p>
|
||||
<div class="sourceCode" id="cb12"><pre
|
||||
class="sourceCode perl"><code class="sourceCode perl"><span id="cb12-1"><a href="#cb12-1" aria-hidden="true" tabindex="-1"></a><span class="kw">#!/usr/bin/perl -w</span></span>
|
||||
via <code>__LINE__</code> and <code>__FILE__</code> which are redefined at various places.
|
||||
Sometimes the <code>__FILE__</code> contains <code>\0</code> bytes; different strings or
|
||||
characters are then accessed with offsets, say <code>10+__FILE__</code> or
|
||||
<code>__LINE__+__FILE__</code> or <code>2[__FILE__]</code>. One integral constant in octal.
|
||||
This makes the source and header input depend on ASCII.</p>
|
||||
<p>A few old obfuscations, like one character identifiers, not too
|
||||
many macros, a <code>goto O</code>, “needless” assignments to satisfy lint
|
||||
with its “function value ignored” warnings. My lint has nothing
|
||||
to complain about.</p>
|
||||
<p>There’s more whitespace in the Standard than just space, tab and newline. In
|
||||
particular, there are vertical tab and form-feed that can be used in certain
|
||||
places (outside of preprocessing directives, i.e. they are not allowed from just
|
||||
after the <code>#</code> up to the final newline. See 6.8 for details.) On many
|
||||
implementations these appear as <code>^L</code> and <code>^K</code>. My source starts with an
|
||||
extremely uncommon 32bit word consisting of <code>^L</code>, <code>^K</code>, <code>%</code> and <code>:</code>. I have
|
||||
grepped old winning entries for ^K, none of them contains one, so this is
|
||||
something new – after 14 years of IOCCC. Be sure to have enough paper in your
|
||||
printer when you make a hard copy of the source…</p>
|
||||
<p>While I’m at it, the rules state that only space, tab and newline
|
||||
are ignored for the count (plus ‘<code>{</code>’, ‘<code>}</code>’, ‘<code>;</code>’ followed by
|
||||
whitespace). The <a href="../mkentry.c">mkentry.c</a> program, however, uses <code>isspace(3)</code> which
|
||||
returns nonzero for <code>\v</code> and <code>\f</code> and other characters as well.
|
||||
I could have used a lot more <code>^K</code> and <code>^L</code> probably undetected by your
|
||||
counter but decided to err on the side of safety. I use a perl
|
||||
script to compute the character count according to the rules.
|
||||
The advantages of an independent clean room approach…</p>
|
||||
<div class="sourceCode" id="cb12"><pre class="sourceCode perl"><code class="sourceCode perl"><span id="cb12-1"><a href="#cb12-1" aria-hidden="true" tabindex="-1"></a><span class="kw">#!/usr/bin/perl -w</span></span>
|
||||
<span id="cb12-2"><a href="#cb12-2" aria-hidden="true" tabindex="-1"></a><span class="wa">$/</span> = <span class="ot">"</span><span class="st">\0</span><span class="ot">"</span>;</span>
|
||||
<span id="cb12-3"><a href="#cb12-3" aria-hidden="true" tabindex="-1"></a><span class="wa">$_</span> = <>;</span>
|
||||
<span id="cb12-4"><a href="#cb12-4" aria-hidden="true" tabindex="-1"></a><span class="ot">s/</span><span class="ch">[</span><span class="bn">;{}</span><span class="ch">][</span><span class="bn"> \t\n</span><span class="ch">]</span><span class="ot">/</span><span class="ch">\n</span><span class="ot">/g</span>;</span>
|
||||
<span id="cb12-5"><a href="#cb12-5" aria-hidden="true" tabindex="-1"></a><span class="ot">s/</span><span class="ch">[</span><span class="bn"> \t\n</span><span class="ch">]+</span><span class="ot">//g</span>;</span>
|
||||
<span id="cb12-6"><a href="#cb12-6" aria-hidden="true" tabindex="-1"></a><span class="fu">print</span> <span class="fu">length</span> (<span class="wa">$_</span>),<span class="ot">"</span><span class="ch">\n</span><span class="ot">"</span>;</span></code></pre></div>
|
||||
<p>To use, try:</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="fu">perl</span> ./charcount.pl schweikh1.c</span></code></pre></div>
|
||||
<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="fu">perl</span> ./charcount.pl schweikh1.c</span></code></pre></div>
|
||||
<p>I have tried, as suggested in the guidelines, to let the code look
|
||||
like ordinary C code. Apart from a few long lines I think I left the
|
||||
indentation like I would in RL. You should however not try to use
|
||||
<code>indent</code> on the source. The code is extremely fragile because
|
||||
of the myriads of <code>__LINE__</code> macros – indenting is a sure way
|
||||
to break the program. Don’t even think of maintaining that beast; I’ve
|
||||
had my share of core dumps during development :-) A test suite was used
|
||||
after every minor change to find out if the program still does what it
|
||||
should.</p>
|
||||
<p>From the goals: “To stress C compilers with unusual code.” That
|
||||
describes exactly my modest attempts…</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>
|
||||
like ordinary C code. Apart from a few long lines I think I left
|
||||
the indentation like I would in RL. You should however not try to
|
||||
use <code>indent</code> on the source. The code is extremely fragile because of the
|
||||
myriads of <code>__LINE__</code> macros – indenting is a sure way to break
|
||||
the program. Don’t even think of maintaining that beast; I’ve
|
||||
had my share of core dumps during development :-) A test suite
|
||||
was used after every minor change to find out if the program still
|
||||
does what it should.</p>
|
||||
<p>From the goals: “To stress C compilers with unusual code.”
|
||||
That describes exactly my modest attempts…</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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998schweikh1"><a name="inventory"></a>Inventory
|
||||
for 1998/schweikh1</h1>
|
||||
<h1 id="inventory-for-1998schweikh1"><a name="inventory"></a>Inventory for 1998/schweikh1</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/schweikh1.c">schweikh1.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/schweikh1.alt.c">schweikh1.alt.c</a>
|
||||
- alternative source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/schweikh1.orig.c">schweikh1.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/charcount.pl">charcount.pl</a>
|
||||
- character counter</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/schweikh1.c">schweikh1.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/schweikh1.alt.c">schweikh1.alt.c</a> - alternative source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/schweikh1.orig.c">schweikh1.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/charcount.pl">charcount.pl</a> - character counter</li>
|
||||
<li><a href="macos.html">macos.html</a> - work with macOS</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/info">info</a>
|
||||
- standards compliance</li>
|
||||
<li><a href="1998_schweikh1.tar.bz2">1998_schweikh1.tar.bz2</a> -
|
||||
download entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/info">info</a> - standards compliance</li>
|
||||
<li><a href="1998_schweikh1.tar.bz2">1998_schweikh1.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/.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/1998/schweikh1/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/.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/1998/schweikh1/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/macos.md">macos.md</a>
|
||||
- markdown source for marcos.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/README.md">README.md</a> - markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh1/macos.md">macos.md</a> - markdown source for marcos.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+37
-47
@@ -120,40 +120,34 @@
|
||||
<!-- END: this line ends content from: inc/before-content.default.html -->
|
||||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
|
||||
<p>This document describes how this was fixed to work with macOS as well
|
||||
as some of the magic in the entry. Even if you don’t have a Mac it might
|
||||
be worth your time reading especially as some of it details some
|
||||
important fixes and changes in the original entry as well.</p>
|
||||
<p>This document describes how this was fixed to work with macOS as well as some of
|
||||
the magic in the entry. Even if you don’t have a Mac it might be worth your time
|
||||
reading especially as some of it details some important fixes and changes in the
|
||||
original entry as well.</p>
|
||||
<h1 id="macos-changes">macOS changes</h1>
|
||||
<p>As an aside: if you have a Mac with the Apple chip, some of the
|
||||
header files will report an unsupported architecture and unsupported
|
||||
compiler (error, warning). This will not make the program abort,
|
||||
however, but even with an Intel CPU though, the original entry will not
|
||||
work in macOS as it stands because <code>/usr/include</code> is
|
||||
hard-coded in the code and macOS does not have it.</p>
|
||||
<p>Nevertheless, although some of it would not work in other systems
|
||||
where <code>/usr/include</code> exists, the <code>#define</code>s would
|
||||
still be found okay, at least until a file was not found (this
|
||||
limitation was removed in both versions in 2023). see</p>
|
||||
<p>However, as noted, macOS does <strong>not</strong> have
|
||||
<code>/usr/include</code> so this would never work for macOS without
|
||||
some changes, described next. For macOS you will need the command line
|
||||
tools installed which can be done like:</p>
|
||||
<p>As an aside: if you have a Mac with the Apple chip, some of the header files
|
||||
will report an unsupported architecture and unsupported compiler (error,
|
||||
warning). This will not make the program abort, however, but even with an Intel
|
||||
CPU though, the original entry will not work in macOS as it stands because
|
||||
<code>/usr/include</code> is hard-coded in the code and macOS does not have it.</p>
|
||||
<p>Nevertheless, although some of it would not work in other systems where
|
||||
<code>/usr/include</code> exists, the <code>#define</code>s would still be found okay, at least until
|
||||
a file was not found (this limitation was removed in both versions in 2023). see</p>
|
||||
<p>However, as noted, macOS does <strong>not</strong> have <code>/usr/include</code> so this would never
|
||||
work for macOS without some changes, described next. For macOS you will need the
|
||||
command line tools installed which can be done like:</p>
|
||||
<div class="sourceCode" id="cb1"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="fu">sudo</span> xcode-select <span class="at">--install</span></span></code></pre></div>
|
||||
<p>An important point is that the original version hard-coded
|
||||
<code>gcc</code> but just like the entry, the alternate version has also
|
||||
removed this limitation despite <code>gcc</code> existing (though it’s
|
||||
<code>clang</code>) in macOS.</p>
|
||||
<p>Now as far as how this works if you look at the code of <a
|
||||
href="schweikh1.c">schweikh1.c</a>, on line 55 you’ll see a funny
|
||||
command (this goes for the alternate version as well but a bit
|
||||
different).</p>
|
||||
<p>Now the key is two magic numbers, one (two times) on a different line
|
||||
shortly below the string and the other a couple lines further below.</p>
|
||||
<p>In the original the numbers are, respectively, <code>44</code> and
|
||||
<code>46</code>, but with the gcc limitation removed the numbers now are
|
||||
<code>43</code> and <code>45</code>. But how does this work? Well the
|
||||
command is:</p>
|
||||
<p>An important point is that the original version hard-coded <code>gcc</code> but just like
|
||||
the entry, the alternate version has also removed this limitation despite <code>gcc</code>
|
||||
existing (though it’s <code>clang</code>) in macOS.</p>
|
||||
<p>Now as far as how this works if you look at the code of
|
||||
<a href="schweikh1.c">schweikh1.c</a>, on line 55 you’ll see a funny command (this goes for
|
||||
the alternate version as well but a bit different).</p>
|
||||
<p>Now the key is two magic numbers, one (two times) on a different line shortly below the
|
||||
string and the other a couple lines further below.</p>
|
||||
<p>In the original the numbers are, respectively, <code>44</code> and <code>46</code>, but with the gcc
|
||||
limitation removed the numbers now are <code>43</code> and <code>45</code>. But how does this work? Well
|
||||
the command is:</p>
|
||||
<pre><code>"0gcc -ansi -E -dM -undef %s /usr/include/%s>r\0 ("</code></pre>
|
||||
<p>which has been changed to be:</p>
|
||||
<pre><code>"0cc -ansi -E -dM -undef %s /usr/include/%s>r\0 ("</code></pre>
|
||||
@@ -161,21 +155,17 @@ command is:</p>
|
||||
<div class="sourceCode" id="cb4"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a><span class="cf">if</span> <span class="op">((</span>H <span class="op">=</span> fopen <span class="op">(</span>__FILE__<span class="op">+</span><span class="dv">43</span><span class="op">,</span> <span class="dv">43</span><span class="op">+</span>__FILE__<span class="op">)))</span></span>
|
||||
<span id="cb4-2"><a href="#cb4-2" aria-hidden="true" tabindex="-1"></a><span class="cf">while</span> <span class="op">((</span>fgets <span class="op">(</span>L<span class="op">,</span> <span class="op">(</span><span class="dt">int</span><span class="op">)</span><span class="kw">sizeof</span> L<span class="op">,</span> H<span class="op">))</span> <span class="op">!=</span> <span class="dv">0</span><span class="op">)</span> <span class="op">{</span></span>
|
||||
<span id="cb4-3"><a href="#cb4-3" aria-hidden="true" tabindex="-1"></a> I<span class="op">[</span>strcspn <span class="op">(</span>I<span class="op">,</span> <span class="dv">45</span><span class="op">+</span>__FILE__<span class="op">)]</span> <span class="op">=</span> O <span class="op">=</span> <span class="dv">0</span><span class="op">;</span></span></code></pre></div>
|
||||
<p>The first number in the above C means the length starting from 0 up
|
||||
through the <code>></code>. The second number is the same starting
|
||||
point but up through the <code>\0</code> which is why it’s
|
||||
<code>+2</code>. But what happens if only the first number is updated
|
||||
(from the original)? Most of the output will be just
|
||||
<code>#define</code> by itself; in the cases where there was text after
|
||||
that it was macros that certainly were not defined. There might have
|
||||
been other errors as well.</p>
|
||||
<p>Changing this for macOS allows for opening the right files; the
|
||||
problem with macOS is <code>/usr/include</code> does not exist: instead
|
||||
it’s
|
||||
<code>/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include</code>
|
||||
which is why the different command line and the different numbers. The
|
||||
change of the numbers can be found in the alternate code and the
|
||||
explanation is the same.</p>
|
||||
<p>The first number in the above C means the length starting from 0 up through the
|
||||
<code>></code>. The second number is the same starting point but up through the <code>\0</code> which
|
||||
is why it’s <code>+2</code>. But what happens if only the first number is updated (from the
|
||||
original)? Most of the output will be just <code>#define</code> by itself; in the cases
|
||||
where there was text after that it was macros that certainly were not defined.
|
||||
There might have been other errors as well.</p>
|
||||
<p>Changing this for macOS allows for opening the right files; the problem with
|
||||
macOS is <code>/usr/include</code> does not exist: instead it’s
|
||||
<code>/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include</code> which is why
|
||||
the different command line and the different numbers. The change of the numbers
|
||||
can be found in the alternate code and the explanation is the same.</p>
|
||||
|
||||
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
<!-- START: this line starts content from: inc/after-content.default.html -->
|
||||
|
||||
+101
-148
@@ -129,9 +129,9 @@
|
||||
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Jens_Schweikhardt">Jens
|
||||
Schweikhardt</a><br> Location: <a href="../../location.html#DE">DE</a> -
|
||||
<em>Federal Republic of Germany</em> (<em>Germany</em>) <br><br></li>
|
||||
<li>Name: <a href="../../authors.html#Jens_Schweikhardt">Jens Schweikhardt</a><br>
|
||||
Location: <a href="../../location.html#DE">DE</a> - <em>Federal Republic of Germany</em> (<em>Germany</em>)
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -150,16 +150,15 @@ Schweikhardt</a><br> Location: <a href="../../location.html#DE">DE</a> -
|
||||
<span id="cb4-2"><a href="#cb4-2" aria-hidden="true" tabindex="-1"></a></span>
|
||||
<span id="cb4-3"><a href="#cb4-3" aria-hidden="true" tabindex="-1"></a><span class="ex">./yarng</span></span>
|
||||
<span id="cb4-4"><a href="#cb4-4" aria-hidden="true" tabindex="-1"></a><span class="co"># watch what it does</span></span></code></pre></div>
|
||||
<p>What is the difference between what is in the script and running
|
||||
<code>yarng</code> without an arg?</p>
|
||||
<p>What is the difference between what is in the script and running <code>yarng</code> without
|
||||
an arg?</p>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>Run the program with a small argument, like 5 or 10, several times.
|
||||
Are the results different? Why?</p>
|
||||
<p>Run the program with a small argument, like 5 or 10, several times. Are the
|
||||
results different? Why?</p>
|
||||
<h3 id="historical-remarks">Historical remarks:</h3>
|
||||
<p>At the time of judging, some non-gcc compilers that were not fully
|
||||
ANSI standard did not compile this entry correctly. Also at that time,
|
||||
some gcc and egcs implementations ran into a problem when building the
|
||||
entry. Doing:</p>
|
||||
<p>At the time of judging, some non-gcc compilers that were not fully ANSI standard
|
||||
did not compile this entry correctly. Also at that time, some gcc and egcs
|
||||
implementations ran into a problem when building the entry. Doing:</p>
|
||||
<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="fu">make</span> schweikh2</span></code></pre></div>
|
||||
<p>often produced an error of the form:</p>
|
||||
<div class="sourceCode" id="cb6"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="fu">gcc</span> <span class="at">-ansi</span> schweikh2.alt.c <span class="at">-o</span> schweikh2.alt</span>
|
||||
@@ -171,35 +170,30 @@ entry. Doing:</p>
|
||||
<div class="sourceCode" id="cb7"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb7-1"><a href="#cb7-1" aria-hidden="true" tabindex="-1"></a><span class="pp">#line 10 ONE(O(1,1,2,6,0,6))</span></span></code></pre></div>
|
||||
<p>turned into the line:</p>
|
||||
<div class="sourceCode" id="cb8"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb8-1"><a href="#cb8-1" aria-hidden="true" tabindex="-1"></a><span class="pp"># 9 "01\012"</span></span></code></pre></div>
|
||||
<p>(note, though, how that line is on line 11) which caused gcc to give
|
||||
to the assembler the following two lines:</p>
|
||||
<div class="sourceCode" id="cb9"><pre
|
||||
class="sourceCode asm"><code class="sourceCode fasm"><span id="cb9-1"><a href="#cb9-1" aria-hidden="true" tabindex="-1"></a>.stabs <span class="st">"schweikh2.c</span></span>
|
||||
<p>(note, though, how that line is on line 11) which caused gcc to give to the
|
||||
assembler the following two lines:</p>
|
||||
<div class="sourceCode" id="cb9"><pre class="sourceCode asm"><code class="sourceCode fasm"><span id="cb9-1"><a href="#cb9-1" aria-hidden="true" tabindex="-1"></a>.stabs <span class="st">"schweikh2.c</span></span>
|
||||
<span id="cb9-2"><a href="#cb9-2" aria-hidden="true" tabindex="-1"></a>",132,0,0,Ltext1</span></code></pre></div>
|
||||
<p>and the lone <code>"</code> after the <code>#.file</code> line
|
||||
resulted in an assembly syntax error.</p>
|
||||
<p>and the lone <code>"</code> after the <code>#.file</code> line resulted in an assembly syntax error.</p>
|
||||
<p>In some cases one had to compile using <code>gcc -g</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> schweikh2 CFLAGS=-g</span></code></pre></div>
|
||||
<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> schweikh2 CFLAGS=-g</span></code></pre></div>
|
||||
<p>to trigger this error.</p>
|
||||
<p>With the proper text beyond the <code>\012</code>, it was even
|
||||
possible to have all kinds of fun adding inline assembly via
|
||||
<code>#line</code> directives. :-)</p>
|
||||
<p>With the proper text beyond the <code>\012</code>, it was even possible to have all kinds
|
||||
of fun adding inline assembly via <code>#line</code> directives. :-)</p>
|
||||
<h4 id="for-extra-fun-and-credit">For extra fun and credit:</h4>
|
||||
<p>If your compiler had this bug, you could transform the line in the C
|
||||
program to inject assembly instructions in such a way that the program
|
||||
would compile.</p>
|
||||
<p>If you were able to do that, you could have tried adding assembly
|
||||
instructions so that it will compile, execute and do something
|
||||
interesting (or uninteresting, for that matter :-) ).</p>
|
||||
<p>If you succeeded in doing that (especially on FreeBSD, Linux or
|
||||
SunOS/Solaris), you could have emailed the author for a free pat on the
|
||||
back (and maybe you still can :-) ).</p>
|
||||
<p>If your compiler had this bug, you could transform the line in the C program to
|
||||
inject assembly instructions in such a way that the program would compile.</p>
|
||||
<p>If you were able to do that, you could have tried adding assembly instructions
|
||||
so that it will compile, execute and do something interesting (or uninteresting,
|
||||
for that matter :-) ).</p>
|
||||
<p>If you succeeded in doing that (especially on FreeBSD, Linux or SunOS/Solaris),
|
||||
you could have emailed the author for a free pat on the back (and maybe you
|
||||
still can :-) ).</p>
|
||||
<p>Because of this bug, the code was changed to be instead:</p>
|
||||
<div class="sourceCode" id="cb11"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb11-1"><a href="#cb11-1" aria-hidden="true" tabindex="-1"></a><span class="pp">#line 10 "01\015"</span></span></code></pre></div>
|
||||
<p>However in 2023 it was observed that <em>it is gcc</em> (at least
|
||||
some versions?) that has a problem with the compilation of the
|
||||
<em>modified</em> program, giving an internal compiler error:</p>
|
||||
<p>However in 2023 it was observed that <em>it is gcc</em> (at least some versions?) that
|
||||
has a problem with the compilation of the <em>modified</em> program, giving an internal
|
||||
compiler error:</p>
|
||||
<pre><code>:10:16: warning: type defaults to 'int' in declaration of 'zero' [-Wimplicit-int]
|
||||
: In function 'main':
|
||||
:12:1: warning: missing terminating " character
|
||||
@@ -211,8 +205,8 @@ some versions?) that has a problem with the compilation of the
|
||||
<p>and now it works with both clang and gcc.</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<h3 id="what-this-program-does">What this program does</h3>
|
||||
<p>My entry is a <code>yarng</code>, which stands for, you guessed it,
|
||||
yet another random number generator, and is pronounced ‘yawn’ due to its
|
||||
<p>My entry is a <code>yarng</code>, which stands for, you guessed it, yet another
|
||||
random number generator, and is pronounced ‘yawn’ due to its
|
||||
incredible speed. Seriously, it exploits the randomness of quantum
|
||||
mechanical events that build up the hardware as well as some other
|
||||
non-deterministic factors. Here’s how it works:</p>
|
||||
@@ -223,146 +217,105 @@ non-deterministic factors. Here’s how it works:</p>
|
||||
<li>while some other counter is not zero, go to step (1)</li>
|
||||
<li>exit</li>
|
||||
</ol>
|
||||
<p>The <code>yarng</code> therefore produces output at a rate of 1 baud.
|
||||
The number of bits may be specified by an argument and defaults either
|
||||
to <code>UINT_MAX</code> (least likely) or <code>UINT_MAX+1</code> (most
|
||||
likely). Extra credit: why the different values? How long would you need
|
||||
for an empirical test?</p>
|
||||
<p>The <code>yarng</code> therefore produces output at a rate of 1 baud. The number of
|
||||
bits may be specified by an argument and defaults either to <code>UINT_MAX</code>
|
||||
(least likely) or <code>UINT_MAX+1</code> (most likely). Extra credit: why the
|
||||
different values? How long would you need for an empirical test?</p>
|
||||
<p>For example:</p>
|
||||
<div class="sourceCode" id="cb15"><pre
|
||||
class="sourceCode sh"><code class="sourceCode bash"><span id="cb15-1"><a href="#cb15-1" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> ./yarng 32</span>
|
||||
<div class="sourceCode" id="cb15"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb15-1"><a href="#cb15-1" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> ./yarng 32</span>
|
||||
<span id="cb15-2"><a href="#cb15-2" aria-hidden="true" tabindex="-1"></a><span class="ex">10111001010101110110010101001111</span></span>
|
||||
<span id="cb15-3"><a href="#cb15-3" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> ./yarng 5</span>
|
||||
<span id="cb15-4"><a href="#cb15-4" aria-hidden="true" tabindex="-1"></a><span class="ex">10011</span></span></code></pre></div>
|
||||
<h3 id="why-i-think-this-is-obfuscated">Why I think this is
|
||||
obfuscated</h3>
|
||||
<h3 id="why-i-think-this-is-obfuscated">Why I think this is obfuscated</h3>
|
||||
<ul>
|
||||
<li><p>Ever seen a ‘do for … while’ loop?</p></li>
|
||||
<li><p>I avoided <code>int</code> like the plague. Instead I used
|
||||
storage class specifiers (<code>register</code>, <code>auto</code>) to
|
||||
get implicit <code>int</code>. The Standard allows implicit
|
||||
<code>int</code> even in casts as you can see in
|
||||
<code>(void(*)(register))main</code>. Where implicit <code>int</code> is
|
||||
impossible, like in the <code>int main</code> declaration I have
|
||||
<code>int</code> split across two lines. All indent programs I use
|
||||
insert space at the beginning of the continuation line and thereby
|
||||
introduce a syntax error.</p></li>
|
||||
<li><p><code>main()</code> (ab)used as a signal handler. Shocking. Yeah,
|
||||
this leads to undefined behaviour. I have yet to see a system where it
|
||||
does not work. If it doesn’t work for you, I’d appreciate if you mail me
|
||||
about it. Uh-oh, Schweikh did it, uttered “Works for me”. Don’t quote me
|
||||
on that!</p></li>
|
||||
<li><p>Even if you know how the program works, you just can’t predict
|
||||
the output.</p></li>
|
||||
<li><p>Chained use of token pasting operators <code>##</code> with
|
||||
shuffled arguments.</p></li>
|
||||
<li><p>So you think you can’t assign to <code>__LINE__</code> and
|
||||
<code>__FILE__</code>? Not so. The <code>#line</code> preprocessor
|
||||
directive does the trick. But saying <code>#line 10 "01\n"</code> is a
|
||||
little lame and I came up with
|
||||
<code>??=line 10 ONE(O(1,1,2,6,0,6))</code>.</p></li>
|
||||
<li><p><code>__LINE__</code> is used as the signal number argument to
|
||||
<code>signal()</code>. If indenting or other editing changes the number
|
||||
of lines the program is likely to be killed after one second… Thanks to
|
||||
POSIX for specifying <code>SIGALRM</code> as <code>14</code>. You’re SOL
|
||||
if your system does not conform. Get a real OS.</p></li>
|
||||
<li><p>All strings (or characters) needed are crammed into
|
||||
<code>__FILE__</code> using octal notation and then extracted using
|
||||
pointer + offset notation.</p></li>
|
||||
<li><p>Use of a <code>#</code> (null) preprocessor directive (hidden as
|
||||
a <code>%:</code> digraph) Delete this line and prepare for a core
|
||||
dump.</p></li>
|
||||
<li><p>Identifiers reused with different capitalization:
|
||||
<code>one</code>, <code>One</code>, <code>ONE</code>, <code>zero</code>,
|
||||
<code>Zero</code>. <code>ONE</code> is particularly nasty because it
|
||||
appears as a macro taking an arg and as a plain identifier in
|
||||
<code>main</code>’s parameters. The rule is that whenever
|
||||
<code>ONE</code> is followed by <code>(</code> it must be the
|
||||
macro.</p></li>
|
||||
<li><p>A quote from Kernighan and Plauger, <em>The Elements of
|
||||
Programming Style</em>, 2nd Ed., page 21:
|
||||
<code>"A useful way to decide if some piece of code is clear or not is the 'telephone test.' If someone could understand your code when read aloud over the telephone, it's clear enough. If not then it needs rewriting."</code>
|
||||
Now try the telephone test for ‘one = zero = atoi
|
||||
(ONE[zero-1])’.</p></li>
|
||||
<li><p>Don’t you love the aesthetics of symmetry:
|
||||
<code>write (1, 1+__FILE__+1, 1)</code> (telephone test this as well; is
|
||||
it 1, One, ONE, one? Maybe won?).</p></li>
|
||||
<li><p>I avoided <code>int</code> like the plague. Instead I used storage class specifiers
|
||||
(<code>register</code>, <code>auto</code>) to get implicit <code>int</code>. The Standard allows implicit <code>int</code> even in
|
||||
casts as you can see in <code>(void(*)(register))main</code>. Where implicit <code>int</code> is
|
||||
impossible, like in the <code>int main</code> declaration I have <code>int</code> split across two
|
||||
lines. All indent programs I use insert space at the beginning of the
|
||||
continuation line and thereby introduce a syntax error.</p></li>
|
||||
<li><p><code>main()</code> (ab)used as a signal handler. Shocking. Yeah, this leads to undefined
|
||||
behaviour. I have yet to see a system where it does not work. If it doesn’t work
|
||||
for you, I’d appreciate if you mail me about it. Uh-oh, Schweikh did it,
|
||||
uttered “Works for me”. Don’t quote me on that!</p></li>
|
||||
<li><p>Even if you know how the program works, you just can’t predict the output.</p></li>
|
||||
<li><p>Chained use of token pasting operators <code>##</code> with shuffled arguments.</p></li>
|
||||
<li><p>So you think you can’t assign to <code>__LINE__</code> and <code>__FILE__</code>? Not so. The <code>#line</code>
|
||||
preprocessor directive does the trick. But saying <code>#line 10 "01\n"</code> is a little
|
||||
lame and I came up with <code>??=line 10 ONE(O(1,1,2,6,0,6))</code>.</p></li>
|
||||
<li><p><code>__LINE__</code> is used as the signal number argument to <code>signal()</code>. If indenting or
|
||||
other editing changes the number of lines the program is likely to be killed
|
||||
after one second… Thanks to POSIX for specifying <code>SIGALRM</code> as <code>14</code>. You’re SOL if
|
||||
your system does not conform. Get a real OS.</p></li>
|
||||
<li><p>All strings (or characters) needed are crammed into <code>__FILE__</code> using octal
|
||||
notation and then extracted using pointer + offset notation.</p></li>
|
||||
<li><p>Use of a <code>#</code> (null) preprocessor directive (hidden as a <code>%:</code> digraph) Delete
|
||||
this line and prepare for a core dump.</p></li>
|
||||
<li><p>Identifiers reused with different capitalization: <code>one</code>, <code>One</code>, <code>ONE</code>, <code>zero</code>,
|
||||
<code>Zero</code>. <code>ONE</code> is particularly nasty because it appears as a macro taking an arg
|
||||
and as a plain identifier in <code>main</code>’s parameters. The rule is that whenever
|
||||
<code>ONE</code> is followed by <code>(</code> it must be the macro.</p></li>
|
||||
<li><p>A quote from Kernighan and Plauger, <em>The Elements of Programming Style</em>, 2nd
|
||||
Ed., page 21: <code>"A useful way to decide if some piece of code is clear or not is the 'telephone test.' If someone could understand your code when read aloud over the telephone, it's clear enough. If not then it needs rewriting."</code> Now try
|
||||
the telephone test for ‘one = zero = atoi (ONE[zero-1])’.</p></li>
|
||||
<li><p>Don’t you love the aesthetics of symmetry: <code>write (1, 1+__FILE__+1, 1)</code>
|
||||
(telephone test this as well; is it 1, One, ONE, one? Maybe won?).</p></li>
|
||||
</ul>
|
||||
<h3 id="where-does-the-randomness-come-from">Where does the randomness
|
||||
come from?</h3>
|
||||
<h3 id="where-does-the-randomness-come-from">Where does the randomness come from?</h3>
|
||||
<p>Each bit obviously depends on the number of times the loop body is
|
||||
executed between two calls of the signal handler. But what determines
|
||||
this number?</p>
|
||||
<ul>
|
||||
<li>The accuracy of the clock driving the CPU.</li>
|
||||
<li>The accuracy of the clock driving the timer responsible for alarm
|
||||
signals.</li>
|
||||
<li>On multitasking OSes: The total time the process is scheduled to run
|
||||
between successive invocations of the signal handler.</li>
|
||||
<li>The accuracy of the clock driving the timer responsible for alarm signals.</li>
|
||||
<li>On multitasking OSes: The total time the process is scheduled to run between
|
||||
successive invocations of the signal handler.</li>
|
||||
</ul>
|
||||
<p>How about the randomness of the <code>yarng</code>? To measure these
|
||||
properties I counted the number of bit sequences and compared them to
|
||||
what I would expect from a generator with uniform distribution (all
|
||||
sequences equally likely to occur).</p>
|
||||
<p>It is interesting to note that <code>yarng</code>’s maximum
|
||||
deviations are less than or equal to <code>rand(3)</code>’s. Randomness
|
||||
however tends to degrade under high load averages on my system (Linux).
|
||||
This could be avoided by allowing the process one second of execution
|
||||
time instead of wall clock time (using the <code>SIGVTALRM</code> sent
|
||||
by the virtual timer instead of <code>SIGALRM</code>).</p>
|
||||
<p>I’m not surprised. <code>Yarng</code> in the end depends on
|
||||
fluctuations of the electrical field and the heat distribution in the
|
||||
oscillators, the implementation and state of the scheduling algorithm,
|
||||
the system load, number and temporal distribution of asynchronous events
|
||||
and last but not least the phase of the moon. God <em>does</em> play
|
||||
dice. Type <code>yarng</code> and watch Him roll.</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>
|
||||
<p>How about the randomness of the <code>yarng</code>? To measure these properties I
|
||||
counted the number of bit sequences and compared them to what I would
|
||||
expect from a generator with uniform distribution (all sequences
|
||||
equally likely to occur).</p>
|
||||
<p>It is interesting to note that <code>yarng</code>’s maximum deviations are less
|
||||
than or equal to <code>rand(3)</code>’s. Randomness however tends to degrade under
|
||||
high load averages on my system (Linux). This could be avoided by
|
||||
allowing the process one second of execution time instead of wall
|
||||
clock time (using the <code>SIGVTALRM</code> sent by the virtual timer
|
||||
instead of <code>SIGALRM</code>).</p>
|
||||
<p>I’m not surprised. <code>Yarng</code> in the end depends on fluctuations of the
|
||||
electrical field and the heat distribution in the oscillators, the
|
||||
implementation and state of the scheduling algorithm, the system
|
||||
load, number and temporal distribution of asynchronous events and
|
||||
last but not least the phase of the moon. God <em>does</em> play dice.
|
||||
Type <code>yarng</code> and watch Him roll.</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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998schweikh2"><a name="inventory"></a>Inventory
|
||||
for 1998/schweikh2</h1>
|
||||
<h1 id="inventory-for-1998schweikh2"><a name="inventory"></a>Inventory for 1998/schweikh2</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh2/schweikh2.c">schweikh2.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh2/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh2/schweikh2.orig.c">schweikh2.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh2/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a href="1998_schweikh2.tar.bz2">1998_schweikh2.tar.bz2</a> -
|
||||
download entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh2/schweikh2.c">schweikh2.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh2/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh2/schweikh2.orig.c">schweikh2.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh2/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="1998_schweikh2.tar.bz2">1998_schweikh2.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh2/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh2/.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/1998/schweikh2/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh2/.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/1998/schweikh2/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh2/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+110
-147
@@ -129,9 +129,9 @@
|
||||
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Jens_Schweikhardt">Jens
|
||||
Schweikhardt</a><br> Location: <a href="../../location.html#DE">DE</a> -
|
||||
<em>Federal Republic of Germany</em> (<em>Germany</em>) <br><br></li>
|
||||
<li>Name: <a href="../../authors.html#Jens_Schweikhardt">Jens Schweikhardt</a><br>
|
||||
Location: <a href="../../location.html#DE">DE</a> - <em>Federal Republic of Germany</em> (<em>Germany</em>)
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -146,49 +146,43 @@ Schweikhardt</a><br> Location: <a href="../../location.html#DE">DE</a> -
|
||||
the same size (on systems where `sizeof (char *) == 4`, or `4096` when
|
||||
`sizeof (char *) == 8`), increase the manifest constant 32767 on line
|
||||
31.</code></pre>
|
||||
<p>An alternate version allows one to fix this; see <a
|
||||
href="#alternate-code">alternate code</a> below.</p>
|
||||
<p>An alternate version allows one to fix this; see <a href="#alternate-code">alternate
|
||||
code</a> below.</p>
|
||||
<h2 id="to-use">To use:</h2>
|
||||
<p>If <code>dir</code> is the directory (or a directory tree) where you
|
||||
keep all your favorite pictures off the Internet or from
|
||||
<p>If <code>dir</code> is the directory (or a directory tree) where you keep
|
||||
all your favorite pictures off the Internet or from
|
||||
<code>alt.binaries.pictures.*</code>, do</p>
|
||||
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="fu">find</span> dir <span class="at">-type</span> f <span class="at">-print</span> <span class="kw">|</span> <span class="ex">./samefile</span></span></code></pre></div>
|
||||
<p>Maybe you will not need to buy another 10 GB disk to store them.
|
||||
:-)</p>
|
||||
<p>Maybe you will not need to buy another 10 GB disk to store them. :-)</p>
|
||||
<h2 id="try">Try:</h2>
|
||||
<p>If you’re in this winning entry’s directory:</p>
|
||||
<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">./try.sh</span></span></code></pre></div>
|
||||
<p>Notice that the tool finds some files that are duplicates.</p>
|
||||
<h2 id="alternate-code">Alternate code:</h2>
|
||||
<p>If you run into the problem that the author described (above) you can
|
||||
redefine the size as described; this was done with the <code>SZ</code>
|
||||
macro defined in the Makefile which if (in the code) is unset will be
|
||||
set to the default, 32767.</p>
|
||||
<p>If you run into the problem that the author described (above) you can redefine
|
||||
the size as described; this was done with the <code>SZ</code> macro defined in the Makefile
|
||||
which if (in the code) is unset will be set to the default, 32767.</p>
|
||||
<h3 id="alternate-build">Alternate build:</h3>
|
||||
<p>If you wish to change the size to say, 55555:</p>
|
||||
<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="fu">make</span> clobber SIZE=55555 alt</span></code></pre></div>
|
||||
<p>or whatever you wish to redefine it to.</p>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>This program is not as smart as to detect identity of JPEG files with
|
||||
the same picture but with different compression levels. On the other
|
||||
hand compression can make a thing look/sound/feel different so these
|
||||
probably aren’t duplicates anyway. :-)</p>
|
||||
<p>Some time after this entry won, the Internet Systems Consortium (ISC)
|
||||
added the samefile utility to its treasure of software gems! See the
|
||||
author’s page about the tool as well at <a
|
||||
href="http://www.schweikhardt.net/samefile"
|
||||
class="uri">http://www.schweikhardt.net/samefile</a>.</p>
|
||||
<p>This program is not as smart as to detect identity of JPEG files with the same
|
||||
picture but with different compression levels. On the other hand compression can
|
||||
make a thing look/sound/feel different so these probably aren’t duplicates
|
||||
anyway. :-)</p>
|
||||
<p>Some time after this entry won, the Internet Systems Consortium (ISC) added the
|
||||
samefile utility to its treasure of software gems! See the author’s page about
|
||||
the tool as well at <a href="http://www.schweikhardt.net/samefile" class="uri">http://www.schweikhardt.net/samefile</a>.</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<p>The source is expected to conform to IEEE Std 1003.1-1990 (“POSIX”).
|
||||
Thank God the IEEE does not standardize a coding style…</p>
|
||||
<h3 id="what-this-program-does">What this program does</h3>
|
||||
<p>This is best explained in the man page. The troff source for this man
|
||||
page can be found in the file <a href="samefile.1">samefile.1</a>. To
|
||||
render try:</p>
|
||||
<p>This is best explained in the man page. The troff source for this
|
||||
man page can be found in the file <a href="samefile.1">samefile.1</a>. To render try:</p>
|
||||
<div class="sourceCode" id="cb6"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="kw">`</span><span class="fu">man</span> ./samefile.1</span></code></pre></div>
|
||||
<p>Otherwise:</p>
|
||||
<h3 id="samefile1-user-manuals-samefile1">SAMEFILE(1) User Manuals
|
||||
SAMEFILE(1)</h3>
|
||||
<h3 id="samefile1-user-manuals-samefile1">SAMEFILE(1) User Manuals SAMEFILE(1)</h3>
|
||||
<h4 id="name">NAME</h4>
|
||||
<p><code>samefile</code> - find identical files</p>
|
||||
<h4 id="synopsis">SYNOPSIS</h4>
|
||||
@@ -196,34 +190,34 @@ SAMEFILE(1)</h3>
|
||||
<h4 id="description">DESCRIPTION</h4>
|
||||
<p><code>samefile</code> reads a list of file names (one file name per
|
||||
line) from <code>stdin</code>. For each file name pair with identical
|
||||
contents, a line consisting of six tab separated fields is output: The
|
||||
size in bytes, two file names, the character <code>=</code> if the two
|
||||
files are on the same device, <code>X</code> otherwise, and the link
|
||||
counts of the two files. The output is sorted in reverse order by
|
||||
size.</p>
|
||||
<p><code>samefile</code> uses two stages to give optimum
|
||||
performance.</p>
|
||||
<p>In the first stage, all non-plain files are silently ignored
|
||||
(directories, devices, FIFOs, sockets, symbolic links) as well as files
|
||||
for which <code>stat(2)</code> or <code>open(2)</code> fails. The result
|
||||
of the first stage (the file names) is written into a binary tree with
|
||||
one node for every file size. Each node is in turn a linked list of file
|
||||
names along with inode and device information. It is also at this first
|
||||
stage where checks for hard links are done. For any inode only one
|
||||
filename will be added to the binary tree.</p>
|
||||
<p>In the second stage all files having the same size are compared
|
||||
against each other. The rules of mathematical logic are applied to
|
||||
reduce work and output noise: if files <code>A</code>, <code>B</code>,
|
||||
and <code>C</code> have the same size and samefile finds that
|
||||
<code>A = B</code> and <code>A = C</code> then it will not compare
|
||||
<code>B</code> against <code>C</code> (and will not output a line for
|
||||
<code>B</code> and <code>C</code>) but only for <code>A = B</code> and
|
||||
<code>A = C</code>. The algorithm will detect equality across
|
||||
arbitrarily long chains. Note however, that because only the first
|
||||
filename per inode gets into the first stage, the output for a group of
|
||||
identical files with different inode numbers is also minimized. Suppose
|
||||
you have six identical files of size 100 in an inode group consisting of
|
||||
the three inodes with numbers 10, 20 and 30:</p>
|
||||
contents, a line consisting of six tab separated fields is
|
||||
output: The size in bytes, two file names, the character
|
||||
<code>=</code> if the two files are on the same device, <code>X</code> otherwise,
|
||||
and the link counts of the two files. The output
|
||||
is sorted in reverse order by size.</p>
|
||||
<p><code>samefile</code> uses two stages to give optimum performance.</p>
|
||||
<p>In the first stage, all non-plain files are silently
|
||||
ignored (directories, devices, FIFOs, sockets, symbolic
|
||||
links) as well as files for which <code>stat(2)</code> or <code>open(2)</code>
|
||||
fails. The result of the first stage (the file names) is
|
||||
written into a binary tree with one node for every file
|
||||
size. Each node is in turn a linked list of file names
|
||||
along with inode and device information. It is also at
|
||||
this first stage where checks for hard links are done.
|
||||
For any inode only one filename will be added to the
|
||||
binary tree.</p>
|
||||
<p>In the second stage all files having the same size are
|
||||
compared against each other. The rules of mathematical
|
||||
logic are applied to reduce work and output noise: if
|
||||
files <code>A</code>, <code>B</code>, and <code>C</code> have the same size and samefile finds
|
||||
that <code>A = B</code> and <code>A = C</code> then it will not compare <code>B</code> against <code>C</code>
|
||||
(and will not output a line for <code>B</code> and <code>C</code>) but only for <code>A = B</code> and <code>A = C</code>. The algorithm will detect equality across
|
||||
arbitrarily long chains. Note however, that because only
|
||||
the first filename per inode gets into the first stage,
|
||||
the output for a group of identical files with different
|
||||
inode numbers is also minimized. Suppose you have six
|
||||
identical files of size 100 in an inode group consisting
|
||||
of the three inodes with numbers 10, 20 and 30:</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="ex">$</span> ls <span class="at">-i</span> <span class="co"># output edited for readability:</span></span>
|
||||
<span id="cb8-2"><a href="#cb8-2" aria-hidden="true" tabindex="-1"></a> <span class="ex">10</span> file1 20 file4 30 file6</span>
|
||||
<span id="cb8-3"><a href="#cb8-3" aria-hidden="true" tabindex="-1"></a> <span class="ex">10</span> file2 20 file5</span>
|
||||
@@ -231,135 +225,104 @@ the three inodes with numbers 10, 20 and 30:</p>
|
||||
<span id="cb8-5"><a href="#cb8-5" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> ls <span class="kw">|</span> <span class="ex">./samefile</span></span>
|
||||
<span id="cb8-6"><a href="#cb8-6" aria-hidden="true" tabindex="-1"></a><span class="ex">100</span> file1 file4 = 3 2</span>
|
||||
<span id="cb8-7"><a href="#cb8-7" aria-hidden="true" tabindex="-1"></a><span class="ex">100</span> file1 file6 = 3 1</span></code></pre></div>
|
||||
<p>The sum of the sizes in the first column is the amount of disk space
|
||||
you could gain by making all 6 files links to only one file or remove
|
||||
all but one of the files. To be precise, disk space is allocated in
|
||||
blocks - you will probably gain two blocks here, rather than 200 bytes.
|
||||
Note that it is not enough to just remove <code>file4</code> and
|
||||
<code>file6</code> (you would gain only 100 bytes because
|
||||
<code>file5</code> still exists.)</p>
|
||||
<p>The sum of the sizes in the first column is the amount of
|
||||
disk space you could gain by making all 6 files links to
|
||||
only one file or remove all but one of the files. To be
|
||||
precise, disk space is allocated in blocks - you will
|
||||
probably gain two blocks here, rather than 200 bytes.
|
||||
Note that it is not enough to just remove <code>file4</code> and <code>file6</code>
|
||||
(you would gain only 100 bytes because <code>file5</code> still
|
||||
exists.)</p>
|
||||
<h4 id="limitations">LIMITATIONS</h4>
|
||||
<p><code>samefile</code> was written with no limits in mind. The number
|
||||
of input lines is unlimited. The size of the actual files is only
|
||||
limited by available virtual memory needed to compare one pair of files.
|
||||
The only hard limit is the constraint that there should not be more than
|
||||
about <code>8192</code> files having the same size. Experience has shown
|
||||
that there are rarely more than a couple dozen files of the same
|
||||
size.</p>
|
||||
<p><code>samefile</code> was written with no limits in mind. The number of
|
||||
input lines is unlimited. The size of the actual files is
|
||||
only limited by available virtual memory needed to compare
|
||||
one pair of files. The only hard limit is the constraint
|
||||
that there should not be more than about <code>8192</code> files having
|
||||
the same size. Experience has shown that there are rarely
|
||||
more than a couple dozen files of the same size.</p>
|
||||
<h4 id="examples">EXAMPLES</h4>
|
||||
<p>For everybody:</p>
|
||||
<p>What are the duplicates under my home directory?</p>
|
||||
<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">find</span> <span class="va">$HOME</span> <span class="kw">|</span> <span class="ex">./samefile</span></span></code></pre></div>
|
||||
<p>For the sysadmin folks:</p>
|
||||
<p>Report all duplicate files under /usr larger than 16k:</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">find</span> /usr <span class="at">-size</span> +16384c <span class="at">-a</span> <span class="at">-type</span> f <span class="kw">|</span> <span class="ex">./samefile</span></span></code></pre></div>
|
||||
<p>For the ftp and WWW admins: How much space is wasted below our site’s
|
||||
/pub directory?</p>
|
||||
<div class="sourceCode" id="cb11"><pre
|
||||
class="sourceCode sh"><code class="sourceCode bash"><span id="cb11-1"><a href="#cb11-1" aria-hidden="true" tabindex="-1"></a><span class="fu">find</span> /pub <span class="at">-type</span> f <span class="kw">|</span> <span class="ex">samefile</span> <span class="kw">|</span> <span class="fu">awk</span> <span class="st">'{sum += $1} END {print sum}'</span></span></code></pre></div>
|
||||
<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">find</span> /usr <span class="at">-size</span> +16384c <span class="at">-a</span> <span class="at">-type</span> f <span class="kw">|</span> <span class="ex">./samefile</span></span></code></pre></div>
|
||||
<p>For the ftp and WWW admins:
|
||||
How much space is wasted below our site’s /pub directory?</p>
|
||||
<div class="sourceCode" id="cb11"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb11-1"><a href="#cb11-1" aria-hidden="true" tabindex="-1"></a><span class="fu">find</span> /pub <span class="at">-type</span> f <span class="kw">|</span> <span class="ex">samefile</span> <span class="kw">|</span> <span class="fu">awk</span> <span class="st">'{sum += $1} END {print sum}'</span></span></code></pre></div>
|
||||
<h4 id="exit-status">EXIT STATUS</h4>
|
||||
<p>If <code>samefile</code> runs out of memory the exit status is 1,
|
||||
zero otherwise.</p>
|
||||
<p>If <code>samefile</code> runs out of memory the exit status is 1, zero
|
||||
otherwise.</p>
|
||||
<h4 id="see-also">SEE ALSO</h4>
|
||||
<p><code>find(1)</code>, <code>ln(1)</code>, <code>rm(1)</code></p>
|
||||
<h3 id="why-i-think-it-is-obfuscated">Why I think it is obfuscated</h3>
|
||||
<ul>
|
||||
<li>The code is commented but this gives only an <em>extremely</em>
|
||||
faint clue.</li>
|
||||
<li>The code is commented but this gives only an <em>extremely</em> faint clue.</li>
|
||||
<li>The layout does not reflect the program structure, or does it?</li>
|
||||
<li>The data structure the program builds is an ordered binary tree
|
||||
where each node consists of a linked list. This is probably too heavy to
|
||||
comprehend for N percent of all programmers ;-)</li>
|
||||
where each node consists of a linked list. This is probably too
|
||||
heavy to comprehend for N percent of all programmers ;-)</li>
|
||||
<li>The tree is built and traversed by recursive function calls.</li>
|
||||
<li>Why does this program look at <code>dev_t</code> and
|
||||
<code>ino_t</code>? Heavy wizardry.</li>
|
||||
<li>Can you find out how the algorithm works that detects identity of
|
||||
files across arbitrarily long chains? In my private unobfuscated source
|
||||
there are 17 lines describing just that. A classical case for the well
|
||||
known <code>/* You're not supposed to understand this */</code>
|
||||
comment.</li>
|
||||
<li>Why does this program look at <code>dev_t</code> and <code>ino_t</code>? Heavy wizardry.</li>
|
||||
<li>Can you find out how the algorithm works that detects identity
|
||||
of files across arbitrarily long chains? In my private unobfuscated
|
||||
source there are 17 lines describing just that. A classical case for
|
||||
the well known <code>/* You're not supposed to understand this */</code> comment.</li>
|
||||
<li>Would Dijkstra consider this <code>goto</code> harmful?</li>
|
||||
<li>The only string literal is split in more than a dozen
|
||||
substrings.</li>
|
||||
<li>The only string literal is split in more than a dozen substrings.</li>
|
||||
<li>For the task at hand the code is pretty terse. Some dynamic memory
|
||||
is even freed as soon as it’s no longer needed. I have tried to make the
|
||||
preprocessor directives as short as possible. This means no spaces after
|
||||
<code>#include</code> and no spaces after some of the macro names.</li>
|
||||
is even freed as soon as it’s no longer needed. I have tried to
|
||||
make the preprocessor directives as short as possible. This means
|
||||
no spaces after <code>#include</code> and no spaces after some of the macro
|
||||
names.</li>
|
||||
</ul>
|
||||
<p>Are you an algorithms guru? If so you should know why the output
|
||||
appears sorted without any use of <code>qsort(3)</code> or
|
||||
<code>system("sort")</code>.</p>
|
||||
<p>Rewrite (hah!) the program to use memory mapping of files instead of
|
||||
<code>read(2)</code>. Does this affect performance noticeably?</p>
|
||||
<p>It’s easy to write a script that takes <code>samefile</code>’s output
|
||||
and hard links (or symlinks) identical files. Writing such a script is
|
||||
appears sorted without any use of <code>qsort(3)</code> or <code>system("sort")</code>.</p>
|
||||
<p>Rewrite (hah!) the program to use memory mapping of files instead
|
||||
of <code>read(2)</code>. Does this affect performance noticeably?</p>
|
||||
<p>It’s easy to write a script that takes <code>samefile</code>’s output and
|
||||
hard links (or symlinks) identical files. Writing such a script is
|
||||
left as an exercise for the deobfuscator.</p>
|
||||
<p>When you run <code>samefile</code> on some directory tree, try to
|
||||
estimate how much you think it will find. Is the actual result anywhere
|
||||
<p>When you run <code>samefile</code> on some directory tree, try to estimate
|
||||
how much you think it will find. Is the actual result anywhere
|
||||
near your estimate? How many copies of the GPL <code>COPYING</code> file
|
||||
are there on your filesystems? :-)</p>
|
||||
<p>In the remote event that the input has more than <code>8192</code>
|
||||
files with the same size (on systems where
|
||||
<code>sizeof (char *) == 4</code>, or <code>4096</code> when
|
||||
<code>sizeof (char *) == 8</code>), increase the manifest constant 32767
|
||||
on line 31.</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>
|
||||
<p>In the remote event that the input has more than <code>8192</code> files with
|
||||
the same size (on systems where <code>sizeof (char *) == 4</code>, or <code>4096</code> when
|
||||
<code>sizeof (char *) == 8</code>), increase the manifest constant 32767 on line
|
||||
31.</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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998schweikh3"><a name="inventory"></a>Inventory
|
||||
for 1998/schweikh3</h1>
|
||||
<h1 id="inventory-for-1998schweikh3"><a name="inventory"></a>Inventory for 1998/schweikh3</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/schweikh3.c">schweikh3.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/schweikh3.alt.c">schweikh3.alt.c</a>
|
||||
- alternative source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/schweikh3.orig.c">schweikh3.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/samefile.1.dupe">samefile.1.dupe</a>
|
||||
- samefile man page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/samefile.1">samefile.1</a>
|
||||
- samefile man page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a href="1998_schweikh3.tar.bz2">1998_schweikh3.tar.bz2</a> -
|
||||
download entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/schweikh3.c">schweikh3.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/schweikh3.alt.c">schweikh3.alt.c</a> - alternative source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/schweikh3.orig.c">schweikh3.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/samefile.1.dupe">samefile.1.dupe</a> - samefile man page</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/samefile.1">samefile.1</a> - samefile man page</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="1998_schweikh3.tar.bz2">1998_schweikh3.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/.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/1998/schweikh3/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/.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/1998/schweikh3/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/schweikh3/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
+39
-63
@@ -130,8 +130,8 @@
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Tom_Torfs">Tom Torfs</a><br>
|
||||
Location: <a href="../../location.html#ZZ">ZZ</a> - <em>Unknown
|
||||
location</em> <br><br></li>
|
||||
Location: <a href="../../location.html#ZZ">ZZ</a> - <em>Unknown location</em>
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -153,9 +153,9 @@ xor : value to xor the final CRC with (hexadecimal)</code></pre>
|
||||
<h2 id="try">Try:</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">./try.sh</span></span></code></pre></div>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>If you don’t believe the program is correct, try and compare the
|
||||
output of the program with the value of CRCs computed by PKZIP or any
|
||||
other archiver that uses the CRC-32 algorithm.</p>
|
||||
<p>If you don’t believe the program is correct, try and compare the output
|
||||
of the program with the value of CRCs computed by PKZIP or any other
|
||||
archiver that uses the CRC-32 algorithm.</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<pre><code>Usage:
|
||||
./tomtorfs filename bitwidth polynom reflected init xor
|
||||
@@ -176,22 +176,19 @@ xor : value to xor the final CRC with (hexadecimal)</code></pre>
|
||||
<h4 id="arc">ARC:</h4>
|
||||
<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="ex">./tomtorfs</span> filename 16 8005 1 0000 0000</span></code></pre></div>
|
||||
<h3 id="portability-notes">Portability notes</h3>
|
||||
<p>The program assumes <code>CHAR_BIT==8</code>. Results are undefined
|
||||
if <code>bitwidth > sizeof(unsigned long) * 8</code>. It is also
|
||||
assumed that <code>EOF</code> is <code>-1</code> and <code>1</code> is a
|
||||
valid exit value to indicate failure (replace them with <code>EOF</code>
|
||||
resp. <code>EXIT_FAILURE</code> if the assumptions are false). Otherwise
|
||||
ANSI/ISO C.</p>
|
||||
<p>The program assumes <code>CHAR_BIT==8</code>. Results are undefined if <code>bitwidth > sizeof(unsigned long) * 8</code>. It is also assumed that <code>EOF</code> is <code>-1</code> and <code>1</code> is a
|
||||
valid exit value to indicate failure (replace them with <code>EOF</code> resp.
|
||||
<code>EXIT_FAILURE</code> if the assumptions are false). Otherwise ANSI/ISO C.</p>
|
||||
<p>No special build options required.</p>
|
||||
<h3 id="special-notes">Special notes</h3>
|
||||
<p>Count the number of non-whitespace characters in the source file to
|
||||
find out what dark force drove me to write this ;-).</p>
|
||||
<p>Count the number of non-whitespace characters in the source
|
||||
file to find out what dark force drove me to write this ;-).</p>
|
||||
<h3 id="spoiler">Spoiler</h3>
|
||||
<p>First of all, if you run a C beautifier on the program (thereby of
|
||||
course losing the nice code shape I worked so hard on ;-) ) the code
|
||||
will become a bit more readable.</p>
|
||||
<p>The variable names are not very descriptive. They have the following
|
||||
meanings:</p>
|
||||
<p>First of all, if you run a C beautifier on the program (thereby of course losing
|
||||
the nice code shape I worked so hard on ;-) ) the code will become a bit more
|
||||
readable.</p>
|
||||
<p>The variable names are not very descriptive. They have the
|
||||
following meanings:</p>
|
||||
<pre><code>a = argc
|
||||
A = argv
|
||||
|
||||
@@ -208,67 +205,46 @@ b = array of unsigned long variables
|
||||
B = FILE * through which the file argv[1] is opened
|
||||
|
||||
C = typedef for unsigned long</code></pre>
|
||||
<p>The first <code>for</code> loop simply reads the command-line
|
||||
arguments in the <code>b[]</code> array. The third parameter to
|
||||
<code>strtoul(3)</code> causes all arguments to be in base-16 (hex)
|
||||
except the first one, which will be in base-10 (decimal).</p>
|
||||
<p>The rest of the program “simply” calculates the CRC in
|
||||
<code>b[5]</code> and then prints it to <code>stdout</code>. The bit
|
||||
reflection loops may appear a bit tricky at first, but if you have a
|
||||
good look at them they should become obvious also.</p>
|
||||
<p>The first <code>for</code> loop simply reads the command-line arguments
|
||||
in the <code>b[]</code> array. The third parameter to <code>strtoul(3)</code> causes
|
||||
all arguments to be in base-16 (hex) except the first one,
|
||||
which will be in base-10 (decimal).</p>
|
||||
<p>The rest of the program “simply” calculates the CRC in <code>b[5]</code>
|
||||
and then prints it to <code>stdout</code>. The bit reflection loops may
|
||||
appear a bit tricky at first, but if you have a good look
|
||||
at them they should become obvious also.</p>
|
||||
<h3 id="acknowledgments">Acknowledgments:</h3>
|
||||
<p>Ross N. Williams, whose CRC guide was very useful to me for writing
|
||||
this. You can find it in <a href="crc.txt">crc.txt</a>.</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>
|
||||
<p>Ross N. Williams, whose CRC guide was very useful to me
|
||||
for writing this. You can find it in <a href="crc.txt">crc.txt</a>.</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>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<h1 id="inventory-for-1998tomtorfs"><a name="inventory"></a>Inventory
|
||||
for 1998/tomtorfs</h1>
|
||||
<h1 id="inventory-for-1998tomtorfs"><a name="inventory"></a>Inventory for 1998/tomtorfs</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/tomtorfs.c">tomtorfs.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/tomtorfs.orig.c">tomtorfs.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/crc.txt">crc.txt</a>
|
||||
- painless guide to CRC algorithms</li>
|
||||
<li><a href="1998_tomtorfs.tar.bz2">1998_tomtorfs.tar.bz2</a> - download
|
||||
entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/tomtorfs.c">tomtorfs.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/tomtorfs.orig.c">tomtorfs.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/crc.txt">crc.txt</a> - painless guide to CRC algorithms</li>
|
||||
<li><a href="1998_tomtorfs.tar.bz2">1998_tomtorfs.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/.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/1998/tomtorfs/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/.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/1998/tomtorfs/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/tomtorfs/README.md">README.md</a> - markdown source for index.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
Reference in new issue
Block a user