Landon Curt Noll
a78d78ccff
Regarding use of `temp-test-ioccc` in current repo files: We will ignore files under `tmp/` as they are going away. We will ignore files under `bin/` as they will have their default `REPO_URL` value changed during the later parts of the **Great Fork Merge**. We will ignore `*.html` files as the above changes to `bin/` tool will also change them during the later parts of the **Great Fork Merge**. We will ignore `sitemap.xml` as the it will change during the later parts of the **Great Fork Merge**. So this leaves for our consideration the files printed by this command: ```sh find * -type f ! -name '*.html' ! -name sitemap.xml ! -path 'tmp/*' ! -path 'bin/*' -print0 | xargs -0 grep -l 'temp-test-ioccc' ``` We see 5 (3 sir), 3 cases: * README.md index.md The reference to `temp-test-ioccc` will be removed when a given section goes away as part of the later parts of the **Great Fork Merge**. Nothing needs to be dome here other than to add some **XXX** comments to help remind us of what needs to be done in later parts of the **Great Fork Merge**. * bugs.md faq.md news.md var.mk The use of `temp-test-ioccc` is outside of a blob. Here `https://github.com/ioccc-src/temp-test-ioccc/` may be be replaced by `https://github.com/ioccc-src/winner/` in anticipation of the **Great Fork Merge**. There is an exception: The historic discussion abouts the history of the `temp-test-ioccc` repo needs to retain their `https://github.com/ioccc-src/temp-test-ioccc/` strings in `faq.md` and `news.md`. * 2005/sykes/README.md The markdown links that start with `https://github.com/ioccc-src/temp-test-ioccc/blob/master/` should instead start with `%%REPO_URL%%/`. After the **Great Fork Merge**, the `%%REPO_URL%%/` value will refer to `https://github.com/ioccc-src/winner/blob/master/` instead. * 2020/ferguson1/snake.1 There is not a tool to "pre-process" cat pages like there is for markdown files: no should there be. The cat page refers to a markdown file when instead it should refer to a HTML page. In this case we suggest that `https://github.com/ioccc-src/temp-test-ioccc/blob/` be replaced by `https://www.isthe.com/`, and `.md` be replaced by `.html` in anticipation of what it will need to be after the **Great Fork Merge**. * YYYY/entry_dir/*.sh The shell scripts references by the above command are "helper shell scripts. Like man pages, there is no "pre-processor" for shell scripts, nor should there be. Looking at these helper shell script files in detail: ```sh find * -name '*.sh' ! -path 'tmp/*' ! -path 'bin/*' -print0 | xargs -0 grep 'temp-test-ioccc/blob/master' ``` We see that they all make references to `faq.md#something.`. This is wrong in 2 ways: 0) They should not refer to the markdown file `faq.md` but rather to the HTML file `faq.html`. 1) They punctuate a literal string (with one exception) by adding a final period (".") to a string that requires somebody to copy and paste and exclude the final period ("."). Since these echo commands are suggesting that the user view something within the FAQ, we recommend that `echo "Tip: see https://github.com/ioccc-src/temp-test-ioccc/blob/master/faq.md#` be replaced by `echo "Tip: see https://www.ioccc.org/faq.html#` AND that the final period (".") be removed. Thus they too will anticipate what they will need to be after the **Great Fork Merge**.
Twenty Fifth International Obfuscated C Code Contest
Standard IOCCC stuff
View the index.html web page for the given winning entry for information on how
compile the entry 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. This year we included most of the
information included by the submitter.
The primary site can be found at www.ioccc.org.
Use make to compile entries. It is possible that on non-Unix / non-Linux
systems the Makefile needs to be changed. See the Makefile for details.
Look at the source and try to figure out what the programs do, and run them with various inputs.
Read over the Makefile and index.html files for compile/build issues. Your
system may require certain changes (add or remove a library, add or remove a
#define).
Some C compilers are not quite as good as they should be. If yours is lacking, you may need to compile using clang or gcc instead of your local compiler.
Remarks on some of the winning entries
We believe you will again be impressed with this year's winning entries.
The Best of show - 2018/mills is an amazing tribute to entries from 1984 and 2015.
Take a close look at the Most likely to top the charts - 2018/hou. Observe that while it contains no variables and no operators, it remains functional in what it does.
The Best one-liner - 2018/burton1, at 109 characters, is a short and sweet implementation of a classic utility and a nod to a winning entry from 1986. Sometimes it takes 20 some years to do things the true IOCCC way.
The color of the remarks text this year was inspired by one of the stars of the Most stellar - 2018/poikola.
The Best use of python - 2018/endoh2 is a not what you might think it is. It is something completely different.
The Most likely to be awarded - 2018/ciura has an amazing vocabulary!
There are also nods to entries of the years 2000/bellard, 2015/yang, ...
...We'll stop spouting spoilers now. Have fun exploring all the entries!
Remarks on some of submissions that did not win
The number of entries that would have made it into the final rounds would have been much higher had some people paid attention to rules 2 and 22 (one third of 666).
Rule 22, now known as "Catch 22" states:
22) Your source code, data files, remarks and program output must NOT
identify the authors of your code. The judges STRONGLY prefer to
not know who is submitting entries to the IOCCC.
The "Peter Honeyman is exempt" guideline also applies to this rule.
Identifying yourself, in an obvious way in your code, data, remarks
or program output, unless you are Peter Honeyman or pretending
to be Peter Honeyman, will be grounds for disqualification of your entry.
A number of other entries were based on iocccsize.c, making derivative works rather than original works.
Still other entries were too large, violating the first line of rule 2:
2) The size of your program source must be <= 4096 bytes in length.
While these entries might have passed under the 2053 limit for iocccsize, they were larger than <= 4096 bytes, sometimes by an order or magnitude.
We hope the authors of some of those entries will fix and re-submit them for the next IOCCC.
Some entries seemed to have a good idea, but the implementation of the idea was limited in scope.
Final Comments
IMPORTANT NOTE: See contact.html for up to date contact details as well as details on how to provide fixes to any of the entries. See also the IOCCC FAQ for additional information on the IOCCC.