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
+129
-176
@@ -130,8 +130,8 @@
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Scott_Vokes">Scott Vokes</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 -->
|
||||
@@ -144,19 +144,18 @@ America</em> (<em>United States</em>) <br><br></li>
|
||||
<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#2018_vokes">2018 vokes bugs</a>.</p>
|
||||
<p>For more detailed information see <a href="../../bugs.html#2018_vokes">2018 vokes 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">./prog</span> <span class="op"><</span> file.txt</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>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>What this program does is not witchcraft and there are no spectres,
|
||||
but you might have a meltdown trying to work it all out (look at the
|
||||
source code to understand this better).</p>
|
||||
<p>This entry is designed to mislead in many ways. However, if you find
|
||||
yourself wanting to know the possibilities for navigating a graph, you
|
||||
will get the answer you seek with no hocus pocus.</p>
|
||||
<p>What this program does is not witchcraft and there are no spectres, but you
|
||||
might have a meltdown trying to work it all out (look at the source code to
|
||||
understand this better).</p>
|
||||
<p>This entry is designed to mislead in many ways. However, if you find yourself
|
||||
wanting to know the possibilities for navigating a graph, you will get the
|
||||
answer you seek with no hocus pocus.</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<h3 id="introduction">Introduction:</h3>
|
||||
<p>This program reads a directed graph (as lines with integer node IDs),
|
||||
@@ -164,8 +163,7 @@ and prints the graph’s nodes in reverse-topologically sorted order,
|
||||
grouped into strongly connected components. Given a set of nodes
|
||||
representing targets and edges representing dependencies between them,
|
||||
it produces a build order with any dependency cycles gathered.</p>
|
||||
<p>For example, the following input (provided as <a
|
||||
href="example-1.txt">example-1.txt</a>):</p>
|
||||
<p>For example, the following input (provided as <a href="example-1.txt">example-1.txt</a>):</p>
|
||||
<pre><code>0 4 8
|
||||
1 0
|
||||
2 1 3
|
||||
@@ -184,205 +182,160 @@ href="example-1.txt">example-1.txt</a>):</p>
|
||||
6 -> 5, 2
|
||||
7 -> 3, 6, 7</code></pre>
|
||||
<p>So, node 0 has edges to / depends on nodes 4 and 8, node 1 depends on
|
||||
node 0, and so on. Then, it groups the graph’s nodes into strongly
|
||||
connected components and prints them in reverse-topologically sorted
|
||||
order:</p>
|
||||
node 0, and so on. Then, it groups the graph’s nodes into
|
||||
strongly connected components and prints them in reverse-topologically
|
||||
sorted order:</p>
|
||||
<pre><code>0: 8
|
||||
1: 0 1 4
|
||||
2: 2 3
|
||||
3: 5 6
|
||||
4: 7</code></pre>
|
||||
<p>It uses <a
|
||||
href="https://en.wikipedia.org/wiki/Tarjan's_strongly_connected_components_algorithm">Tarjan’s
|
||||
strongly connected components algorithm</a> for the grouping and
|
||||
reverse-topological sorting, along with a bonus hidden implementation of
|
||||
counting sort, which sorts each group.</p>
|
||||
<p>For other details about the input format, see <a
|
||||
href="#issues-and-limitations">Issues and Limitations</a>.</p>
|
||||
<p>It uses <a href="https://en.wikipedia.org/wiki/Tarjan's_strongly_connected_components_algorithm">Tarjan’s strongly connected components
|
||||
algorithm</a>
|
||||
for the grouping and reverse-topological sorting, along with a bonus hidden
|
||||
implementation of counting sort, which sorts each group.</p>
|
||||
<p>For other details about the input format, see <a href="#issues-and-limitations">Issues and
|
||||
Limitations</a>.</p>
|
||||
<h3 id="building">Building:</h3>
|
||||
<p>To build:</p>
|
||||
<pre><code> ${CC} -o prog prog.c -std=c11 -O3 \
|
||||
-Wall -Wextra -pedantic -Wno-missing-prototypes</code></pre>
|
||||
<p><code>-Wno-missing-prototypes</code> is necessary because there
|
||||
aren’t any prototypes. (They would put the program well over the size
|
||||
limit.)</p>
|
||||
<p>Note: The program can also be built with <code>-std=c99</code> or
|
||||
<code>-std=c89</code>.</p>
|
||||
<p>If building with <code>-Weverything</code>, then
|
||||
<code>-Wno-strict-prototypes</code> may also be necessary – the function
|
||||
pointer declarations for <code>_</code> and <code>B</code> may get
|
||||
warnings otherwise, for reasons described next in <a
|
||||
href="#obfuscations">Obfuscations</a>.</p>
|
||||
<p><code>-Wno-missing-prototypes</code> is necessary because there aren’t any
|
||||
prototypes. (They would put the program well over the size limit.)</p>
|
||||
<p>Note: The program can also be built with <code>-std=c99</code> or <code>-std=c89</code>.</p>
|
||||
<p>If building with <code>-Weverything</code>, then <code>-Wno-strict-prototypes</code>
|
||||
may also be necessary – the function pointer declarations for
|
||||
<code>_</code> and <code>B</code> may get warnings otherwise, for reasons described
|
||||
next in <a href="#obfuscations">Obfuscations</a>.</p>
|
||||
<h3 id="obfuscations">Obfuscations:</h3>
|
||||
<ul>
|
||||
<li><p>This entry uses functions that have a variable number of
|
||||
arguments, but despite what the rules say, there is no need to be
|
||||
careful about <code>va_list</code> implementation differences. :) .
|
||||
There are several references to a function pointer, <code>_</code>, but
|
||||
it’s called with different numbers of arguments in different places. (In
|
||||
particular, look at <code>spell</code>.) Because the function pointer
|
||||
declaration has an empty list of parameters, the argument count and
|
||||
types are unconstrained. <code>_</code> is set to different functions in
|
||||
several places, but it is always called with appropriate argument(s) for
|
||||
its possible current functions. This is allowed by the standard – The
|
||||
section on
|
||||
<code>F</code>,<code>I</code>,<code>N</code>,<code>D</code>,<code>M</code>,<code>Y</code>,<code>C</code>,<code>L</code>,<code>U</code>,<code>E</code>
|
||||
has further details.</p></li>
|
||||
<li><p>It uses <code>_</code> in three different scopes: as a
|
||||
<code>goto</code> label (function scope), as an <code>enum</code> name,
|
||||
and a <code>_</code> function pointer (which is required to have file
|
||||
scope, since it starts with <code>_</code>). There are also other
|
||||
<code>_</code>s: it appears in a string, obscured by a hexadecimal
|
||||
escape sequence (<code>\x5f</code>), and the cauldron is supported by a
|
||||
giant underscore. (Does this program qualify for Best One
|
||||
Liner?)</p></li>
|
||||
<li><p>This entry uses functions that have a variable number of arguments,
|
||||
but despite what the rules say, there is no need to be careful about
|
||||
<code>va_list</code> implementation differences. :) . There are several
|
||||
references to a function pointer, <code>_</code>, but it’s called with different
|
||||
numbers of arguments in different places. (In particular, look at
|
||||
<code>spell</code>.) Because the function pointer declaration has an empty list
|
||||
of parameters, the argument count and types are unconstrained. <code>_</code> is
|
||||
set to different functions in several places, but it is always called
|
||||
with appropriate argument(s) for its possible current functions. This
|
||||
is allowed by the standard – The section on
|
||||
<code>F</code>,<code>I</code>,<code>N</code>,<code>D</code>,<code>M</code>,<code>Y</code>,<code>C</code>,<code>L</code>,<code>U</code>,<code>E</code> has further details.</p></li>
|
||||
<li><p>It uses <code>_</code> in three different scopes: as a <code>goto</code> label (function
|
||||
scope), as an <code>enum</code> name, and a <code>_</code> function pointer (which is required
|
||||
to have file scope, since it starts with <code>_</code>). There are also other
|
||||
<code>_</code>s: it appears in a string, obscured by a hexadecimal escape sequence
|
||||
(<code>\x5f</code>), and the cauldron is supported by a giant underscore.
|
||||
(Does this program qualify for Best One Liner?)</p></li>
|
||||
<li><p>Most of the variables are not only global, but used for unrelated
|
||||
purposes at different times, so just renaming them while studying the
|
||||
program should make it even more confusing. The few variables local to
|
||||
functions have their names reused for different things in other
|
||||
functions.</p></li>
|
||||
<li><p>There is an enum early on that defines several single-letter
|
||||
identifiers:
|
||||
<code>F</code>,<code>I</code>,<code>N</code>,<code>D</code>,<code>M</code>,<code>Y</code>,<code>C</code>,<code>L</code>,<code>U</code>,<code>E</code>.
|
||||
These are used for array offsets, both individually and in combination.
|
||||
The first several values are also a clue: ISO/IEC 9899:1999 chapter
|
||||
6.7.5.3 verse 14 describes how function declarators with an empty
|
||||
parameter list behave. (As does 3.5.4.3 for ANSI C, which explains the
|
||||
<code>0x3543</code> that appears soon after.)</p></li>
|
||||
<li><p>Several parts of the program’s state are stashed in otherwise
|
||||
unused offsets of the node arrays. These locations are accessed in
|
||||
multiple ways, such as using <code>I[p]</code> (where
|
||||
<code>I == 7</code>) as well as <code>p[F+L]</code> (6+1), or
|
||||
<code>b[M-N]</code> (14-5) and <code>U[b]</code> (where
|
||||
<code>U == 9</code>).</p></li>
|
||||
<li><p>The other identifiers are misleading, punny, or both.
|
||||
<code>spectre</code> does not exploit CVE-2017-5753 or CVE-2017-5715,
|
||||
for example – it just fits the witch theme. <code>cast</code> doesn’t
|
||||
cast, <code>hex</code> has nothing to do with hexadecimal,
|
||||
<code>bubble</code> is not bubble sort, there is no undefined behavior
|
||||
in <code>nasal_demons</code>, and <code>main()</code> has absolutely
|
||||
nothing to do with a hand.</p></li>
|
||||
<li><p>For well-formed input, how the program determines when to exit is
|
||||
a bit obscure. <code>main()</code> ends with a <code>goto</code> leading
|
||||
back to an earlier <code>_</code> label, so it just loops forever, and
|
||||
<code>exit</code> only appears in code paths related to error-handling.
|
||||
It looks like <code>cast</code> calls <code>meltdown</code> with its
|
||||
second argument set to 0, which would call <code>exit</code>, but
|
||||
running in <code>gdb(1)</code> with a breakpoint on <code>cast</code>
|
||||
reveals that it isn’t being called…</p></li>
|
||||
<li><p>Instead of using <code>isdigit(3)</code>, the program checks the
|
||||
numeric value of each <code>char</code>, and literals that would suggest
|
||||
comparing against e.g. <code>'0'</code> are specified in octal in one
|
||||
place, and produced by arithmetic using the <code>enum</code>
|
||||
elsewhere.</p></li>
|
||||
<li><p>Common conventions are subverted: <code>i</code> is not a loop
|
||||
index, <code>argv</code> and <code>argc</code>’s names are
|
||||
swapped.</p></li>
|
||||
<li><p><code>NULL</code> does not appear in the program. Instead,
|
||||
<code>argc[argv]</code> (which is required to be a NULL pointer) is
|
||||
saved and passed to where its value is needed.</p></li>
|
||||
<li><p>Oh, and the program is squashed into the shape of a bubbling
|
||||
cauldron, on top of a giant underscore, so there’s that.</p></li>
|
||||
<li><p>There is an enum early on that defines several single-letter identifiers:
|
||||
<code>F</code>,<code>I</code>,<code>N</code>,<code>D</code>,<code>M</code>,<code>Y</code>,<code>C</code>,<code>L</code>,<code>U</code>,<code>E</code>. These are used for array offsets,
|
||||
both individually and in combination. The first several values are also a
|
||||
clue: ISO/IEC 9899:1999 chapter 6.7.5.3 verse 14 describes how function
|
||||
declarators with an empty parameter list behave. (As does 3.5.4.3 for ANSI C,
|
||||
which explains the <code>0x3543</code> that appears soon after.)</p></li>
|
||||
<li><p>Several parts of the program’s state are stashed in otherwise unused
|
||||
offsets of the node arrays. These locations are accessed in multiple
|
||||
ways, such as using <code>I[p]</code> (where <code>I == 7</code>) as well as <code>p[F+L]</code> (6+1),
|
||||
or <code>b[M-N]</code> (14-5) and <code>U[b]</code> (where <code>U == 9</code>).</p></li>
|
||||
<li><p>The other identifiers are misleading, punny, or both. <code>spectre</code> does
|
||||
not exploit CVE-2017-5753 or CVE-2017-5715, for example – it just fits
|
||||
the witch theme. <code>cast</code> doesn’t cast, <code>hex</code> has nothing to do with
|
||||
hexadecimal, <code>bubble</code> is not bubble sort, there is no undefined
|
||||
behavior in <code>nasal_demons</code>, and <code>main()</code> has absolutely nothing to do
|
||||
with a hand.</p></li>
|
||||
<li><p>For well-formed input, how the program determines when to exit is a
|
||||
bit obscure. <code>main()</code> ends with a <code>goto</code> leading back to an earlier <code>_</code>
|
||||
label, so it just loops forever, and <code>exit</code> only appears in code paths
|
||||
related to error-handling. It looks like <code>cast</code> calls <code>meltdown</code> with
|
||||
its second argument set to 0, which would call <code>exit</code>, but running in
|
||||
<code>gdb(1)</code> with a breakpoint on <code>cast</code> reveals that it isn’t being called…</p></li>
|
||||
<li><p>Instead of using <code>isdigit(3)</code>, the program checks the numeric value of
|
||||
each <code>char</code>, and literals that would suggest comparing against e.g. <code>'0'</code>
|
||||
are specified in octal in one place, and produced by arithmetic using
|
||||
the <code>enum</code> elsewhere.</p></li>
|
||||
<li><p>Common conventions are subverted: <code>i</code> is not a loop index, <code>argv</code> and
|
||||
<code>argc</code>’s names are swapped.</p></li>
|
||||
<li><p><code>NULL</code> does not appear in the program. Instead, <code>argc[argv]</code> (which is
|
||||
required to be a NULL pointer) is saved and passed to where its value
|
||||
is needed.</p></li>
|
||||
<li><p>Oh, and the program is squashed into the shape of a bubbling cauldron,
|
||||
on top of a giant underscore, so there’s that.</p></li>
|
||||
</ul>
|
||||
<h3 id="issues-and-limitations">Issues and Limitations:</h3>
|
||||
<ul>
|
||||
<li><p>Despite appearances, it does not handle numbers in hex, or
|
||||
provide a <code>curses(3)</code>-based interface.</p></li>
|
||||
<li><p>The expected input format is zero or more lines of
|
||||
space-separated integers. If other characters appear in the input, it
|
||||
will either reject the input entirely and exit with a non-zero status,
|
||||
or skip number(s) adjacent to the non-digit characters, depending on
|
||||
where the characters appear. Tabs and multiple consecutive spaces are
|
||||
handled correctly, however.</p></li>
|
||||
<li><p>Individual lines of input longer than <code>0x3543 - 1</code>
|
||||
bytes will be split and processed as if they were multiple lines of
|
||||
input, which can produce incorrect results. This magic number’s
|
||||
significance is described earlier.</p></li>
|
||||
<li><p>The algorithm expects its input to represent a fully connected
|
||||
graph. While the output is otherwise topologically sorted, if there are
|
||||
nodes completely unconnected to the rest of the graph (with or without
|
||||
self-cycles), they will be output as soon as they are processed – this
|
||||
means that, when there are disconnected nodes, reordering the input
|
||||
lines can produce different output. Addressing this by adding another
|
||||
pass is would put the program over the size limit.</p></li>
|
||||
<li><p>While the node IDs don’t need to be consecutive or start at 0,
|
||||
the implementation doesn’t have special handling for sparse graphs. If
|
||||
you give it a graph with nodes numbered 0 and 2147483647, it will
|
||||
attempt to allocate sufficient memory (potentially around 32 GB) for the
|
||||
entire range of graph nodes, even if those are the only ones. If memory
|
||||
allocation returns NULL, it will gracefully exit, otherwise it will
|
||||
succeed, eventually, perhaps after a great deal of swapping.</p></li>
|
||||
<li><p>Node IDs >= 2147483648 will cause the program to print an
|
||||
error message and exit with a non-zero status. This shrinks the code
|
||||
that detects overflowing the array size by a bit.</p></li>
|
||||
<li><p>A very large group of nodes in a cycle can cause a stack
|
||||
overflow. This typically takes over 100,000 nodes, and depends on the
|
||||
order the nodes are visited. Addressing this would put the program over
|
||||
the size limit.</p></li>
|
||||
<li><p>The implementation depends on the characters <code>'0'</code>,
|
||||
<code>'1'</code>, … <code>'9'</code> having the values <code>48</code>
|
||||
through <code>57</code>, rather than using <code>isdigit(3)</code>. As
|
||||
noted above, this program has nothing to do with a hand.</p></li>
|
||||
<li><p>Despite appearances, it does not handle numbers in hex, or provide
|
||||
a <code>curses(3)</code>-based interface.</p></li>
|
||||
<li><p>The expected input format is zero or more lines of space-separated
|
||||
integers. If other characters appear in the input, it will either
|
||||
reject the input entirely and exit with a non-zero status, or skip
|
||||
number(s) adjacent to the non-digit characters, depending on where the
|
||||
characters appear. Tabs and multiple consecutive spaces are handled
|
||||
correctly, however.</p></li>
|
||||
<li><p>Individual lines of input longer than <code>0x3543 - 1</code> bytes will be
|
||||
split and processed as if they were multiple lines of input, which can
|
||||
produce incorrect results. This magic number’s significance is
|
||||
described earlier.</p></li>
|
||||
<li><p>The algorithm expects its input to represent a fully connected graph.
|
||||
While the output is otherwise topologically sorted, if there are nodes
|
||||
completely unconnected to the rest of the graph (with or without
|
||||
self-cycles), they will be output as soon as they are processed –
|
||||
this means that, when there are disconnected nodes, reordering the
|
||||
input lines can produce different output. Addressing this by adding
|
||||
another pass is would put the program over the size limit.</p></li>
|
||||
<li><p>While the node IDs don’t need to be consecutive or start at 0, the
|
||||
implementation doesn’t have special handling for sparse graphs. If you
|
||||
give it a graph with nodes numbered 0 and 2147483647, it will attempt
|
||||
to allocate sufficient memory (potentially around 32 GB) for the
|
||||
entire range of graph nodes, even if those are the only ones. If
|
||||
memory allocation returns NULL, it will gracefully exit, otherwise it
|
||||
will succeed, eventually, perhaps after a great deal of swapping.</p></li>
|
||||
<li><p>Node IDs >= 2147483648 will cause the program to print an error
|
||||
message and exit with a non-zero status. This shrinks the code that
|
||||
detects overflowing the array size by a bit.</p></li>
|
||||
<li><p>A very large group of nodes in a cycle can cause a stack overflow.
|
||||
This typically takes over 100,000 nodes, and depends on the order the
|
||||
nodes are visited. Addressing this would put the program over the size
|
||||
limit.</p></li>
|
||||
<li><p>The implementation depends on the characters <code>'0'</code>, <code>'1'</code>, … <code>'9'</code> having
|
||||
the values <code>48</code> through <code>57</code>, rather than using <code>isdigit(3)</code>. As noted above,
|
||||
this program has nothing to do with a hand.</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-2018vokes"><a name="inventory"></a>Inventory for
|
||||
2018/vokes</h1>
|
||||
<h1 id="inventory-for-2018vokes"><a name="inventory"></a>Inventory for 2018/vokes</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/2018/vokes/prog.c">prog.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/prog.orig.c">prog.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/example-1.txt">example-1.txt</a>
|
||||
- sample input</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/example-2.txt">example-2.txt</a>
|
||||
- sample input</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/example-tab.txt">example-tab.txt</a>
|
||||
- sample input</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/ioccc.txt">ioccc.txt</a>
|
||||
- sample input</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a href="2018_vokes.tar.bz2">2018_vokes.tar.bz2</a> - download entry
|
||||
source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/prog.c">prog.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/prog.orig.c">prog.orig.c</a> - original source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/example-1.txt">example-1.txt</a> - sample input</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/example-2.txt">example-2.txt</a> - sample input</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/example-tab.txt">example-tab.txt</a> - sample input</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/ioccc.txt">ioccc.txt</a> - sample input</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="2018_vokes.tar.bz2">2018_vokes.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/2018/vokes/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/.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/2018/vokes/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/.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/2018/vokes/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2018/vokes/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