Cody Boone Ferguson
06a5665f5d
As both Landon and I have been wondering if changing entries to use
fgets() is bordering on tampering with entries I decided to make the
original (sometimes bug fixed) versions (using gets()) alt code. I had
originally started to make the fgets() version of each entry the alt but
since the fgets() versions can handle input better and since some also
fixed bugs (see below) I decided to make the original version the alt
code (this also is how it is for other entries).
There were some exceptions here. If the change also fixed some crashes
or other bugs outside of the gets() to fgets() conversion I did not
bother to make an alt version. An example is 1992/dds. In some cases the
alt code does have bug fixes in which case they were added.
Updated the Makefiles and .gitignore files as well for the alt target
and the new files (compiled and in the case of 1992/adrian additional
source files in the Makefile alt rule).
This should solve the problem observed by Landon and me. It wouldn't be
a problem to change it so the alt version is the one that uses fgets()
but I think that might be the wrong choice.
In some entries I altogether avoided changing to fgets() say if the
author notes it uses gets() (in one case even providing a version that
uses fgets()). In some cases using fgets() introduces a bug so those are
also not changed.
As for 1990/tbr there's a strong reason for not having the fgets()
version being the alt. In macOS in particular (in linux - or maybe gcc,
not sure - it shows a warning at linker time) it will mess up the first
line of output in a potentially confusing way. For instance:
$ ./tbr.alt
$ warning: this program uses gets(), which is unsafe.
# nothing here, what to do?
And that touches on another issue of making the alt version the one that
uses gets(): the warnings that can be alarming during compilation,
linking and (in the case of macOS) runtime.
Not all entries should be or can be changed to fgets() but some can and
it's warranted for these reasons. More will possibly happen in the
future.
2000 marked the "The Fifteenth International Obfuscated C Code Contest"
Standard IOCCC stuff
Look at the README.md file for the given winner for information on how to compile the winner 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 comments for even more details.
Use make to compile entries. It is possible that on non-Un*x / non-Linux systems the makefile needs to be changed. See the Makefile for details.
Read over the makefile for compile/build issues. Your system may require certain changes (add or remove a library, add or remove a #define).
Some ANSI C compilers are not quite as good as they should be. If yours is lacking, you may need to compile using gcc instead of your local compiler.
New Judge
The judges were unable to contact Jeremy Horn for judging the 2000 contest.
As a result, Simon Cooper:
http://www.sfik.com/
joined our team. Simon is well known for being a co-author of the 2nd edition of the Building Internet Firewalls book.
Remarks on some of the entries
There were some outstanding entries that did not win. Unfortunately some very good entries lost because they:
+ depended too much on non-portable side effects in expressions;
+ depended too much on a particular byte order;
+ required the use of a special script, data file or pseudo-machine
language that was not supplied with the entry.
We hope the authors of some of those entries will fix and re-submit them for the next IOCCC.
We believe you will be impressed with this year's winners. The Best of Show is a fine example of compact obfuscation. But don't ignore the shorter winners. The Best Small Program, Best Abuse of User and Most Complete Program are well worth studying in detail.
The Worst Abuse of the Rules is technically allowed by the rules. We gave it an award this year, but don't assume you can get away with using it next time ... :-)
Speaking of time, be sure to check out the Astronomically Obfuscated and the Most Timely Output.
There was no 1999 contest
So what happened to 1999? Landon Curt Noll was scheduled to take a vacation from the IOCCC this year. The remaining judges were unable to contact Jeremy Horn, so the IOCCC stalled.
But thanks to Landon's returning early from his IOCCC vacation (Landon will take a full IOCCC vacation during some other year), Simon Cooper joining the IOCCC judging team as well as the hard work of Peter Seebach and Leonid A. Broukhis the judging was completed in Dec 2000.
It was decided that the 15th contest would be the year 2000 contest (the year the judging completed) rather than year 1999 (the initial scheduled start of the contest). That is why there is no 1999 contest.
Final Comments
Please send us comments and suggestions what we have expressed above. Also include anything else that you would like to see in future contests. Send such email to:
questions@ioccc.org
If you use, distribute or publish these entries in some way, please drop us a line. We enjoy seeing who, where and how the contest is used.
You must include the words ``ioccc question'' in the subject of your email message when sending email to the judges.
If you have problems with any of the entries, AND YOU HAVE A FIX, please email the fix (patch file or the entire changed file) to the above address.
The next IOCCC is planned to start towards early spring 2001. Watch:
http://www.ioccc.org/
for news of the next contest.
=-=
p.s. The has been mentioned in an Amici Curiae for the DeCSS case. See:
http://cryptome.org/mpaa-v-2600-bac.htm
and seach on the word ioccc (twice).
=-=
Copyright (C) Landon Curt Noll, Simon Cooper, Peter Seebach and Leonid A. Broukhis, 2000. All Rights Reserved. Permission for personal, educational or non-profit use is granted provided this copyright and notice are included in its entirety and remains unaltered. All other uses must receive prior permission from the contest judges.