mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Various somewhat interconnected fixes

Browse Source 
At least one link in the FAQ was fixed (not to a file but a named
reference). The FAQ has not been checked entirely for broken links
because the changes have got a bit out of hand and an entire make www
will have to be performed due to a problem I discovered doing the below.
Other improvements were made.

When going through the FAQ for broken links another problem was
discovered, one that broke the scripts that rely on jstrdecode(1). These
have been fixed but need further testing with make www. Some index.html files
were modified; for why this can be done without make quick_readme2index
see below on what changed and why it could be done this way.

When going through the FAQ for broken links I discovered some
issues with some entries' synopsis. This means that a number of
index.html and .entry.json files have been updated. The reason the
index.html files could be modified without running the scripts which
would were broken due to the jstrdecode(1) issue (a missing option in
the scripts) is because I used sgit(1). However, a single README.md file
was modified and the index.html file was not modified just yet. That
will happen with make www. The change is not significant, however, so
this should be okay this time. As the next step is a long process I
therefore decided to commit these things to get them out of the way to
try and prevent the commit from being even larger.

Minor fixes in next/try.sh and next/try.alt.sh were also discovered when
going through the FAQ.

Minor typos were made in the FAQ.

The .gitignore file was also updated: with the last change I
accidentally made it so vim swap files without a filename are not
ignored. That means there have to be two vim swap file globs.
This commit is contained in:
Cody Boone Ferguson committed 2024-12-22 09:33:08 -08:00
1 parent 02df0785b2
commit 03694c587d
20 files changed
+175 -154
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

