Merge pull request #2244 from xexyl/readmes
Format / typo check YYYY/README.md files
This commit is contained in:
23 files changed
+164
-161
No files matched your search
+1
-1
@@ -6,7 +6,7 @@ contest was simply "`First annual Obfuscated C Code Contest`".
|
||||
View the `index.html` web page for the given winning entry for information on how
|
||||
to compile it and how to run the winning program. Look at the winning
|
||||
source and try to figure how it does what it does! This year we only had
|
||||
remarks from two authors but which came years later.
|
||||
remarks from two authors but these came years later.
|
||||
|
||||
Restrictions against machine dependent code were not in the [rules](rules.txt)
|
||||
in 1984. The source file size restriction was only 512 bytes. Rules and results
|
||||
|
||||
+2
-1
@@ -13,7 +13,8 @@ The practice of posting a preliminary set of rules for the next year was started
|
||||
this year.
|
||||
|
||||
[Rules](rules.txt) and results were posted to comp.lang.c and comp.unix.wizards
|
||||
with an announcement in news.announce.important. Micro/Systems Journal
|
||||
with an announcement in news.announce.important.
|
||||
[Micro/Systems Journal](https://www.vintage-computer.com/publications.php?microsystemsjournal)
|
||||
published the 1987 winning entries. [Mark R.
|
||||
Horton](https://www.amazon.com/stores/Mark-R.-Horton/author/B001HPGRB8) included
|
||||
a version of the [1987 winning entries](../years.html#1987) in an appendix of his C book
|
||||
|
||||
+1
-1
@@ -7,7 +7,7 @@ You may then wish to look at the Author's remarks for even more details.
|
||||
|
||||
The maximum size of entries was raised from 1024 to 1536 bytes, however smaller
|
||||
entries were encouraged. Due to the ["Best Abuse of the Rules" entry of
|
||||
1987](../1987/biggar/), a limit of 160 chars in the compile line was introduced.
|
||||
1987](/1987/biggar/index.html), a limit of 160 chars in the compile line was introduced.
|
||||
|
||||
This year, the Grand Prize was given to the most unusual entry and best
|
||||
abuse of the C Preprocessor rather than the most well rounded entry.
|
||||
|
||||
+3
-4
@@ -11,15 +11,14 @@ System V or non-Unix systems the Makefile needs to be changed).
|
||||
This year, the Grand Prize was given to the most useful program.
|
||||
|
||||
The ["Strangest abuse of the rules"](jar.1/indx.html) award was given this year
|
||||
to stress the fact that starting in 1990, compiling entries must result an
|
||||
executable regular file.
|
||||
to stress the fact that starting in 1990, compiling entries must result a
|
||||
regular executable file.
|
||||
|
||||
The Makefile always uses the portable version of the ["Best
|
||||
self modifying program"](fubar/indx.html) because there is no loss of functionality in
|
||||
using it. In the case of the ["Best game"](tromp/README) entry, however, some
|
||||
functionality is lost in the portable version and so the Makefile uses
|
||||
the original program. System V users may need to change the Makefile
|
||||
to use the s5 version. See the hint files or the Makefile for details.
|
||||
the original program.
|
||||
|
||||
[Rules](rules.txt) and results were posted to comp.lang.c, comp.sources.unix, and
|
||||
alt.sources. They have been made available on a wide number of USENET
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ Instructions for use: Run `make` to compile entries. It is possible that
|
||||
on BSD or non-Unix systems the Makefile needs to be changed.
|
||||
|
||||
This year, we did not single out an entry that was better than all of
|
||||
the rest. We selected 3 entries that were, in our opinion, went beyond
|
||||
the rest. We selected 3 entries that, in our opinion, went beyond
|
||||
all of the other entries this year:
|
||||
|
||||
- [Grand Prize](westley/index.html) by [Brian
|
||||
|
||||
+5
-2
@@ -13,12 +13,15 @@ certain changes (add or remove a library, add or remove a `#define` i.e. the
|
||||
`-D` flag). A number of compilers had problems optimizing certain entries.
|
||||
Some compilers do optimize, but the resulting program does not work. By default
|
||||
we have left off `-O` from compile lines. You might want to add `-O` back, or
|
||||
add it back for certain entries where performance is important.
|
||||
add it back for certain entries where performance is important. (This was
|
||||
updated to use `-O3` in 202n though sometimes an entry does not work if the
|
||||
compiler optimises the code and in this case it is disabled or explicitly set to
|
||||
level 0.)
|
||||
|
||||
This year marked an all time high for number of entries as well as the
|
||||
quality of entries. Nearly twice the usual number of entries made it
|
||||
to the final judging rounds. Even when we raised the standards for
|
||||
winning, we still wound up giving out a few more awards than in other
|
||||
winning, we still wound up giving out a few more awards than in previous
|
||||
years. The new size rules size probably contributed to the overall
|
||||
high quality.
|
||||
|
||||
|
||||
+1
-1
@@ -60,7 +60,7 @@ See also [the IOCCC FAQ](../faq.html) for addition information on the IOCCC.
|
||||
### Credits:
|
||||
|
||||
We would like to thank Barbara Frezza for her role as official chef
|
||||
of the contest. Landon Noll and Larry Bassel appreciated the opportunity
|
||||
of the contest. Landon Curt Noll and Larry Bassel appreciated the opportunity
|
||||
to serve as official taste testers. And as usual, the food was excellent.
|
||||
|
||||
|
||||
|
||||
+3
-3
@@ -39,7 +39,7 @@ The ideal 3rd judge would have all of the following:
|
||||
|
||||
* thorough knowledge of the C language (ANSI and K&R)
|
||||
* thorough knowledge of common C libs (libc, libm, curses, ...)
|
||||
* reasonable written communication skills (able to write `README.md` files)
|
||||
* reasonable written communication skills (able to write `README.md` files, for example)
|
||||
* appreciation for well-written non-obfuscated code
|
||||
* willing to devote ~4 weekend days in January (starting Jan 96) for judging
|
||||
* located in the San Francisco (California, US) Bay Area, or
|
||||
@@ -112,7 +112,7 @@ judges@toad.com
|
||||
```
|
||||
|
||||
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.
|
||||
us a line. We enjoy seeing who, where and how the contest is used,
|
||||
as well as details on how to provide fixes to any of the entries.
|
||||
|
||||
|
||||
@@ -128,7 +128,7 @@ See also [the IOCCC FAQ](../faq.html) for addition information on the IOCCC.
|
||||
## Credits
|
||||
|
||||
We would like to thank Barbara Frezza for her role as official chef
|
||||
of the contest. Landon Noll and Larry Bassel appreciated the opportunity
|
||||
of the contest. Landon Curt Noll and Larry Bassel appreciated the opportunity
|
||||
to serve as official taste testers. And as usual, the food was excellent.
|
||||
The official menu of the 1994 Obfuscated C Contest dinner:
|
||||
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ no longer post the winning entries to this newsgroup - we'll let you the reader
|
||||
for yourself the wizardry of these entries.
|
||||
|
||||
This year there were several people who won more than once and several [previous
|
||||
winning entries](../authors.html) as well. The judging was done without knowledge of the
|
||||
winning authors](../authors.html) as well. The judging was done without knowledge of the
|
||||
names of the submitters - multiple winning entries were a coincidence. Since we tend to
|
||||
discount entries that are similar to previous entries, these people had to come
|
||||
with original ideas to stay in the winning entry circle.
|
||||
|
||||
+1
-2
@@ -8,8 +8,7 @@ on how to compile it 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.
|
||||
|
||||
The IOCCC has an official home page: [www.ioccc.org](https://www.ioccc.org)
|
||||
|
||||
The IOCCC has an official home page: [www.ioccc.org](https://www.ioccc.org),
|
||||
containing previous winning entries, information about the judges,
|
||||
announcements and much more.
|
||||
|
||||
|
||||
+6
-8
@@ -8,7 +8,7 @@ on how to compile it 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.
|
||||
|
||||
The IOCCC has its own domain. The IOCCC has an official home page is now:
|
||||
The IOCCC has its own domain. The IOCCC has an official home page:
|
||||
[www.ioccc.org](https://www.ioccc.org).
|
||||
|
||||
Use `make` to compile entries. It is possible that on BSD or non-Unix
|
||||
@@ -35,9 +35,9 @@ Landon was unable to contact Sriram Srinivasan at the start of
|
||||
the 1998 IOCCC season. Having not heard from Sriram, Landon put out
|
||||
a call for new IOCCC judges. A number of excellent people applied.
|
||||
|
||||
Landon selected Leonid A. Broukhis, a two time IOCCC author, as a
|
||||
Landon selected Leonid A. Broukhis, a two time IOCCC winning author, as a
|
||||
co-judge. Landon and Leo together selected Jeremy Horn and Peter
|
||||
Seebach. The four judges (../judges.html) together worked
|
||||
Seebach. The four [judges](https://www.ioccc.org/judges.html) together worked
|
||||
thru-out the 1998 IOCCC season.
|
||||
|
||||
|
||||
@@ -64,7 +64,7 @@ for the fact that they didn't work. If you didn't win, but think you
|
||||
had a chance: test your program, fix it and submit it next year!
|
||||
|
||||
This year we awarded some outstanding entries. We recommend that you
|
||||
look at all of the winning enties. The list of winning entries is a bit too long to
|
||||
look at all of the winning entries. The list of winning entries is a bit too long to
|
||||
say something about every entry. On the other hand a partial mention
|
||||
of a few is in order:
|
||||
|
||||
@@ -76,7 +76,7 @@ of a few is in order:
|
||||
impressed with CPP code expansion liked the entry that translated
|
||||
lambda expressions into combinator expressions.
|
||||
- Logic minded folks will get somewhat twisted up while following the
|
||||
flow of the [Best Flow Control entry](1998/schnitzi/index.html).
|
||||
flow of the [Best Flow Control entry](schnitzi/index.html).
|
||||
- Those who know the PostScript language will be 'bemused' by
|
||||
the [Best Encapsulation entry](bas1/index.html).
|
||||
|
||||
@@ -124,9 +124,7 @@ You must include the words 'ioccc question' in the subject of your email
|
||||
message when sending email to the judges.
|
||||
|
||||
The next IOCCC is planned to start towards the end of 1999. Watch
|
||||
[www.ioccc.org](https://www.ioccc.org)
|
||||
|
||||
for news of the next contest.
|
||||
[www.ioccc.org](https://www.ioccc.org) for news of the next contest.
|
||||
|
||||
|
||||
# Copyright and License
|
||||
|
||||
+5
-6
@@ -13,7 +13,7 @@ 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).
|
||||
`#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
|
||||
@@ -24,10 +24,9 @@ local compiler.
|
||||
|
||||
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.
|
||||
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
|
||||
@@ -55,7 +54,7 @@ using it next time ... :-)
|
||||
|
||||
Speaking of time, be sure to check out the [Astronomically
|
||||
Obfuscated](rince/index.html) and the [Most Timely
|
||||
Output](schneiderwent/index.html).
|
||||
Output](schneiderwent/index.html) entries.
|
||||
|
||||
|
||||
## There was no 1999 contest
|
||||
|
||||
+1
-1
@@ -39,7 +39,7 @@ them for the next IOCCC.
|
||||
We believe you will be impressed with this year's winning entries The [Best of
|
||||
Show](ollinger/index.html) is a fine example of obfuscation. But don't ignore
|
||||
the other entries! There are games, programs that speak, ones that compile code
|
||||
and [one that might run binaries you already have](2001/anonymous/index.html).
|
||||
and [one that _might_ run binaries you already have](2001/anonymous/index.html).
|
||||
|
||||
The [Best/Worst Abuse of the Rules](bellard/index.html) is technically allowed by the
|
||||
[rules](rules.txt). This year we awarded it again, but don't assume you can get
|
||||
|
||||
+16
-15
@@ -31,41 +31,42 @@ We believe you will be impressed with this year's winning entries.
|
||||
|
||||
In particular:
|
||||
|
||||
+ The [Abuse of the rules](klausler/klausler.c) used local dictionary data to
|
||||
+ The [Abuse of the rules (klausler)](klausler/index.html) used local dictionary data to
|
||||
get around the size limit.
|
||||
|
||||
+ The [Most beauteous visuals](vince/vince.c) made clever use of `{}`s and
|
||||
+ The [Most beauteous visuals (vince)](vince/index.html) made clever use of `{}`s and
|
||||
whitespace in their source code and during execution.
|
||||
|
||||
+ The [Most circuitous walk](vik/vik.c) entry is just amazing.
|
||||
+ The [Most circuitous walk (vik)](vik/index.html) entry is just amazing.
|
||||
|
||||
+ The [Best game](toledo/toledo.c) makes full use of its single function.
|
||||
+ The [Best game (toledo)](toledo/index.html) makes full use of its single function.
|
||||
|
||||
+ The [Best emulator](sykes) may allow you to reconnect to your first
|
||||
+ The [Best emulator (sykes)](sykes/index.html) may allow you to reconnect to your first
|
||||
[PET](https://en.wikipedia.org/wiki/Commodore_PET).
|
||||
|
||||
+ Our [Best of Show](persano/persano.c) this year was simply (or non-simply :-) ) the best!
|
||||
+ Our [Best of Show (persano)](persano/index.html) this year was simply (or non-simply :-) ) the best!
|
||||
|
||||
+ (And we need only mention (parenthetically speaking) that the best use of parenthesis is self reproducing).
|
||||
+ (And we need only mention (parenthetically speaking) that the [Best use of
|
||||
parenthesis](mikeash/index.html) is self reproducing).
|
||||
|
||||
+ The [Most sonorous output](jetro/jetro.c) might `sound` :-) like a good idea.
|
||||
+ The [Most sonorous output (jetro)](jetro/index.html) might `sound` :-) like a good idea.
|
||||
|
||||
+ The [Best 2D puzzle](giljade/giljade.c) takes editorial license with expressions as well as the
|
||||
+ The [Best 2D puzzle (giljade)](giljade/index.html) takes editorial license with expressions as well as the
|
||||
with the [vi editor](https://en.wikipedia.org/wiki/Vi).
|
||||
|
||||
+ The [Most ambiguous language](chia/chia.c) entry is really a C program.
|
||||
+ The [Most ambiguous language (chia)](chia/index.html) entry is really a C program.
|
||||
|
||||
+ The [Most superfluous output](boutines/boutines.c) entry is simply
|
||||
+ The [Most superfluous output (boutines)](boutines/index.html) entry is simply
|
||||
[Voronoi](Voronoi)-lific!
|
||||
|
||||
+ Try not to have your sense of good coding offended by the [Most
|
||||
discourteous interpreter](timwi/timwi.c) entry.
|
||||
discourteous interpreter (timwi)](timwi/index.html) entry.
|
||||
|
||||
+ The [Best use of the www](mynx/mynx.c) doesn't include those letters.
|
||||
+ The [Best use of the www (mynx)](mynx/index.html) doesn't include those letters.
|
||||
|
||||
+ You will be puzzled by the [Best 3D puzzle](anon/anon.c) entry; we are sure!
|
||||
+ You will be puzzled by the [Best 3D puzzle (anon)](anon/index.html) entry; we are sure!
|
||||
|
||||
+ The [Most ingenious puzzle solution](aidan/aidan.c) might puzzle you more while it
|
||||
+ The [Most ingenious puzzle solution (aidan)](aidan/index.html) might puzzle you more while it
|
||||
puzzles out some puzzles: all in a puzzling way! :-)
|
||||
|
||||
### Remarks on some of the losing entries
|
||||
|
||||
+1
-1
@@ -18,7 +18,7 @@ This year we included most of the information included by the submitters
|
||||
in the `README.md` files (that were used to build the `index.html` web pages).
|
||||
|
||||
Read over the Makefile for compile/build issues. Your system may require
|
||||
certain changes (add or remove a library, add or remove a #define).
|
||||
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
|
||||
|
||||
+3
-2
@@ -18,7 +18,7 @@ This year we included most of the information included by the submitters
|
||||
in the `README.md` files (that were used to build the `index.html` web pages).
|
||||
|
||||
Read over the Makefile for compile/build issues. Your system may require
|
||||
certain changes (add or remove a library, add or remove a #define).
|
||||
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
|
||||
@@ -41,7 +41,8 @@ them for the next IOCCC.
|
||||
|
||||
We believe you will be impressed with this year's winning entries. The Best
|
||||
of Show is a fine example of character stitching. But don't ignore the other
|
||||
entries! There are games, puzzle solvers, utilities, eye candy, calculators and graphical and audio tools.
|
||||
entries! There are games, puzzle solvers, utilities, eye candy, calculators and
|
||||
graphical and audio tools.
|
||||
|
||||
This year all authors are different, and there is a authors from a new country -
|
||||
China! Many authors won for the first time. (Please note that judging is done
|
||||
|
||||
+5
-5
@@ -15,7 +15,7 @@ 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.
|
||||
|
||||
Read over the Makefile for compile/build issues. Your system may require
|
||||
certain changes (add or remove a library, add or remove a #define).
|
||||
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
|
||||
@@ -33,7 +33,7 @@ This year we selected the top 4 entries for particularly high honors:
|
||||
* Gold award - Balanced use of obfuscation
|
||||
|
||||
A very extremely subtle and twisted piece of source code!
|
||||
Even if you start with the zeitak_deobfucate.c source,
|
||||
Even if you start with the zeitak.alt.c source,
|
||||
you will still have a very challenging time to understand it!
|
||||
|
||||
* Silver award - Most elementary use of C
|
||||
@@ -55,9 +55,9 @@ This year we selected the top 4 entries for particularly high honors:
|
||||
But don't ignore the other winning entries! There are games, utilities,
|
||||
eye candy, calculators and graphical tools to explore.
|
||||
|
||||
This year, Yusuke Endoh won with two entries, one of which (endoh1)
|
||||
won the special Honorable mention award. Eight of the winning entries
|
||||
were from people who won in previous years.
|
||||
This year, Yusuke Endoh won with two entries, one of which
|
||||
([endoh1](endoh1/index.html)) won the special Honorable mention award. Eight of
|
||||
the winning entries were from people who won in previous years.
|
||||
|
||||
This year we had a number of authors from Asia. We saw our second
|
||||
authors from China and first from Korea. We are pleased to see
|
||||
|
||||
+12
-12
@@ -11,16 +11,16 @@ the Author's remarks for even more details.
|
||||
The IOCCC has a web site and now has a number of international mirrors.
|
||||
The primary site can be found at [www.ioccc.org](https://www.ioccc.org).
|
||||
|
||||
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.
|
||||
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. If you want to, look at the hints files for
|
||||
spoilers - this year we included most of the information included
|
||||
by the submitter.
|
||||
|
||||
Read over the makefile for compile/build issues. Your system may require
|
||||
certain changes (add or remove a library, add or remove a #define).
|
||||
Read over the README.md 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
|
||||
@@ -38,14 +38,14 @@ authors submitted very different styles of entries.
|
||||
|
||||
This year was the second time the IOCCC size tool was used. Rule 2
|
||||
required that when program source is fed as input to the current IOCCC size
|
||||
tool, and the IOCCC size tool -i command line option is used, the value
|
||||
tool, and the IOCCC size tool `-i` command line option is used, the value
|
||||
printed should be less than or equal to 2053.
|
||||
|
||||
We were pleased to see that abuse of the rules was extended to abuse
|
||||
to the IOCCC size tool. Matt Zucker, followed by a few users, were
|
||||
able to discover cleaver use of certain // comments to perplex the size tool.
|
||||
The abuse was so bad that the judges released a critical and mandatory
|
||||
patch to the IOCCC size tool on 2014-09-23.
|
||||
We were pleased to see that abuse of the rules was extended to abuse to the
|
||||
IOCCC size tool. [Matt Zucker](../authors.html#Matt_Zucker), followed by a few
|
||||
users, were able to discover clever use of certain `//` comments to perplex the
|
||||
size tool. The abuse was so bad that the judges released a critical and
|
||||
mandatory patch to the IOCCC size tool on 2014-09-23.
|
||||
|
||||
There were some great entries that did not win. Unfortunately
|
||||
some entries lost because they:
|
||||
@@ -71,7 +71,7 @@ in some particularly impressive way.
|
||||
|
||||
We apologize on the delay of sending the authors the tarball for them
|
||||
to review. There were some unforeseen events, such as unplanned mandatory
|
||||
business travel, the death of a IOCCC judge mother, etc. that impacted
|
||||
business travel, the death of an IOCCC judge's mother, etc. that impacted
|
||||
our planned schedule for building the tarball of this year's winning entries.
|
||||
|
||||
During some of these forced delays, we took the time to better automate
|
||||
@@ -81,7 +81,7 @@ these changes made during those delays will make releasing future winning IOCCC
|
||||
entries a faster procedure.
|
||||
|
||||
p.s. The final advice given to Landon by his mom: "Have fun."
|
||||
We recommend following this advice were possible.
|
||||
We recommend following this advice where possible.
|
||||
|
||||
|
||||
## Final Comments
|
||||
|
||||
+26
-25
@@ -6,21 +6,20 @@
|
||||
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.
|
||||
the Author's remarks for even more details. This year we included most of the
|
||||
information included by the submitter.
|
||||
|
||||
The IOCCC has a web site and now has a number of international mirrors.
|
||||
The primary site can be found at [www.ioccc.org](https://www.ioccc.org).
|
||||
|
||||
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.
|
||||
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. If you want to, look at the hints files for
|
||||
spoilers - this year we included most of the information included
|
||||
by the submitter.
|
||||
them with various inputs.
|
||||
|
||||
Read over the makefile for compile/build issues. Your system may require
|
||||
certain changes (add or remove a library, add or remove a #define).
|
||||
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
|
||||
@@ -33,28 +32,28 @@ We believe you will again be impressed with this year's winning entries.
|
||||
|
||||
The fraction of worthy entries was higher than usual.
|
||||
|
||||
We call to your attention, the _hou_ entry, that performs the MD5
|
||||
cryptographic hash. Normally implemented with a set of integer and
|
||||
boolean operations, this code uses floating point variables inside
|
||||
a single while loop filled with unusual constants, cosine, square
|
||||
root, and exponent function calls. The number of lines of code
|
||||
is also smaller than the original algorithm.
|
||||
We call to your attention the [hou](hou/index.html) entry that performs the MD5
|
||||
cryptographic hash. Normally implemented with a set of integer and boolean
|
||||
operations, this code uses floating point variables inside a single `while` loop
|
||||
filled with unusual constants, cosine, square root, and exponent function calls.
|
||||
The number of lines of code is also smaller than the original algorithm.
|
||||
|
||||
The _mills2_ source code is a very compressed version of a decompression
|
||||
algorithm. We think those who enjoy compression algorithms will
|
||||
The [mills2](mills2/index.html) source code is a very compressed version of a
|
||||
decompression algorithm. We think those who enjoy compression algorithms will
|
||||
particularly enjoy this entry.
|
||||
|
||||
We suggest that you attempt to completely understand the _endoh4_
|
||||
1-liner program: another impressive compact piece of C code.
|
||||
We suggest that you attempt to completely understand the
|
||||
[endoh4](endoh4/index.html) 1-liner program: another impressive compact piece of
|
||||
C code.
|
||||
|
||||
And while you are at it, cat the _endoh2_ prog.c code. Compile it
|
||||
And while you are at it, cat the [endoh2 prog.c](endoh2/prog.c) code. Compile it
|
||||
and look at the source code again.
|
||||
|
||||
In a "Back to the Future" moment, _endoh3_ gave us a twist on one of
|
||||
the all time best IOCCC entries from 1984.
|
||||
In a "Back to the Future" moment, [endoh3](endoh3/index.html) gave us a twist on
|
||||
one of the all time best IOCCC entries from 1984.
|
||||
|
||||
We also suggest that you take a very good look at how the _muth_ code
|
||||
makes full use of the C Pre-Processor.
|
||||
We also suggest that you take a very good look at how the
|
||||
[muth](muth/index.html) code makes full use of the C Pre-Processor.
|
||||
|
||||
...We'll stop spouting spoilers now. Have fun exploring all the entries!
|
||||
|
||||
@@ -78,12 +77,14 @@ Rule 22, now known as **Catch 22** states:
|
||||
| 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.
|
||||
A number of other entries were based on [iocccsize.c](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.
|
||||
|
||||
+26
-24
@@ -6,7 +6,8 @@
|
||||
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.
|
||||
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](https://www.ioccc.org).
|
||||
|
||||
@@ -14,12 +15,11 @@ 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. If you want to, look at the hints files for
|
||||
spoilers - this year we included most of the information included
|
||||
by the submitter.
|
||||
them with various inputs.
|
||||
|
||||
Read over the Makefile for compile/build issues. Your system may require
|
||||
certain changes (add or remove a library, add or remove a #define).
|
||||
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
|
||||
@@ -30,24 +30,24 @@ compiler.
|
||||
|
||||
We believe you will again be impressed with this year's winning entries.
|
||||
|
||||
The "Best of show" (mills) is an amazing tribute to entrues
|
||||
The ["Best of show" (mills)](mills/index.html) is an amazing tribute to entries
|
||||
from 1984 and 2015.
|
||||
|
||||
Take a close look at the "Most likely to top the charts" [2018/hou](hou/index.html)
|
||||
Take a close look at the "[Most likely to top the charts" (hou)](hou/index.html).
|
||||
Observe that while it contains no variables and no operators, it
|
||||
remains functional in what it does.
|
||||
|
||||
The "Best one-liner" (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 ox years to do things the true IOCCC way.
|
||||
The ["Best one-liner" (burton1)](burton1/index.html), 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](poikola/index.html).
|
||||
of the ["Most stellar" (poikola)](poikola/index.html).
|
||||
|
||||
The "Best use of python" (endoh2) is a not what you might think it is.
|
||||
The ["Best use of python" (endoh2)](endoh2/index.html) is a not what you might think it is.
|
||||
It is something completely different.
|
||||
|
||||
The "Most likely to be awarded" (ciura) has an amazing vocabulary!
|
||||
The ["Most likely to be awarded" (ciura)](ciura/index.html) has an amazing vocabulary!
|
||||
|
||||
There are also nods to entries of the years [2000/bellard](2000/bellard/index.htmk),
|
||||
[1989/yang](1989/yang/index.html), ...
|
||||
@@ -63,21 +63,23 @@ 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.
|
||||
```
|
||||
| 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.
|
||||
| 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.
|
||||
A number of other entries were based on [iocccsize.c](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.
|
||||
> 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.
|
||||
|
||||
+15
-10
@@ -13,8 +13,9 @@ The primary site can be found at [www.ioccc.org](https://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.
|
||||
|
||||
Read over the Makefile for compile/build issues. Your system may require
|
||||
certain changes (add or remove a library, add or remove a #define).
|
||||
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
|
||||
@@ -25,9 +26,11 @@ compiler.
|
||||
|
||||
This year's winning entries are impressive!
|
||||
|
||||
The "Most in need of debugging" (endoh) is very inventive in a way it produces its own text!
|
||||
The ["Most in need of debugging" (endoh)](endoh/index.html) is very inventive in
|
||||
a way it produces its own text!
|
||||
|
||||
The "Most likely to be awarded" (ciura) has an amazing vocabulary!
|
||||
The ["Most likely to be awarded" (ciura)](ciura/index.html) has an amazing
|
||||
vocabulary!
|
||||
|
||||
There are again nods to entries of the years:
|
||||
|
||||
@@ -36,12 +39,14 @@ There are again nods to entries of the years:
|
||||
|
||||
These nods to not run afoul of the guideline:
|
||||
|
||||
We tend to dislike programs that:
|
||||
...
|
||||
are rather similar to previous entries
|
||||
```
|
||||
We tend to dislike programs that:
|
||||
...
|
||||
are rather similar to previous entries
|
||||
```
|
||||
|
||||
because the entry [2019/dogon](2019/dogon/index.html) appropriately pays homage to past entries
|
||||
without blatantly reusing their code.
|
||||
because the entry [2019/dogon](2019/dogon/index.html) appropriately pays homage
|
||||
to past entries without blatantly reusing their code.
|
||||
|
||||
...We'll stop spouting spoilers now. Have fun exploring all the entries!
|
||||
|
||||
@@ -56,7 +61,7 @@ uninitialized locals and/or reading-writing below the stack.
|
||||
We advise running your entry through valgrind to make sure those mistakes
|
||||
are avoided.
|
||||
|
||||
Using extra arguments to main, or arguments of wrong types as a quick and dirty
|
||||
Using extra arguments to `main`, or arguments of wrong types as a quick and dirty
|
||||
way of declaring variables is now passé. Clang, for example, rejects them outright.
|
||||
|
||||
We hope the authors of some of those entries will fix and re-submit
|
||||
|
||||
+26
-18
@@ -13,8 +13,9 @@ The primary site can be found at [www.ioccc.org](https://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.
|
||||
|
||||
Read over the Makefile for compile/build issues. Your system may require
|
||||
certain changes (add or remove a library, add or remove a #define).
|
||||
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
|
||||
@@ -23,37 +24,42 @@ compiler.
|
||||
|
||||
## Remarks on some of the winning entries
|
||||
|
||||
This year's Best of Show (carlini) is such a novel way of obfuscation that it would be
|
||||
worth of a special mention in the (future) Best of IOCCC list!
|
||||
This year's [Best of Show (carlini)](carlini/index.html) is such a novel way of
|
||||
obfuscation that it would be worth of a special mention in the (future) Best of
|
||||
IOCCC list!
|
||||
|
||||
For some reason, this year's set of winning entries contains three nostalgic games,
|
||||
Asteroids (tsoj), Minesweeper (endoh1), and Snake (ferguson1).
|
||||
[Asteroids (tsoj)](tsoj/index.html), [Minesweeper (endoh1)](endoh1/index.html),
|
||||
and [Snake (ferguson1)](ferguson1/index.html).
|
||||
|
||||
An entry (kurdyukov1) pays homage to a previous entry [2015/hou](2015/hou/index.htm0).
|
||||
An entry ([kurdyukov1](kurdyukov1/index.html)) pays homage to previous entry
|
||||
[2015/hou](2015/hou/index.htm0).
|
||||
|
||||
...We'll stop spouting spoilers now. Have fun exploring all the entries!
|
||||
|
||||
|
||||
## Remarks on some of submissions that did not win
|
||||
|
||||
As a rule, we try to compile the entries on a variety of platforms.
|
||||
Quite a few entries this year could not be built or executed on some of them due to reliance on
|
||||
library internals or the system runtime.
|
||||
As a rule, we try to compile the entries on a variety of platforms. Quite a few
|
||||
entries this year could not be built or executed on some of them due to reliance
|
||||
on library internals or the system runtime.
|
||||
|
||||
A few entries were violating the "2053 significant bytes" rule. If an entry could not be brought to
|
||||
compliance within a few seconds of looking at the source, it was disqualified.
|
||||
A few entries were violating the "2053 significant bytes" rule. If an entry
|
||||
could not be brought to compliance within a few seconds of looking at the
|
||||
source, it was disqualified.
|
||||
|
||||
One entry tried to get around the size limit by putting the code into
|
||||
Makefile variables and using -D. This is already called out as discouraged
|
||||
Makefile variables and using `-D`. This is already called out as discouraged
|
||||
technique in the guidelines, but it is worth a reminder.
|
||||
|
||||
Several promising entries attempted to make use of the `syscall` function using literal syscall numbers.
|
||||
This is utterly non-portable.
|
||||
Several promising entries attempted to make use of the `syscall` function using
|
||||
literal syscall numbers. This is utterly non-portable.
|
||||
|
||||
A note to the authors: when submitting multiple entries, don't let us easily correlate them by
|
||||
coding style or documentation content, and definitely don't submit nearly identical versions
|
||||
of your program separately. As we try to judge the entries anonymously, the similarities will cause such
|
||||
entries to compete against one another, making each less likely to win.
|
||||
A note to the authors: when submitting multiple entries, don't let us easily
|
||||
correlate them by coding style or documentation content, and definitely don't
|
||||
submit nearly identical versions of your program separately. As we try to judge
|
||||
the entries anonymously, the similarities will cause such entries to compete
|
||||
against one another, making each less likely to win.
|
||||
|
||||
We hope the authors of non-winning entries will refine their entries and
|
||||
perhaps re-submit them for the next IOCCC.
|
||||
@@ -61,6 +67,8 @@ perhaps re-submit them for the next IOCCC.
|
||||
|
||||
## Final Comments
|
||||
|
||||
One more thing that feels dated is digraphs and trigraphs.
|
||||
|
||||
**IMPORTANT NOTE**: See [contact.html](../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](../faq.html) for addition information on the IOCCC.
|
||||
|
||||
+3
-17
@@ -1,5 +1,5 @@
|
||||
# A todo list of known things to check and/or do
|
||||
*Last updated: Tue 27 Feb 2024 16:16:25 UTC*
|
||||
*Last updated: Thu 07 Mar 2024 18:16:13 UTC*
|
||||
|
||||
This document is for [Cody Boone Ferguson](/authors.html#Cody_Boone_Ferguson) as
|
||||
he (that is I :-) ) wanted a way to keep track of things in a way that did not
|
||||
@@ -15,24 +15,10 @@ something needs to be done is thought of it is also updated unless it can be
|
||||
done right then and there or it seems more appropriate to add to the issue (#3)
|
||||
todo list.
|
||||
|
||||
- Typo fix ALL markdown files. For the README.md files the entries have all been
|
||||
done (along with format fixes) but the YYYY/README.md files have not been
|
||||
completed.
|
||||
* Go through all year README.md files: that is 1984/README.md,
|
||||
1985/README.md and so on. As of **Mon 16 Oct 11:22:52 UTC 2023** the
|
||||
following years have had a first pass: 1984 through 2001. However there are
|
||||
changes that might be required in those years too so a pass over all of them
|
||||
will have to be done at the time the files are to be reviewed.
|
||||
|
||||
- Check that the following todo tasks at:
|
||||
<https://github.com/ioccc-src/temp-test-ioccc/issues/3#issuecomment-1583842154>,
|
||||
<https://github.com/ioccc-src/temp-test-ioccc/issues/3#issuecomment-1583836962>,
|
||||
<https://github.com/ioccc-src/temp-test-ioccc/issues/3#issuecomment-1583834979>,
|
||||
<https://github.com/ioccc-src/temp-test-ioccc/issues/3#issuecomment-1583833132>,
|
||||
<https://github.com/ioccc-src/temp-test-ioccc/issues/3#issuecomment-1583832622>,
|
||||
<https://github.com/ioccc-src/temp-test-ioccc/issues/3#issuecomment-1583829356>
|
||||
<https://github.com/ioccc-src/temp-test-ioccc/issues/3#issuecomment-1583833132>
|
||||
and
|
||||
<https://github.com/ioccc-src/temp-test-ioccc/issues/3#issuecomment-1583828473>
|
||||
<https://github.com/ioccc-src/temp-test-ioccc/issues/3#issuecomment-1583829356>
|
||||
|
||||
have been finished. It is quite possible that some or all of these have been
|
||||
corrected by now but this has not yet been determined.
|
||||
Reference in new issue
Block a user