build missing HTML files for entries
Setup a simple topnav for missing HTML files for entries. Added `bin/gen-other-html.sh` to build entry HTML files from markdown other than README.md to index.html HTML files. Fixed duplicate link text in `2020/ferguson1/gameplay.md`. Improved `inc/md2html.cfg` to support building the missing HTML files for entries. Added `make gen_other_html` to top level Makefile. Added `make gen_other_html` to `make quick_www` and `make www`. Fixed inventory links for year level index.html files. Changed `bin/output-year-index.sh` VERSION from "1.0.1 2024-02-23" to "1.1 2024-02-27". Added missing lines in `manifest.numbers`. Update the affected `.entry.json` files. The manifest (in both `manifest.numbers` and the collection of manifests from of all entry `.entry.json` files) now match. Errors from `make verify_entry_files` will now abort both `make quick_www` and `make www` rules in the top level `Makefile`. Changed markdown files in manifest to have an _inventory_order_ of _2000000000_ so that the `index.html` file will usually appear at the start of the _Secondary files_ set for the "#inventory" section of an entry's `index.html` file. Changed compressed tar files (files that end in _.tar.bz2_) in manifest to have an _inventory_order_ of _100000_ so that these files will usually appear at the end of the _Primary files_ set for the "#inventory" section of an entry's `index.html` file. Added 'Jump to top` link above the _Primary files_ section. Changed `bin/output-index-inventory.sh` VERSION from "1.1.1 2024-02-23" to "1.2 2024-02-27". Updated HTML files to perform the above via `make www`.
This commit is contained in:
1 parent
7babf792e4
commit
9d3438fb88
718 files changed
+17515
-4084
No files matched your search
@@ -0,0 +1,371 @@
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||||
<!-- START: two lines up starts content from: inc/top.default.html -->
|
||||
<!-- -->
|
||||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||||
<!-- -->
|
||||
<!-- END: this line ends content from: inc/top.default.html -->
|
||||
<!-- -->
|
||||
<!-- The original markdown content was formed by the tool: bin/gen-other-html.sh -->
|
||||
<!-- The HTML was converted from markdown by the tool: bin/md2html.sh -->
|
||||
<!-- -->
|
||||
<!-- START: this line starts content from: inc/head.default.html -->
|
||||
|
||||
<head>
|
||||
<link rel="stylesheet" href="../../ioccc.css">
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
|
||||
<title>The International Obfuscated C Code Contest</title>
|
||||
<meta name="description" content="obfuscation.md for 2020/ferguson2">
|
||||
<meta name="keywords" content="IOCCC, 2020/ferguson2, obfuscation.md">
|
||||
</head>
|
||||
|
||||
<!-- END: this line ends content from: inc/head.default.html -->
|
||||
<!-- START: this line starts content from: inc/body.default.html -->
|
||||
|
||||
<body>
|
||||
|
||||
<!-- END: this line ends content from: inc/body.default.html -->
|
||||
<!-- START: this line starts content from: inc/header.default.html -->
|
||||
|
||||
<div class="header">
|
||||
<img src="../../png/ioccc.png" alt="IOCCC image by Matt Zucker" width=300 height=110>
|
||||
<h1>The International Obfuscated C Code Contest</h1>
|
||||
<h2>obfuscation.md for 2020/ferguson2</h2>
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/header.default.html -->
|
||||
<!-- START: this line starts content from: inc/topnav.up2index.html -->
|
||||
|
||||
<div class="topnav">
|
||||
<a class="Left" href="index.html">↑ jump to index.html ↑</a>
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/topnav.up2index.html -->
|
||||
<!-- START: this line starts content from: inc/begin-row.default.html -->
|
||||
|
||||
<div class="row">
|
||||
|
||||
<!-- END: this line ends content from: inc/begin-row.default.html -->
|
||||
<!-- START: this line starts content from: inc/begin-leftcolumn.default.html -->
|
||||
|
||||
<div class="leftcolumn">
|
||||
|
||||
<!-- END: this line ends content from: inc/begin-leftcolumn.default.html -->
|
||||
<!-- START: this line starts content from: inc/sidenav.default.html -->
|
||||
|
||||
<div class="sidenav">
|
||||
<a href="#content">Jump to contents</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="../../index.html">IOCCC Home</a>
|
||||
<a href="../../years.html">Winning Entries</a>
|
||||
<a href="../../authors.html">People who have won</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="../../news.html">IOCCC News</a>
|
||||
<a href="../../faq.html#submit">How to enter the IOCCC</a>
|
||||
<a href="../../faq.html">FAQ</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="../../bugs.html">Bugs & (mis)features</a>
|
||||
<a href="../../faq.html#fix_an_entry">Fixing IOCCC entries</a>
|
||||
<a href="../../faq.html#fix_web_site">Fixing the web site</a>
|
||||
<a href="../../faq.html#fix_author">Fixing author info</a>
|
||||
<a href="../../thanks-for-help.html">Thanks for the help</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="../../judges.html">The IOCCC Judges</a>
|
||||
<a href="../../contact.html">Contacting the IOCCC</a>
|
||||
</div>
|
||||
<hr>
|
||||
<div class="sidenav">
|
||||
<a href="#top">Jump to top</a>
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/sidenav.default.html -->
|
||||
<!-- START: this line starts content from: inc/end-leftcolumn.default.html -->
|
||||
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/end-leftcolumn.default.html -->
|
||||
<!-- START: this line starts content from: inc/begin-rightcolumn.default.html -->
|
||||
|
||||
<div class="rightcolumn">
|
||||
|
||||
<!-- END: this line ends content from: inc/begin-rightcolumn.default.html -->
|
||||
<!-- START: this line starts content from: inc/before-content.default.html -->
|
||||
|
||||
<a name="content"></a>
|
||||
|
||||
<!-- END: this line ends content from: inc/before-content.default.html -->
|
||||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
|
||||
<h1 id="obfuscation">Obfuscation</h1>
|
||||
<ul>
|
||||
<li><p>Strings identifying what it is are encrypted by the Enigma itself
|
||||
(with its default settings). The strings are: <code>Position</code>,
|
||||
<code>Setting</code>, <code>Ring</code>, <code>Plugboard pair</code>
|
||||
<code>Reflector</code>. Together these would be a dead giveaway to
|
||||
anyone familiar with the Enigma machine and some of them by themselves
|
||||
would be a dead giveaway too. I can’t even explain how I did this
|
||||
(although I’m sure at one point I could have) but I do think it’s pretty
|
||||
cool to have the text encrypted by the program and still be capable of
|
||||
printing it correctly all without giving anything away.</p></li>
|
||||
<li><p>Digraphs. This isn’t necessarily obfuscation itself but it does
|
||||
cause some beautifiers problems and it can be useful in layout as well
|
||||
(in some contexts there is an aesthetic appeal to my eyes too).</p></li>
|
||||
<li><p>Compound literal of ints of size 13 that have a variety of
|
||||
different data (including what was originally two arrays plus some
|
||||
additional ints).</p></li>
|
||||
<li><p>Negative pointer offsets. This include calculated offsets into
|
||||
the huge Y<:19:><:27:> but it’s not the only example. Here
|
||||
the compound literal of 13 ints:</p>
|
||||
<pre><code>int *z=(int[13]) { 0 } , *e, *g;</code></pre>
|
||||
<p>Then in main:</p>
|
||||
<pre><code>e = z + 10;
|
||||
g = e + 1;
|
||||
|
||||
for (j=-3; j < 0; ++j)
|
||||
e<:j:> = j+3;</code></pre>
|
||||
<p>Which I think is more confusing: when one is iterating an array you
|
||||
don’t expect to start out with index < 0 but to then compare that
|
||||
that index < 0 and increment until 0 along with setting the value of
|
||||
the array to j + 3 is more confusing still. There are at least two other
|
||||
ways that are much easier to read that could accomplish the same thing.
|
||||
It continues on:</p>
|
||||
<pre><code>/* ... */
|
||||
e<:i-3:> = (j < 1 ? 1 : (j > 5 ? 5 : j))-1;</code></pre></li>
|
||||
<li><p>Observe these two functions:</p>
|
||||
<pre><code>void w(char *s, int k, int v)
|
||||
{
|
||||
for(e<:2:> = 0; s<:*P:>; ++e<:2:>)
|
||||
{
|
||||
v = s<:e<:2:>:>;
|
||||
if(v > 64 && v < 91)
|
||||
s<:e<:2:>:> = (((v - 65 + k) % 26) + 65);
|
||||
}
|
||||
}
|
||||
void Q(void)
|
||||
{
|
||||
for(*g = 0; *g < 3; ++*g)
|
||||
{
|
||||
*Y<:16+e<:1:>:>=S<:e<:e<:1:>-3:>:>;
|
||||
R<:e<:1:>:>=Y<:e<:-3+e<:1:>:>:>;
|
||||
w(R[*g],*(e+e<:1:>-6)=q(Y<:8:>,*Y<:7:>),*g);
|
||||
}
|
||||
}</code></pre>
|
||||
<p>First of all: why do I set <code>e[2]</code> to 0 and increment it
|
||||
for each pass in the loop, but then the condition for the loop is
|
||||
<code>s[*P]</code>?</p>
|
||||
<p>Second notice the many references to e[1] (as e[1] and <em>g). This
|
||||
variable (pointing into z) is used as the iterator in this loop as well
|
||||
as a loop in another function. Now why do I pass </em>g to the function
|
||||
w()? To mislead. Originally it was more misleading in that I didn’t
|
||||
touch the parameter ‘v’ in the function and did a *g = v; at the end of
|
||||
the function. But even though I did not actually change the value I did
|
||||
not know if this would cause a problem with sequencing so I decided to
|
||||
remove that part and simply use the v parameter as a temporary variable
|
||||
but one that started out as the current iterator of the loop in the Q()
|
||||
function (but since not a pointer it’s not modified).</p>
|
||||
<p>Originally I went further than that but due to order of evaluation
|
||||
being unspecified I changed it to what it is now. Anyway:</p>
|
||||
<p>You can also see that I use the value of e[1]-3 as the index of S[e]
|
||||
(so S[e[e[1]-3]]) (I think I said that right; I honestly don’t know now
|
||||
because there is such major array and offset abuse. The entire prog.c is
|
||||
riddled with offset abuses.).</p></li>
|
||||
<li><p>If you observe that above the compound literal <code>z</code> is
|
||||
of size 13 but I point <code>e</code> to be <code>z + 10</code>. Why?
|
||||
Twofold: (1) I decided to make use of one of them as a temporary
|
||||
variable instead of a regular int in the function (so make it global);
|
||||
and (2) I didn’t want to risk changing all the offsets: thus I just made
|
||||
that address <code>e[1]</code>. Thus I also have:</p>
|
||||
<pre><code>for (*g = 0 ; *g < 10; ++*g)
|
||||
{
|
||||
r<:-2:> = Y<:14:><:*(e+1):>; r<:-3:> = Y<:15:><:1<:e:>:>;
|
||||
if (r<:-3:> && r<:-2:> == r<:-1:>)
|
||||
return r<:-3:>;
|
||||
if (r<:-2:> && r<:-3:> == r<:-1:>)
|
||||
return r<:-2:>;
|
||||
}</code></pre>
|
||||
<p>This <code>e[1]</code> of course is the same as <code>*g</code> as
|
||||
above and as you can see has multiple dimensions (that is the reference
|
||||
to Y does) too (and this is also strewn about the code). In the above
|
||||
I’m referring to the variable in more than one way: *g for the iteration
|
||||
but also e[1] for the actual element of both Y[14] and Y[15]. I also
|
||||
happen to use S (via r which points to S + 10) which I use as the two
|
||||
chars to compare (this is the plugboard function).</p></li>
|
||||
<li><p>The above function Z() takes a <code>char x</code> but you won’t
|
||||
notice it being used at all. Why? In fact I call it like so:</p>
|
||||
<pre><code>k = Z(r<:-1:>=k);</code></pre>
|
||||
<p>The char is just used as a way to be able to call the function and
|
||||
assign to the proper variable at the same time: in the function Z I
|
||||
don’t care about x because it’s the same value as r[-1] (which I do care
|
||||
about). Why is it attached to S? Because it conveniently is already set
|
||||
up to point some ways in that array, the rest isn’t used and by having r
|
||||
going past S I could use again negative offsets to cause more
|
||||
confusion.</p></li>
|
||||
<li><p>Although this is clearly already shown in the above there are
|
||||
other ways I refer to the same variable in more than one way (or in some
|
||||
cases maybe more correct to say ‘same location’). In the Z() function
|
||||
for example:</p>
|
||||
<pre><code>r<:-2:> = Y<:14:><:*(e+1):>; r<:-3:> = Y<:15:><:1<:e:>:>;</code></pre>
|
||||
<p>I refer to e[1] as both: *(e+1) and 1[e].</p></li>
|
||||
<li><p>Replacing a number of <code>if ..</code>s with
|
||||
<code>... && (...)</code>s (in one case at least it’s nested
|
||||
further:
|
||||
<code>f && (f = 0 && (a = W(A,a)));</code>).</p></li>
|
||||
<li><p>Three different char arrays in one: the rotors settings, the
|
||||
positions and the notches for each rotor. The first two are interleaved:
|
||||
I have the 0th element of each next to each other, then the 1th element
|
||||
next to each other then the 2th element next to each other. Then it’s
|
||||
the notch settings. The first two arrays here require some index
|
||||
calculations like <code>i+i%3</code> and <code>i+i+1</code> depending on
|
||||
which ‘array’ is needed. At other points I refer to those elements by
|
||||
direct index (sort of).</p></li>
|
||||
<li><p>Another set of char arrays in one: the five rotors as well as the
|
||||
two reflectors in one <code>char [][27]</code>. This makes for some fun
|
||||
code like:</p>
|
||||
<pre><code>(Y<:e<:-10:>+5:><:k-'A':>) && (k = Y<:e<:-10:>+5:><:k-'A':>);</code></pre>
|
||||
<p>(Of course this also removes an if statement by joining with a
|
||||
&&).</p></li>
|
||||
<li><p>In fact I decided that the above two arrays in arrays needed to
|
||||
be merged with the rest of the char arrays so that’s what I have done.
|
||||
They have different purposes and they’re referred to differently. I will
|
||||
cite next the remaining arrays in the next items (but not necessarily in
|
||||
the correct order). Notice that the array I’m talking about is the
|
||||
massive <code>Y<:19:><:27:></code>.</p></li>
|
||||
<li><p>The alphabet (this is one string).</p></li>
|
||||
<li><p>The plugboard (this is two arrays).</p></li>
|
||||
<li><p>The Enigma ciphered text for prompting for input (five
|
||||
strings).</p></li>
|
||||
<li><p>The relevant notches (this is not the same as the five notch
|
||||
letters!) (this is three chars but each in a different element of the
|
||||
<code>char Y[19][27]</code> - for why see below).</p></li>
|
||||
<li><p>I’m not even sure if there are any others due to the way I have
|
||||
done this; to save iocccsize bytes I have used the first element of
|
||||
three of the strings when I only did need the first element (since doing
|
||||
e.g. <code>f[3][2]</code> takes more bytes than <code>*f[3]</code> or
|
||||
whatever). All in all though there are 18 different strings (in some
|
||||
cases only the first char is relevant) in <code>char Y[19][27]</code>
|
||||
with a multitude of different uses. Some of these are as I noted
|
||||
scrambled. Some default to empty string which might hide that it’s even
|
||||
there.</p></li>
|
||||
<li><p>Although minor I have made use of the result of the end of a for
|
||||
loop in the beginning in the next loop in main(): <code>j</code> will
|
||||
end up being 0 and I need it at 9 so I do <code>j += 9</code> in the
|
||||
initialisation of the for loop instead of simply setting it to
|
||||
9.</p></li>
|
||||
<li><p>The judges don’t like obfuscation through the C preprocessor.
|
||||
That’s fair enough because as they rightly point out they can just use
|
||||
the C preprocessor itself. But although I have quite a few cpp
|
||||
directives I am not using them for obfuscation but rather to save bytes.
|
||||
For examples:</p>
|
||||
<pre><code>%:define J(x) do(*x)=getchar(); while((*x)=='\n')</code></pre>
|
||||
<p>Is used quite a number of times and although it could be a function
|
||||
that takes a pointer to an int it was more convenient this way (I
|
||||
believe it used more bytes but I no longer know that). There are many
|
||||
others and they all save bytes (or at least most of them do if not all).
|
||||
There is one in particular I want to bring up though because I think
|
||||
it’s a curious one and it ties in to another point above:</p>
|
||||
<pre><code>%:define A(y) *(&Y<:7:><:1:>+(y))</code></pre>
|
||||
<p>What is special about this one: Above I noted how I sort of refer
|
||||
directly to the notch settings (I think it was the notch settings
|
||||
anyway). Now I could have done say</p>
|
||||
<pre><code>char a = Y[7][1], b = Y[7][3], c = Y[7][5];</code></pre>
|
||||
<p>But I felt that doing instead the pointer arithmetic was worth doing.
|
||||
However it used significantly more bytes even as a macro: 17 if I recall
|
||||
right. That’s with the macro. If I were to include it three times by
|
||||
itself it’d be many more. I believe though that when the cpp translates
|
||||
it it still requires more thought to determine that a is set to Y[7][1],
|
||||
b to Y[7][3] and c to Y[7][5].</p></li>
|
||||
</ul>
|
||||
<h1 id="obfuscation-wrt-recode.c">Obfuscation wrt recode.c</h1>
|
||||
<ul>
|
||||
<li><p>To cause confusion I have used the same names of variables and
|
||||
functions (well recode.c has more functions and variables) but with
|
||||
different meanings. For example in recode.c <code>R</code> is a
|
||||
<code>char R[3]</code> but in prog.c it’s <code>char *R[3]</code>.
|
||||
Another example is where in prog.c <code>Y</code> is
|
||||
<code>char Y[19][27]</code> in recode.c it’s <code>char *Y[3]</code>.
|
||||
Some are use swaps but not necessarily all. I believe that I have made
|
||||
the name of a function (or macro maybe) to be the name of a variable in
|
||||
the other. Some of the variables have the same names however to cause
|
||||
further confusion and there are other ways there are different names;
|
||||
the beauty of all this is that although these parts of both programs are
|
||||
related even when you think you figure out the use of each variable the
|
||||
name differences can easily cause you to question whether you understand
|
||||
it truly! Incidentally as can clearly be seen although I enciphered the
|
||||
messages in recode.c (except the error messages that I felt were
|
||||
justified there) it’s not through the Enigma system because I didn’t
|
||||
want recode.c to give many hints as to how prog.c works. I don’t believe
|
||||
deciphering recode.c will explain how my entry works because recode.c
|
||||
doesn’t use the Enigma algorithm and even the strings are done very
|
||||
differently (and separated) so that one cannot easily replace the
|
||||
<code>char</code> variables in recode.c, move them to prog.c, compile
|
||||
and expect it to work right.</p></li>
|
||||
<li><p>Also what is this about ?</p>
|
||||
<pre><code> /\
|
||||
/ This is *not* what you think:
|
||||
void D(char*x){ /* ... */ }</code></pre>
|
||||
<p>Is that valid and if so how does it function? Yes it’s valid but I’ll
|
||||
leave the other part of the question up to the reader to answer. Hint:
|
||||
you already know how it works (yes, really you do)! Another hint: This
|
||||
is and is not a misleading comment (conversely this makes this hint both
|
||||
misleading - and also not).</p></li>
|
||||
</ul>
|
||||
<table>
|
||||
<colgroup>
|
||||
<col style="width: 100%" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td>(c) Copyright 1984-2020, [Leo Broukhis, Simon Cooper, Landon Curt
|
||||
Noll][judges] - All rights reserved This work is licensed under a
|
||||
[Creative Commons Attribution-ShareAlike 3.0 Unported License][cc].</td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td>[judges]: https://www.ioccc.org/judges.html [cc]:
|
||||
http://creativecommons.org/licenses/by-sa/3.0/</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<!-- 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 -->
|
||||
|
||||
<!-- END: this line ends content from: inc/after-content.default.html -->
|
||||
<!-- START: this line starts content from: inc/end-rightcolumn.default.html -->
|
||||
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/end-rightcolumn.default.html -->
|
||||
<!-- START: this line starts content from: inc/end-row.default.html -->
|
||||
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/end-row.default.html -->
|
||||
<!-- START: this line starts content from: inc/footer.default.html -->
|
||||
|
||||
<div class="footer">
|
||||
<hr>
|
||||
<h2>Coda</h2>
|
||||
<p><a href="https://validator.w3.org/nu/?doc=#">Nu HTML check this web page</a></p>
|
||||
<p><a href="#top">Jump to top</a> <a href="#content">Jump to Content</a> <a href="#inventory">Jump to Inventory</a></p>
|
||||
</div>
|
||||
|
||||
<!-- END: this line ends content from: inc/footer.default.html -->
|
||||
<!-- START: this line starts content from: inc/bottom.default.html -->
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
<!-- END: this line ends content from: inc/bottom.default.html -->
|
||||
Reference in new issue
Block a user