.gitignore
+1
View File
@@ -5,6 +5,7 @@
.auth.json
.info.json
.s[a-zA-Z][a-zA-Z0-9]
.*.s[a-zA-Z][a-zA-Z0-9]
.tmp.*
/NOTES
/archive/historic/[12][0-9][0-9][0-9]
1986/wall/.entry.json
+1 -1
View File
@@ -6,7 +6,7 @@
"dir" : "wall",
"entry_id" : "1986_wall",
"title" : "1986.wall",
"abstract" : "dvorak keyboard emulator",
"abstract" : "Dvorak keyboard emulator",
"author_set" : [
{
"author_handle" : "Larry_Wall"
1986/wall/index.html
+1 -1
View File
@@ -406,7 +406,7 @@
</a>
<h1>The International Obfuscated C Code Contest</h1>
<h2>1986/wall - Grand Prize - Most well rounded in confusion</h2>
<h3>dvorak keyboard emulator</h3>
<h3>Dvorak keyboard emulator</h3>
</div>
<!-- END: this line ends content from: inc/header.default.html -->
1987/lievaart/.entry.json
+1 -1
View File
@@ -6,7 +6,7 @@
"dir" : "lievaart",
"entry_id" : "1987_lievaart",
"title" : "1987.lievaart",
"abstract" : "very good othello player",
"abstract" : "very good Othello player",
"author_set" : [
{
"author_handle" : "Roemer_B_Lievaart"
1987/lievaart/index.html
+1 -1
View File
@@ -406,7 +406,7 @@
</a>
<h1>The International Obfuscated C Code Contest</h1>
<h2>1987/lievaart - Grand Prize</h2>
<h3>very good othello player</h3>
<h3>very good Othello player</h3>
</div>
<!-- END: this line ends content from: inc/header.default.html -->
1988/applin/.entry.json
+1 -1
View File
@@ -6,7 +6,7 @@
"dir" : "applin",
"entry_id" : "1988_applin",
"title" : "1988.applin",
"abstract" : "massive #define that includes itself prints table of primes",
"abstract" : "massive #define that includes itself and prints a table of primes",
"author_set" : [
{
"author_handle" : "Jack_Applin"
1988/applin/index.html
+1 -1
View File
@@ -406,7 +406,7 @@
</a>
<h1>The International Obfuscated C Code Contest</h1>
<h2>1988/applin - Best of Show</h2>
<h3>massive #define that includes itself prints table of primes</h3>
<h3>massive #define that includes itself and prints a table of primes</h3>
</div>
<!-- END: this line ends content from: inc/header.default.html -->
1991/westley/README.md
+4 -4
View File
@@ -110,8 +110,8 @@ Can you figure out why the board looks different than the
What happens if you make a move already made?
Now go try and draw or better yet win (without cheating which is very easy :-) )!
Why is win better than draw? Because everyone knows how to draw:
Now go try and draw or better yet win! Why is win better than draw? Because
everyone knows how to draw:
> **Professor Falken**: Did you ever play **tic-tac-toe**?
>
@@ -126,8 +126,8 @@ Why is win better than draw? Because everyone knows how to draw:
> **Jennifer**: Because it's a boring game. It's always a tie.
>
> **Falken**: Exactly. There's no way to win. The game itself is pointless. But
back at the [International Obfuscated C Code Contest judges' room](../../judges.html) they believe
that you can win **tic-tac-toe**, that there can be acceptable draws.
> back at the [International Obfuscated C Code Contest judges' room](../../judges.html) they believe
> that you can win **tic-tac-toe**, that there can be acceptable draws.
Try not to cheat (even though it's very easy :-) ), the computer has not learned
how to catch you doing it.
1994/dodsond1/.entry.json
+1 -1
View File
@@ -6,7 +6,7 @@
"dir" : "dodsond1",
"entry_id" : "1994_dodsond1",
"title" : "1994.dodsond1",
"abstract" : "plays a game of othello",
"abstract" : "plays a game of Othello",
"author_set" : [
{
"author_handle" : "Don_Dodson"
1994/dodsond1/index.html
+1 -1
View File
@@ -406,7 +406,7 @@
</a>
<h1>The International Obfuscated C Code Contest</h1>
<h2>1994/dodsond1 - Best game</h2>
<h3>plays a game of othello</h3>
<h3>plays a game of Othello</h3>
</div>
<!-- END: this line ends content from: inc/header.default.html -->
1994/dodsond2/.entry.json
+1 -1
View File
@@ -6,7 +6,7 @@
"dir" : "dodsond2",
"entry_id" : "1994_dodsond2",
"title" : "1994.dodsond2",
"abstract" : "Hunt the Wumpus (gziped source)",
"abstract" : "Hunt the Wumpus (gzipped source)",
"author_set" : [
{
"author_handle" : "Don_Dodson"
1994/dodsond2/index.html
+1 -1
View File
@@ -406,7 +406,7 @@
</a>
<h1>The International Obfuscated C Code Contest</h1>
<h2>1994/dodsond2 - Most obfuscated packaging</h2>
<h3>Hunt the Wumpus (gziped source)</h3>
<h3>Hunt the Wumpus (gzipped source)</h3>
</div>
<!-- END: this line ends content from: inc/header.default.html -->
1998/bas1/.entry.json
+1 -1
View File
@@ -6,7 +6,7 @@
"dir" : "bas1",
"entry_id" : "1998_bas1",
"title" : "1998.bas1",
"abstract" : "Outputs a gziped 3D beam maze in Postscript",
"abstract" : "Outputs a gzipped 3D beam maze in Postscript",
"author_set" : [
{
"author_handle" : "Bas_de_Bakker"
1998/bas1/index.html
+1 -1
View File
@@ -406,7 +406,7 @@
</a>
<h1>The International Obfuscated C Code Contest</h1>
<h2>1998/bas1 - Best encapsulation</h2>
<h3>Outputs a gziped 3D beam maze in Postscript</h3>
<h3>Outputs a gzipped 3D beam maze in Postscript</h3>
</div>
<!-- END: this line ends content from: inc/header.default.html -->
faq.html
+52 -46
View File
@@ -452,7 +452,7 @@
<ul>
<li><strong>Q 2.0</strong>: <a class="normal" href="#questions">What is the best way to ask a question about the IOCCC rules, guideline and tools?</a></li>
<li><strong>Q 2.1</strong>: <a class="normal" href="#feedback">How can I comment or make a suggestion on IOCCC rules, guidelines and tools?</a></li>
<li><strong>Q 2.2</strong>: <a class="normal" href="#warnings">Are there any compiler warnings that I should not worry about?</a></li>
<li><strong>Q 2.2</strong>: <a class="normal" href="#warnings">Are there any compiler warnings that I should not worry about in my submissions?</a></li>
<li><strong>Q 2.3</strong>: <a class="normal" href="#frequent-themes">What types of entries have been frequently submitted to the IOCCC?</a></li>
<li><strong>Q 2.4</strong>: <a class="normal" href="#rule_2_broken">How did an entry that breaks the size rule 2 win the IOCCC?</a></li>
<li><strong>Q 2.5</strong>: <a class="normal" href="#submissions">How many submissions do the judges receive for a given IOCCC?</a></li>
@@ -501,7 +501,7 @@
<ul>
<li><strong>Q 6.0</strong>: <a class="normal" href="#compile_errors">Why don’t certain IOCCC entries compile and/or run?</a>
<ul>
<li><strong>Q 6.1.1</strong>: <a class="normal" href="#macos_compile">Why do some IOCCC entries fail to compile under macOS?</a></li>
<li><strong>Q 6.1.1</strong>: <a class="normal" href="#macos">Why do some IOCCC entries fail to compile and/or run under macOS?</a></li>
</ul></li>
<li><strong>Q 6.2</strong>: <a class="normal" href="#weverything">Why do Makefiles use -Weverything with clang?</a></li>
</ul>
@@ -509,9 +509,9 @@
<ul>
<li><strong>Q 7.0</strong>: <a class="normal" href="#try">What are <code>try.sh</code> and <code>try.alt.sh</code> scripts and why should I use them?</a></li>
<li><strong>Q 7.1</strong>: <a class="normal" href="#sanity">An IOCCC entry messed up my terminal application, how do I fix this?</a></li>
<li><strong>Q 7.2</strong>: <a class="normal" href="#unsupported">Why does an IOCCC entry fail to run?</a>
<li><strong>Q 7.2</strong>: <a class="normal" href="#unsupported">Why does an IOCCC entry fail to compile and/or run?</a>
<ul>
<li><strong>Q 7.2.1</strong>: <a class="normal" href="#64bit">Why does an IOCCC entry fail to run on my 64-bit system?</a></li>
<li><strong>Q 7.2.1</strong>: <a class="normal" href="#64bit">Why does an IOCCC entry fail to compile and/or run on my 64-bit system?</a></li>
</ul></li>
<li><strong>Q 7.3</strong>: <a class="normal" href="#eof">How do I find out how to send interrupt/EOF etc. for entries that require it?</a></li>
<li><strong>Q 7.4</strong>: <a class="normal" href="#download">How do I download individual winning entries or all winning entries of a given year?</a></li>
@@ -913,7 +913,9 @@ program(s), clean up any files made by the program etc.</li>
<ul>
<li>run the program in a way you suggest. If you use the <code>try.sh</code> script
system, which we do like, you can have this rule invoke the script
(<code>./try.sh</code>).</li>
(<code>./try.sh</code>). See the
FAQ on the “<a href="#try_scripts">try.sh scripts system</a>”
for more details.</li>
</ul></li>
</ul>
<p>Although the <code>mkiocccentry(1)</code> tool only checks for those rules, the most up to
@@ -977,15 +979,15 @@ included in your submission), it can be helpful to include a <code>try.sh</code>
<li><a href="next/try.alt.sh">download example try.alt.sh</a></li>
</ul>
<p>The template <code>try.sh</code> script can be used as a starting point, or you can look at
some of the others in the website, to get some ideas.</p>
some of the others in past winning entries, to get some ideas.</p>
<p>It is not detrimental to your chances of winning if you do not include one as
not all submissions can make use of them. Nevertheless, it is helpful to include
ways to use your program, and if you have creative ways this can be a bonus. It
does not mean that a program that cannot be used with other programs is less
interesting or less likely to win, but we do enjoy interesting and creative uses
of submissions.</p>
ways to use your program and as submitted Makefiles should have a <code>try</code> rule, if
you have creative ways this can be a bonus. It does not mean that a program that
cannot be used with other programs is less interesting or less likely to win,
but we do enjoy interesting and creative uses of submissions.</p>
<p>If you have alternate code that you are including, then you can use the
<a href="next/try.alt.sh">try.alt.sh template</a> instead.</p>
<code>try.alt.sh</code> template as well.</p>
<p>We recommend that you include the use of these scripts in the <code>try</code> rule in the
example Makefile that you modify for your submission. See the
FAQ on “<a href="#makefile">submission Makefiles</a>.</p>
@@ -1102,9 +1104,9 @@ can be confusing or even seem overwhelming to some people.</p>
<p>The <a href="judges.html">IOCCC judges</a> do welcome questions about the IOCCC
and will be <strong>happy to help</strong>.</p>
<p>Chances are, if you have a question, there are a number of other people who
have similar questions. So we recommend first view the
have similar questions. So we recommend that you first view the
<a href="https://github.com/ioccc-src/winner/discussions">GitHub discussions for this repo</a>
so see if someone else asked already. Feel free to join in on such a discussion,
to see if someone else asked it already. Feel free to join in on such a discussion,
even if to just say:</p>
<blockquote>
<p>I have this question too.</p>
@@ -1162,7 +1164,7 @@ discussion</a>.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="forced_warnings">
<div id="warnings">
<h3 id="q-2.2-are-there-any-compiler-warnings-that-i-should-not-worry-about">Q 2.2: Are there any compiler warnings that I should not worry about?</h3>
<h3 id="q-2.2-are-there-any-compiler-warnings-that-i-should-not-worry-about-in-my-submissions">Q 2.2: Are there any compiler warnings that I should not worry about in my submissions?</h3>
</div>
</div>
<p>There are unfortunately some warnings that cannot be disabled; they are always
@@ -1347,37 +1349,37 @@ certainly more than 3.</p>
</div>
<p>In some years, the IOCCC judges discover a truly amazing IOCCC entry that
stands out among all of the other IOCCC entries received that year.
For such an IOCCC entry, the IOCCC judges award a “Grand Prize”
or “Best of Show award.</p>
<p>In 1984-1987, the grand prize winning entries are:</p>
For such an IOCCC entry, the IOCCC judges award a “<code>Grand Prize</code>”
or “<code>Best of Show award</code>”.</p>
<p>In 1984-1987, the “<code>Grand Prize</code>” winning entries are:</p>
<ul>
<li><a href="years.html#1984_mullender">1984/mullender</a></li>
<li><a href="years.html#1985_shapiro">1985/shapiro</a></li>
<li><a href="years.html#1986_wall">1986/wall</a></li>
<li><a href="years.html#1987_lievaart">1987/lievaart</a></li>
<li><a href="1984/mullender/index.html">1984/mullender</a></li>
<li><a href="1985/shapiro/index.html">1985/shapiro</a></li>
<li><a href="1986/wall/index.html">1986/wall</a></li>
<li><a href="1987/lievaart/index.html">1987/lievaart</a></li>
</ul>
<p>Starting from 1988, the entry we liked the most in that year is called
“Best of Show”. Here are the “Best of Show” entries:</p>
“<code>Best of Show</code>”. Here are the “<code>Best of Show</code>” entries:</p>
<ul>
<li><a href="years.html#1988_applin">1988/applin</a></li>
<li><a href="years.html#1989_jar.2">1989/jar.2</a></li>
<li><a href="years.html#1990_theorem">1990/theorem</a></li>
<li><a href="years.html#1991_brnstnd">1991/brnstnd</a></li>
<li><a href="years.html#1992_vern">1992/vern</a></li>
<li><a href="years.html#1996_august">1996/august</a></li>
<li><a href="years.html#1998_banks">1998/banks</a></li>
<li><a href="years.html#2000_jarijyrki">2000/jarijyrki</a></li>
<li><a href="years.html#2020_carlini">2020/carlini</a></li>
<li><a href="1988/applin/index.html">1988/applin</a></li>
<li><a href="1989/jar.2/index.html">1989/jar.2</a></li>
<li><a href="1990/theorem/index.html">1990/theorem</a></li>
<li><a href="1991/brnstnd/index.html">1991/brnstnd</a></li>
<li><a href="1992/vern/index.html">1992/vern</a></li>
<li><a href="1996/august/index.html">1996/august</a></li>
<li><a href="1998/banks/index.html">1998/banks</a></li>
<li><a href="2000/jarijyrki/index.html">2000/jarijyrki</a></li>
<li><a href="2020/carlini/index.html">2020/carlini</a></li>
</ul>
<p>In 1993, 1994 and 1995 the judges were unable to select a clear overall
winning entry. So to give a nod to the entry that had the highest approval ranking
from the judges, they used the following awards:</p>
<ul>
<li><a href="years.html#1993_rince">1993/rince</a> - Most Well Rounded</li>
<li><a href="years.html#1994_shapiro">1994/shapiro</a> - Most Well Rounded</li>
<li><a href="years.html#1995_leo">1995/leo</a> - Best Use of Obfuscation</li>
<li><a href="1993/rince/index.html">1993/rince</a> - <code>Most Well Rounded</code></li>
<li><a href="1994/shapiro/index.html">1994/shapiro</a> - <code>Most Well Rounded</code></li>
<li><a href="1995/leo/index.html">1995/leo</a> - <code>Best Use of Obfuscation</code></li>
</ul>
<p>These could be considered the ‘best entry’ for those years with 1 or
<p>These could be considered the ‘<code>best entry</code>’ for those years with 1 or
more other entries that came in close behind.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="announcing_winners">
@@ -2997,7 +2999,7 @@ There are only a few cases when <code>OK_to_edit</code> needs to be <code>false<
<p>Modifications of the <strong>original source code</strong> is only permitted it can
be shown at the file is not the true <strong>original source code</strong>.</p>
<p>See the
FAQ on “<a href="#original_source_file">original source code</a>”
FAQ on “<a href="#orig_c">original source code</a>”
for more information including how to open an <a href="https://github.com/ioccc-src/winner/issues">IOCCC issue</a>
if you believe the <strong>original source code</strong> is not a true original.</p>
<ul>
@@ -3216,12 +3218,12 @@ versions:</p>
<pre><code> make alt</code></pre>
<p>The following Makefile rules should be in all Makefiles:</p>
<ul>
<li>all: build the entry programs (main program and any supplementary program)</li>
<li>alt: build alternate code</li>
<li>clobber: clean up object files and all binary files (except for those that are
<li><code>all</code>: build the entry programs (main program and any supplementary program)</li>
<li><code>alt</code>: build alternate code</li>
<li><code>clobber</code>: clean up object files and all binary files (except for those that are
not compiled)</li>
<li>clean: a simpler version of <code>clobber</code> that only removes object files. <code>make clobber</code> depends on <code>clean</code> so running <code>make clobber</code> will invoke <code>make clean</code>.</li>
<li>everything: equivalent to <code>make all alt</code>.</li>
<li><code>clean</code>: a simpler version of <code>clobber</code> that only removes object files. <code>make clobber</code> depends on <code>clean</code> so running <code>make clobber</code> will invoke <code>make clean</code>.</li>
<li><code>everything</code>: equivalent to <code>make all alt</code>.</li>
</ul>
<p>Are there any other rules? You tell us!</p>
<p>The top level and the year (e.g. <code>1984/Makefile</code>, <code>1985/Makefile</code> etc.)
@@ -3872,7 +3874,7 @@ than Linux (due to versions and possibly other things)!</p>
<p>Given that your entry <strong>MUST</strong> work as documented, you may be safer to
say that your entry keeps the number of warnings and <code>-Wno-foo</code> options while
compiling with <code>clang -Weverything</code> at a minimum. You might want to say the
version number and platform too as an extra safety net. Because if you claim zero
version number and platform (OS and OS version) too as an extra safety net. Because if you claim zero
warnings, and we find a warning situation, this may diminish the value of your
entry as it is not as documented. Thus it might be wise to point this out and
if you can test it in multiple platforms (or versions of <code>clang</code>, see
@@ -3922,7 +3924,7 @@ help.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="no_support">
<div id="unsupported">
<h3 id="q-7.2-why-does-an-ioccc-entry-fail-to-run">Q 7.2: Why does an IOCCC entry fail to run?</h3>
<h3 id="q-7.2-why-does-an-ioccc-entry-fail-to-compile-andor-run">Q 7.2: Why does an IOCCC entry fail to compile and/or run?</h3>
</div>
</div>
<p>What may have worked years ago may not work well or work at all today.
@@ -3956,12 +3958,16 @@ for how to submit a fix to an IOCCC entry.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="64bit">
<div id="64-bit">
<h3 id="q-7.2.1-why-does-an-ioccc-entry-fail-to-run-on-my-64-bit-system">Q 7.2.1: Why does an IOCCC entry fail to run on my 64-bit system?</h3>
<div id="32bit">
<div id="32-bit">
<h3 id="q-7.2.1-why-does-an-ioccc-entry-fail-to-compile-andor-run-run-on-my-64-bit-system">Q 7.2.1: Why does an IOCCC entry fail to compile and/or run run on my 64-bit system?</h3>
</div>
</div>
</div>
</div>
<p>Unfortunately some older entries are non-portable and require 32-bit support or
32-bit binaries. A problem system here is macOS Catalina (10.15) as as of that
version macOS no longer supports 32-bit binaries. If the entry acts on a certain
32-bit binaries. A problem system here is that as of macOS Catalina (10.15)
macOS no longer supports 32-bit binaries. If the entry acts on a certain
type of binary, say ELF, then that will also be a problem depending on the
entry. For example <a href="2001/anonymous/index.html">2001/anonymous</a> requires 32-bit
ELF binaries.</p>
faq.md
+52 -46
View File
@@ -26,7 +26,7 @@ This is FAQ version **28.1.8 2024-12-07**.
## 2. [IOCCC Judging process](#judging)
- **Q 2.0**: <a class="normal" href="#questions">What is the best way to ask a question about the IOCCC rules, guideline and tools?</a>
- **Q 2.1**: <a class="normal" href="#feedback">How can I comment or make a suggestion on IOCCC rules, guidelines and tools?</a>
- **Q 2.2**: <a class="normal" href="#warnings">Are there any compiler warnings that I should not worry about?</a>
- **Q 2.2**: <a class="normal" href="#warnings">Are there any compiler warnings that I should not worry about in my submissions?</a>
- **Q 2.3**: <a class="normal" href="#frequent-themes">What types of entries have been frequently submitted to the IOCCC?</a>
- **Q 2.4**: <a class="normal" href="#rule_2_broken">How did an entry that breaks the size rule 2 win the IOCCC?</a>
- **Q 2.5**: <a class="normal" href="#submissions">How many submissions do the judges receive for a given IOCCC?</a>
@@ -74,15 +74,15 @@ This is FAQ version **28.1.8 2024-12-07**.
## 6. [Problems compiling IOCCC entries](#compile_problems)
- **Q 6.0**: <a class="normal" href="#compile_errors">Why don't certain IOCCC entries compile and/or run?</a>
- **Q 6.1.1**: <a class="normal" href="#macos_compile">Why do some IOCCC entries fail to compile under macOS?</a>
- **Q 6.1.1**: <a class="normal" href="#macos">Why do some IOCCC entries fail to compile and/or run under macOS?</a>
- **Q 6.2**: <a class="normal" href="#weverything">Why do Makefiles use -Weverything with clang?</a>
## 7. [Running IOCCC entries](#running_entries)
- **Q 7.0**: <a class="normal" href="#try">What are `try.sh` and `try.alt.sh` scripts and why should I use them?</a>
- **Q 7.1**: <a class="normal" href="#sanity">An IOCCC entry messed up my terminal application, how do I fix this?</a>
- **Q 7.2**: <a class="normal" href="#unsupported">Why does an IOCCC entry fail to run?</a>
- **Q 7.2.1**: <a class="normal" href="#64bit">Why does an IOCCC entry fail to run on my 64-bit system?</a>
- **Q 7.2**: <a class="normal" href="#unsupported">Why does an IOCCC entry fail to compile and/or run?</a>
- **Q 7.2.1**: <a class="normal" href="#64bit">Why does an IOCCC entry fail to compile and/or run on my 64-bit system?</a>
- **Q 7.3**: <a class="normal" href="#eof">How do I find out how to send interrupt/EOF etc. for entries that require it?</a>
- **Q 7.4**: <a class="normal" href="#download">How do I download individual winning entries or all winning entries of a given year?</a>
@@ -612,7 +612,9 @@ The following rules should exist in your Makefile:
- `try`
* run the program in a way you suggest. If you use the `try.sh` script
system, which we do like, you can have this rule invoke the script
(`./try.sh`).
(`./try.sh`). See the
FAQ on the "[try.sh scripts system](#try_scripts)"
for more details.
Although the `mkiocccentry(1)` tool only checks for those rules, the most up to
date
@@ -690,17 +692,17 @@ included in your submission), it can be helpful to include a `try.sh` script:
The template `try.sh` script can be used as a starting point, or you can look at
some of the others in the website, to get some ideas.
some of the others in past winning entries, to get some ideas.
It is not detrimental to your chances of winning if you do not include one as
not all submissions can make use of them. Nevertheless, it is helpful to include
ways to use your program, and if you have creative ways this can be a bonus. It
does not mean that a program that cannot be used with other programs is less
interesting or less likely to win, but we do enjoy interesting and creative uses
of submissions.
ways to use your program and as submitted Makefiles should have a `try` rule, if
you have creative ways this can be a bonus. It does not mean that a program that
cannot be used with other programs is less interesting or less likely to win,
but we do enjoy interesting and creative uses of submissions.
If you have alternate code that you are including, then you can use the
[try.alt.sh template](next/try.alt.sh) instead.
`try.alt.sh` template as well.
We recommend that you include the use of these scripts in the `try` rule in the
example Makefile that you modify for your submission. See the
@@ -869,9 +871,9 @@ The [IOCCC judges](judges.html) do welcome questions about the IOCCC
and will be **happy to help**.
Chances are, if you have a question, there are a number of other people who
have similar questions. So we recommend first view the
have similar questions. So we recommend that you first view the
[GitHub discussions for this repo](https://github.com/ioccc-src/winner/discussions)
so see if someone else asked already. Feel free to join in on such a discussion,
to see if someone else asked it already. Feel free to join in on such a discussion,
even if to just say:
> I have this question too.
@@ -945,7 +947,7 @@ Jump to: [top](#)
<div id="forced_warnings">
<div id="warnings">
### Q 2.2: Are there any compiler warnings that I should not worry about?
### Q 2.2: Are there any compiler warnings that I should not worry about in my submissions?
</div>
</div>
@@ -1185,39 +1187,39 @@ Jump to: [top](#)
In some years, the IOCCC judges discover a truly amazing IOCCC entry that
stands out among all of the other IOCCC entries received that year.
For such an IOCCC entry, the IOCCC judges award a "Grand Prize"
or "Best of Show award.
For such an IOCCC entry, the IOCCC judges award a "`Grand Prize`"
or "`Best of Show award`".
In 1984-1987, the grand prize winning entries are:
In 1984-1987, the "`Grand Prize`" winning entries are:
- [1984/mullender](years.html#1984_mullender)
- [1985/shapiro](years.html#1985_shapiro)
- [1986/wall](years.html#1986_wall)
- [1987/lievaart](years.html#1987_lievaart)
- [1984/mullender](1984/mullender/index.html)
- [1985/shapiro](1985/shapiro/index.html)
- [1986/wall](1986/wall/index.html)
- [1987/lievaart](1987/lievaart/index.html)
Starting from 1988, the entry we liked the most in that year is called
"Best of Show". Here are the "Best of Show" entries:
"`Best of Show`". Here are the "`Best of Show`" entries:
- [1988/applin](years.html#1988_applin)
- [1989/jar.2](years.html#1989_jar.2)
- [1990/theorem](years.html#1990_theorem)
- [1991/brnstnd](years.html#1991_brnstnd)
- [1992/vern](years.html#1992_vern)
- [1996/august](years.html#1996_august)
- [1998/banks](years.html#1998_banks)
- [2000/jarijyrki](years.html#2000_jarijyrki)
- [2020/carlini](years.html#2020_carlini)
- [1988/applin](1988/applin/index.html)
- [1989/jar.2](1989/jar.2/index.html)
- [1990/theorem](1990/theorem/index.html)
- [1991/brnstnd](1991/brnstnd/index.html)
- [1992/vern](1992/vern/index.html)
- [1996/august](1996/august/index.html)
- [1998/banks](1998/banks/index.html)
- [2000/jarijyrki](2000/jarijyrki/index.html)
- [2020/carlini](2020/carlini/index.html)
In 1993, 1994 and 1995 the judges were unable to select a clear overall
winning entry. So to give a nod to the entry that had the highest approval ranking
from the judges, they used the following awards:
- [1993/rince](years.html#1993_rince) - Most Well Rounded
- [1994/shapiro](years.html#1994_shapiro) - Most Well Rounded
- [1995/leo](years.html#1995_leo) - Best Use of Obfuscation
- [1993/rince](1993/rince/index.html) - `Most Well Rounded`
- [1994/shapiro](1994/shapiro/index.html) - `Most Well Rounded`
- [1995/leo](1995/leo/index.html) - `Best Use of Obfuscation`
These could be considered the 'best entry' for those years with 1 or
These could be considered the '`best entry`' for those years with 1 or
more other entries that came in close behind.
Jump to: [top](#)
@@ -3231,7 +3233,7 @@ Now we will describe each field of each file in the manifest:
be shown at the file is not the true **original source code**.
See the
FAQ on "[original source code](#original_source_file)"
FAQ on "[original source code](#orig_c)"
for more information including how to open an [IOCCC issue](https://github.com/ioccc-src/winner/issues)
if you believe the **original source code** is not a true original.
@@ -3503,13 +3505,13 @@ versions:
The following Makefile rules should be in all Makefiles:
- all: build the entry programs (main program and any supplementary program)
- alt: build alternate code
- clobber: clean up object files and all binary files (except for those that are
- `all`: build the entry programs (main program and any supplementary program)
- `alt`: build alternate code
- `clobber`: clean up object files and all binary files (except for those that are
not compiled)
- clean: a simpler version of `clobber` that only removes object files. `make
- `clean`: a simpler version of `clobber` that only removes object files. `make
clobber` depends on `clean` so running `make clobber` will invoke `make clean`.
- everything: equivalent to `make all alt`.
- `everything`: equivalent to `make all alt`.
Are there any other rules? You tell us!
@@ -4657,7 +4659,7 @@ than Linux (due to versions and possibly other things)!
Given that your entry **MUST** work as documented, you may be safer to
say that your entry keeps the number of warnings and `-Wno-foo` options while
compiling with `clang -Weverything` at a minimum. You might want to say the
version number and platform too as an extra safety net. Because if you claim zero
version number and platform (OS and OS version) too as an extra safety net. Because if you claim zero
warnings, and we find a warning situation, this may diminish the value of your
entry as it is not as documented. Thus it might be wise to point this out and
if you can test it in multiple platforms (or versions of `clang`, see
@@ -4726,7 +4728,7 @@ Jump to: [top](#)
<div id="no_support">
<div id="unsupported">
### Q 7.2: Why does an IOCCC entry fail to run?
### Q 7.2: Why does an IOCCC entry fail to compile and/or run?
</div>
</div>
@@ -4770,13 +4772,17 @@ Jump to: [top](#)
<div id="64bit">
<div id="64-bit">
### Q 7.2.1: Why does an IOCCC entry fail to run on my 64-bit system?
<div id="32bit">
<div id="32-bit">
### Q 7.2.1: Why does an IOCCC entry fail to compile and/or run run on my 64-bit system?
</div>
</div>
</div>
</div>
Unfortunately some older entries are non-portable and require 32-bit support or
32-bit binaries. A problem system here is macOS Catalina (10.15) as as of that
version macOS no longer supports 32-bit binaries. If the entry acts on a certain
32-bit binaries. A problem system here is that as of macOS Catalina (10.15)
macOS no longer supports 32-bit binaries. If the entry acts on a certain
type of binary, say ELF, then that will also be a problem depending on the
entry. For example [2001/anonymous](2001/anonymous/index.html) requires 32-bit
ELF binaries.
next/try.alt.sh
+2 -2
View File
@@ -1,9 +1,9 @@
#!/usr/bin/env bash
#
# try.alt.sh - demonstrate IOCCC entry YYYY/foo alternate code
# XXX - try.alt.sh example version: 1.0.0-1 11-28-2024 - XXX
# XXX - try.alt.sh example version: 1.0.0-1 11-28-2024 - XXX
#
# XXX - NOTE: if your submission wins and become an entry, then - XXX
# XXX - NOTE: if your submission wins and becomes an entry, then - XXX
# XXX - YYYY/foo will be changed to the 4 digit year and directory - XXX
# XXX - name. - XXX
# XXX - NOTE: please remove the XXX lines in this file, including this one - XXX
next/try.sh
+2 -2
View File
@@ -1,9 +1,9 @@
#!/usr/bin/env bash
#
# try.sh - demonstrate IOCCC entry YYYY/foo
# XXX - try.sh example version: 1.0.0-1 11-28-2024 - XXX
# XXX - try.sh example version: 1.0.0-1 11-28-2024 - XXX
# XXX - NOTE: if your submission wins and become an entry, then - XXX
# XXX - NOTE: if your submission wins and becomes an entry, then - XXX
# XXX - YYYY/foo will be changed to the 4 digit year and directory - XXX
# XXX - name. - XXX
# XXX - NOTE: please remove the XXX lines in this file, including this one - XXX
thanks-for-help.html
+25 -21
View File
@@ -5053,8 +5053,10 @@ compilers. See the index.html for more details.</p>
</div>
<p>Jump to: <a href="#">top</a></p>
<div id="makefiles_fixes_improvements">
<div id="makefiles">
<h2 id="makefiles-fixes-and-improvements">Makefiles fixes and improvements</h2>
</div>
</div>
<p><a href="#cody">Cody</a> fixed the top level <code>Makefile</code> <code>all</code> rule which had a stray <code>fi;</code>
without an <code>if</code> so the rule failed entirely.</p>
<p>Cody also made a variety of other changes in all the Makefiles, sometimes to get
@@ -5172,29 +5174,30 @@ helped improve the presentation of their fellow IOCCC entries.</p>
</div>
<p>We call out the extensive contributions of <a href="authors.html#Cody_Boone_Ferguson">Cody Boone
Ferguson</a> who is responsible for many
improvements and fixes, including entries that no longer worked
and other important fixes, often <strong>EXTREMELY HARD</strong> (for certain
improvements and fixes, including fixing many <a href="faq.html#unsupported">entries that no longer
worked</a>,
often <strong>EXTREMELY HARD</strong> (for certain
definitions of ‘<code>HARD</code>’ :-) ), such as
<a href="thanks-for-help.html#1988_phillipps">1988/phillipps</a>,
<a href="thanks-for-help.html#1992_vern">1992/vern</a>,
<a href="thanks-for-help.html#2001_anonymous">2001/anonymous</a>,
<a href="thanks-for-help.html#2004_burley">2004/burley</a> and
<a href="thanks-for-help.html#2005_giljade">2005/giljade</a>; fixing entries such as
<a href="thanks-for-help.html#2005_giljade">2005/giljade</a>; fixing entries like
<a href="thanks-for-help.html#1985_sicherman">1985/sicherman</a> and
<a href="thanks-for-help.html#1986_wall">1986/wall</a> to
not require <code>-traditional-cpp</code>; fixing
entries like <a href="thanks-for-help.html#1991_dds">1991/dds</a> to work with <code>clang</code> (or, as in the case of
entries like <a href="thanks-for-help.html#1991_dds">1991/dds</a> to work with
<a href="faq.html#clang">clang</a> (or, as in the case of
<a href="thanks-for-help.html#1989_westley">1989/westley</a>, a true masterpiece in
obfuscation, to work as much as possible); porting entries such as
<a href="thanks-for-help.html#1998_schweikh1">1998/schweikh1</a> to macOS; fixing code like
<a href="thanks-for-help.html#2001_herrmann2">2001/herrmann2</a> to work in both 32-bit and
64-bit; providing <a href="faq.html#alt_code">alternate code</a> where useful/necessary;
improving all <code>Makefiles</code>; and writing scripts to greatly simplify running many
of the entries.</p>
obfuscation, to work as much as possible); porting entries like
<a href="thanks-for-help.html#1998_schweikh1">1998/schweikh1</a> to
<a href="faq.html#macos_compile">macOS</a>; fixing code like
<a href="thanks-for-help.html#2001_herrmann2">2001/herrmann2</a> to work in <a href="faq.html#32bit">both 32-bit and
64-bit</a>; providing <a href="faq.html#alt_code">alternate code</a> where useful/necessary;
improving all <a href="#makefiles">Makefiles</a>; writing <a href="#try">scripts</a> to greatly simplify running many
of the entries; and other important fixes.</p>
<p>Cody also wrote the feature-rich <a href="https://github.com/xexyl/sgit">sgit</a> to easily
run <code>sed(1)</code> on files in the repo which we used to help build the website. He
also co-developed the <a href="faq.html#jparse">JSON parser and tools</a> with us, as the
website makes extensive use of JSON.</p>
run <code>sed(1)</code> on files in the repo which we used earlier on to help build the website.</p>
<p>Cody Boone Ferguson also used one of his own tools to detect many dead links.
While the tool was not perfect it went a long way to uncover a good number of
bad, broken or otherwise invalid links. It was a very laborious task to copy and
@@ -5206,14 +5209,15 @@ invalid links are thanks to Cody’s efforts! Another tool he wrote detected
inconsistent award titles in the <code>README.md</code> files (used to generate the
<code>index.html</code> files) and the CSV file that he generated from our SQL file.</p>
<p>Cody also greatly improved the manifests and checked that the generated html
files look well and are presentable, suggested some CSS rules for
image responsiveness on smaller screens along with some other improvements,
greatly improved the FAQ.</p>
<p>Cody also wrote some of the <a href="bin/index.html">website scripts</a> and improved and
bug fixed others.</p>
files look good and are presentable, suggested CSS rules for
image responsiveness and other improvements, and greatly improved the FAQ.</p>
<p>Cody also wrote some of the <a href="bin/index.html">website scripts</a>, improved and
bug fixed others, co-developed the <a href="https://github.com/xexyl/jparse">JSON parser and tools</a> with
us, as we now make extensive use of JSON, and helped test and fix the submit
server for IOCCC28 and beyond.</p>
<p><strong>THANK YOU VERY MUCH</strong> for your extensive efforts in helping improve the IOCCC
presentation of past IOCCC entries and fixing almost all entries that no
longer worked, for modern systems!</p>
presentation of past IOCCC entries, fixing almost all entries that no
longer worked and getting the IOCCC where it is today!</p>
<p>Jump to: <a href="#">top</a></p>
<div id="yusuke">
<h3 id="yusuke-endoh">Yusuke Endoh</h3>
@@ -5221,7 +5225,7 @@ longer worked, for modern systems!</p>
<p><a href="authors.html#Yusuke_Endoh">Yusuke Endoh</a> supplied a
number of important bug fixes to a number of past IOCCC entries, including
<strong>fixing <em>numerous entries</em> that no longer worked</strong>. Some of those
fixes were <strong>EXTREMELY TECHNICALLY CHALLENGING</strong>, such as
fixes were <strong>EXTREMELY TECHNICALLY CHALLENGING</strong>, like
<a href="thanks-for-help.html#1989_robison">1989/robison</a>,
<a href="thanks-for-help.html#1990_cmills">1990/cmills</a>,
<a href="thanks-for-help.html#1992_lush">1992/lush</a> and
thanks-for-help.md
+25 -21
View File
@@ -6944,8 +6944,10 @@ Jump to: [top](#)
Jump to: [top](#)
<div id="makefiles_fixes_improvements">
<div id="makefiles">
## Makefiles fixes and improvements
</div>
</div>
[Cody](#cody) fixed the top level `Makefile` `all` rule which had a stray `fi;`
without an `if` so the rule failed entirely.
@@ -7111,30 +7113,31 @@ Jump to: [top](#)
We call out the extensive contributions of [Cody Boone
Ferguson](authors.html#Cody_Boone_Ferguson) who is responsible for many
improvements and fixes, including entries that no longer worked
and other important fixes, often **EXTREMELY HARD** (for certain
improvements and fixes, including fixing many [entries that no longer
worked](faq.html#unsupported),
often **EXTREMELY HARD** (for certain
definitions of '`HARD`' :-) ), such as
[1988/phillipps](thanks-for-help.html#1988_phillipps),
[1992/vern](thanks-for-help.html#1992_vern),
[2001/anonymous](thanks-for-help.html#2001_anonymous),
[2004/burley](thanks-for-help.html#2004_burley) and
[2005/giljade](thanks-for-help.html#2005_giljade); fixing entries such as
[2005/giljade](thanks-for-help.html#2005_giljade); fixing entries like
[1985/sicherman](thanks-for-help.html#1985_sicherman) and
[1986/wall](thanks-for-help.html#1986_wall) to
not require `-traditional-cpp`; fixing
entries like [1991/dds](thanks-for-help.html#1991_dds) to work with `clang` (or, as in the case of
entries like [1991/dds](thanks-for-help.html#1991_dds) to work with
[clang](faq.html#clang) (or, as in the case of
[1989/westley](thanks-for-help.html#1989_westley), a true masterpiece in
obfuscation, to work as much as possible); porting entries such as
[1998/schweikh1](thanks-for-help.html#1998_schweikh1) to macOS; fixing code like
[2001/herrmann2](thanks-for-help.html#2001_herrmann2) to work in both 32-bit and
64-bit; providing [alternate code](faq.html#alt_code) where useful/necessary;
improving all `Makefiles`; and writing scripts to greatly simplify running many
of the entries.
obfuscation, to work as much as possible); porting entries like
[1998/schweikh1](thanks-for-help.html#1998_schweikh1) to
[macOS](faq.html#macos_compile); fixing code like
[2001/herrmann2](thanks-for-help.html#2001_herrmann2) to work in [both 32-bit and
64-bit](faq.html#32bit); providing [alternate code](faq.html#alt_code) where useful/necessary;
improving all [Makefiles](#makefiles); writing [scripts](#try) to greatly simplify running many
of the entries; and other important fixes.
Cody also wrote the feature-rich [sgit](https://github.com/xexyl/sgit) to easily
run `sed(1)` on files in the repo which we used to help build the website. He
also co-developed the [JSON parser and tools](faq.html#jparse) with us, as the
website makes extensive use of JSON.
run `sed(1)` on files in the repo which we used earlier on to help build the website.
Cody Boone Ferguson also used one of his own tools to detect many dead links.
While the tool was not perfect it went a long way to uncover a good number of
@@ -7148,16 +7151,17 @@ inconsistent award titles in the `README.md` files (used to generate the
`index.html` files) and the CSV file that he generated from our SQL file.
Cody also greatly improved the manifests and checked that the generated html
files look well and are presentable, suggested some CSS rules for
image responsiveness on smaller screens along with some other improvements,
greatly improved the FAQ.
files look good and are presentable, suggested CSS rules for
image responsiveness and other improvements, and greatly improved the FAQ.
Cody also wrote some of the [website scripts](bin/index.html) and improved and
bug fixed others.
Cody also wrote some of the [website scripts](bin/index.html), improved and
bug fixed others, co-developed the [JSON parser and tools](https://github.com/xexyl/jparse) with
us, as we now make extensive use of JSON, and helped test and fix the submit
server for IOCCC28 and beyond.
**THANK YOU VERY MUCH** for your extensive efforts in helping improve the IOCCC
presentation of past IOCCC entries and fixing almost all entries that no
longer worked, for modern systems!
presentation of past IOCCC entries, fixing almost all entries that no
longer worked and getting the IOCCC where it is today!
Jump to: [top](#)
@@ -7170,7 +7174,7 @@ Jump to: [top](#)
[Yusuke Endoh](authors.html#Yusuke_Endoh) supplied a
number of important bug fixes to a number of past IOCCC entries, including
**fixing _numerous entries_ that no longer worked**. Some of those
fixes were **EXTREMELY TECHNICALLY CHALLENGING**, such as
fixes were **EXTREMELY TECHNICALLY CHALLENGING**, like
[1989/robison](thanks-for-help.html#1989_robison),
[1990/cmills](thanks-for-help.html#1990_cmills),
[1992/lush](thanks-for-help.html#1992_lush) and