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

Merge pull request #1033 from xexyl/1980s-1990s-readmes

Browse Source
This commit is contained in:
Landon Curt Noll authored and GitHub committed 2023-10-12 08:24:32 -07:00
2 parents b31dd1fb70 f9a6d7f5a0
commit 9fa14ebfee
16 files changed
+278 -269
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

1984/README.md
+4 -4
View File
@@ -1,10 +1,10 @@
# First Obfuscated C Code Contest
In [1984](/years.html#1984), the first contest was held. The name of the contest was simply
"`Obfuscated C Code Contest`".
In [1984](/years.html#1984), the first contest was held. The name of the
contest was simply "`Obfuscated C Code Contest`".
Look at the `README.md`file for the given winner for information on how to
compile the entry and how to run the winning program. Look at the winning
Look at the `README.md`file 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.
1985/README.md
+4 -5
View File
@@ -1,9 +1,9 @@
# [1985](/years.html#1985) marked the second year of the International Obfuscated C Code Contest.
Look at the `README.md` file for the given winner for information
on how to 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.
Look at the `README.md` file 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! You may then wish to look at the
Author's remarks for even more details.
Hints against machine dependent code were added to the [rules](rules.txt) to
avoid another 1984 style winner ([1984/mullender](../1984/mullender)).
@@ -13,7 +13,6 @@ avoid another 1984 style winner ([1984/mullender](../1984/mullender)).
was invited to help in the judging. Awards were given to 5 classes of programs
since we were unable to select only the best 4.
=-=
Copyright (c) 1985, Landon Curt Noll & Larry Bassel.
1986/README.md
+7 -9
View File
@@ -1,15 +1,13 @@
# The 1986 contest was named "The Third International Obfuscated C Code Contest"
Look at the `README.md` file for the given winner for information
on how to 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.
Look at the `README.md` file 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! You may then wish to look at the
Author's remarks for even more details.
The [rules for 1986](rules.txt) suggested categories due to the success of the
[1985](/years.html#1985)
judging method. The maximum size was increased from 512 to 1024 bytes.
Larry Bassel joined as the second official judge.
[1985](/years.html#1985) judging method. The maximum size was increased from
512 to 1024 bytes. Larry Bassel joined as the second official judge.
A poll was taken for the worst code for
[BSD](https://en.wikipedia.org/wiki/Berkeley_Software_Distribution) and [System
@@ -24,7 +22,7 @@ program took third place.
[Micro/Systems
Journal](https://www.vintage-computer.com/publications.php?microsystemsjournal)
started regular publishing of the winners. The practice of making first
announcement of the winners at the Summer Usenix BOF (Birds of a Feather)
announcement of the winners at the Summer USENIX BOF (Birds of a Feather)
started this year. A notice was posted to net.announce.
=-=
1987/README.md
+12 -12
View File
@@ -1,25 +1,25 @@
1987 marked the "The Fourth International Obfuscated C Code Contest"
# 1987 marked the "The Fourth International Obfuscated C Code Contest"
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 remarks for even more details.
Look at the README.md file 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! You may then wish to look at the
Author's remarks for even more details.
The [rules for 1997](rules.txt) suggested even more categories than in 1986.
Hints for what to do and not to do were also given in the [rules](rules.txt).
For example, a simple excessive abuse of /lib/cpp was discouraged unless the
For example, a simple excessive abuse of `/lib/cpp` was discouraged unless the
abuse was unusual. The mailboxes for the contest were moved from nsc to amdahl.
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
[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
published the 1987 winners. [Mark R.
Horton](https://www.amazon.com/stores/Mark-R.-Horton/author/B001HPGRB8) included a version of the [1987
winners](../years.html#1987) in an appendix of his C book [Portable C Software International
Horton](https://www.amazon.com/stores/Mark-R.-Horton/author/B001HPGRB8) included
a version of the [1987 winners](../years.html#1987) in an appendix of his C book
[Portable C Software International
Edition](https://www.amazon.com/Portable-Software-Mark-R-Horton/dp/0138680507).
The first announcement of winners at the Summer 87 Usenix was helped by a small
The first announcement of winners at the Summer 87 USENIX was helped by a small
fly that danced all over the foils.
=-=
1988/README.md
+10 -11
View File
@@ -1,26 +1,25 @@
1988 marked the "The Fifth International Obfuscated C Code Contest"
# 1988 marked the "The Fifth International Obfuscated C Code Contest"
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 README.md file 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!
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"
winner of 1987](../1987/biggar/), a limit of 160 chars in the compile line was
introduced.
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" winner of
1987](../1987/biggar/), 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.
[Rules](rules.txt) and results were posted to comp.lang.c, comp.sources.unix and
alt.sources. The 1988 winners will be published in the Micro/Systems Journal.
alt.sources. The 1988 winners will be published in the [Micro/Systems
Journal](https://www.vintage-computer.com/publications.php?microsystemsjournal).
Winning entries for previous years were repackaged with each year
being in its own directory. Makefiles and hints were also provided.
The package was posted to the: comp.sources.unix newsgroup. They are
also available on a wide number of Usenet archive sites.
The package was posted to the comp.sources.unix newsgroup. They are
also available on a wide number of USENET archive sites.
=-=
1989/README.md
+12 -13
View File
@@ -1,14 +1,12 @@
1989 marked the "The Sixth International Obfuscated C Code Contest"
# 1989 marked the "The Sixth International Obfuscated C Code Contest"
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 README.md file 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!
You may then wish to look at the Author's remarks for even more details.
Instructions for use: Run make to compile entries (it is possible
that on System V or non-unix systems the Makefile needs to be
changed).
Instructions for use: Run `make` to compile entries (it is possible that on
System V or non-Unix systems the Makefile needs to be changed).
This year, the Grand Prize was given to the most useful program.
@@ -17,16 +15,17 @@ to stress the fact that starting in 1990, compiling entries must result an
executable regular file.
The Makefile always uses the portable version of the ["Best
self modifying program"](fubar/) because there is no loss of functionality in
using it. In the case of the ["Best game"](tromp/) winner, however, some
self modifying program"](fubar/README.md) because there is no loss of functionality in
using it. In the case of the ["Best game"](tromp/README) winner, 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. System V users may need to change the Makefile
to use the s5 version. See the hint files or the Makefile for details.
[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
alt.sources. They have been made available on a wide number of USENET
archive sites such as uunet. The 1989 winners will be published in the
Micro/Systems Journal.
[Micro/Systems
Journal](https://www.vintage-computer.com/publications.php?microsystemsjournal).
=-=
1990/README.md
+11 -12
View File
@@ -1,28 +1,27 @@
1990 marked the "The Seventh International Obfuscated C Code Contest"
# 1990 marked the "The Seventh International Obfuscated C Code Contest"
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 README.md file 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!
You may then wish to look at the Author's remarks for even more details.
This year, the Grand Prize won a standing ovation at USENIX.
The "Strangest abuse of the rules" award was given this year to stress
the fact that starting in 1991, entries should be shell-specific.
The ["Strangest abuse of the rules"](1990/stig/README.md) award was given this
year to stress the fact that starting in 1991, entries should be shell-specific.
This year was the first year that we accepted ANSI C entries. It was
interesting to note that the ANSI C entries were as a whole less
portable than the K&R C entries. We hope that in future contests
people will enter more obfuscated and challenging ANSI C programs.
interesting to note that the ANSI C entries were as a whole less portable than
the K&R C entries. We hope that in future contests people will enter more
obfuscated and challenging ANSI C programs.
We would like to thank Barbara Frezza (loving wife of Larry Bassel) for
her role as official chef of the contest. Her opinions regarding
some of the contest entries were appreciated.
Rules 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
archive sites such as uunet.
[Rules](rules.txt) and [results](https://www.ioccc.org/years.html#1990) were
posted to comp.lang.c, comp.sources.unix, and alt.sources. They have been made
available on a wide number of USENET archive sites such as uunet.
=-=
1991/README.md
+41 -34
View File
@@ -1,30 +1,32 @@
1991 marked the "The Eighth International Obfuscated C Code Contest"
# 1991 marked the "The Eighth International Obfuscated C Code Contest"
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 README.md file 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!
You may then wish to look at the Author's remarks for even more details.
Instructions for use: Run make to compile entries. It is possible that
on BSD or non-unix systems the makefile needs to be changed.
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
all of the other entries this year:
Grand Prize by Brian Westley
Most Well Rounded by Diomidis Spinellis
Best Of Show by Daniel J. Bernstein
- [Grand Prize](westley/README.md) by [Brian
Westley](https://www.ioccc.org/winners.html#Brian_Westley)
- [Most Well Rounded](dds/README.md) by [Diomidis
Spinellis](https://www.ioccc.org/winners.html#Diomidis_Spinellis)
- [Best Of Show](brnstnd/README.md) by [Daniel J.
Bernstein](https://www.ioccc.org/winners.html#Daniel_J._Bernstein)
Name and address information are separated from the actual program
prior to judging. This eliminates any chance that we would bias our
judging for/against any person or group. In the end, we are surprised
as you are to see who as won. Even so, it is worth noting that
Brian Westley has submitted a winning entry for the past 5 years!
as you are to see who has won. Even so, it is worth noting that
[Brian Westley](https://www.ioccc.org/winners.html#Brian_Westley) has submitted
a winning entry for the past 5 years!
A few notes regarding possible changes to the contest:
## A few notes regarding possible changes to the contest:
We did not give awards to some traditional contest categories such as
"Best Layout" or "Worst Abuse of the Rules". We felt that to do so
@@ -33,38 +35,42 @@ been eliminated, and will likely be considered in future years.
A number of entries made use of the following C pre-processor feature:
#define X define
#X foo bar
```c
#define X define
#X foo bar
```
This is not permitted under ANSI C. Some ANSI C compilers do allow
this. In the future, we do not want programs to use this feature.
Because this request was not stated in the 1991 rules, we did not
reject entries of this type. However we provided more portable
versions so that more people could compile these programs.
This is not permitted under ANSI C. Some ANSI C compilers do allow this. In
the future, we do not want programs to use this feature. Because this request
was not stated in the [1991 rules](rules.txt), we did not reject entries of this
type. However we provided more portable versions so that more people could
compile these programs.
This year we received entries that made use of the X Window System.
This functionality is now available on many systems, we feel that
Since this functionality is now available on many systems, we feel that
programs that use these are now portable enough to be valid entries.
We may allow programs to make use of the X Window System libs and include
files, provided that they can operate with a system running at the level
of at least X11r4. Requiring the use of imake, a specific window manager,
specific display hardware, or a specific user interface (Openl**k,
M*tif, ...) is likely not to be allowed. We will provide a more detailed
specific display hardware, or a specific user interface (`Openl**k`,
`M*tif`, ...) is likely not to be allowed. We will provide a more detailed
explanation of our viewpoint in next year's rules.
In order to encourage more 'normal' looking C programs, we are considering
the following change to the maximum size rule:
Your source, not counting any <space>, <tab>, and a <newline> character,
and not counting any ';', '{' and '}' character followed by a <newline>
character, must be 1536 bytes or less. The entire source, counting all
characters, be 4096 bytes or less.
```
Your source, not counting any <space>, <tab>, and a <newline> character,
and not counting any ';', '{' and '}' character followed by a <newline>
character, must be 1536 bytes or less. The entire source, counting all
characters, be 4096 bytes or less.
```
Some thought has been given to adding some c++ categories, however this
is not likely to happen soon. We are waiting until c++ compilers become
Some thought has been given to adding some C++ categories, however this
is not likely to happen soon. We are waiting until C++ compilers become
common place on a wide number of systems. We also need time to brace
ourselves for what obfuscation c++ could wield!
ourselves for what obfuscation C++ could wield!
Be sure to wait until the 1992 rules are posted before submitting entries.
We may fine tune the rules to reflect the some ideas above.
@@ -73,11 +79,12 @@ 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:
...!{sun,pacbell,uunet,pyramid}!hoptoad!judges
judges@toad.com
```
...!{sun,pacbell,uunet,pyramid}!hoptoad!judges
judges@toad.com
```
Credits:
## Credits:
We would like to thank Barbara Frezza for her role as official chef
of the contest. Landon Noll appreciated the opportunity to serve
1992/README.md
+26 -26
View File
@@ -1,34 +1,32 @@
1992 marked the "The Ninth International Obfuscated C Code Contest"
# 1992 marked the "The Ninth International Obfuscated C Code Contest"
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 README.md file 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!
You may then wish to look at the Author's remarks for even more details.
Use make to compile entries. It is possible that on BSD or non-unix
systems the makefile needs to be changed. See the Makefile for details.
Use `make` to compile entries. It is possible that on BSD or non-Unix
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). 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.
Read over the Makefile for compile/build issues. Your system may require
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.
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 giving out a few more awards than in other
winning, we still wound up giving out a few more awards than in other
years. The new size rules size probably contributed to the overall
high quality.
FYI: By tradition, we do not record the count the number entries,
nor do we give our our guess as to the number of entries
received. For folks who wonder, we can say that we consumed
about 2000 pages of output (printing between 2 and 4 normal
pages per side) during the judging process this year.
FYI: By tradition, we do not record the count of the number entries,
nor do we give our our guess as to the number of entries
received. For folks who wonder, we can say that we consumed
about 2000 pages of output (printing between 2 and 4 normal
pages per side) during the judging process this year.
The new instructions for submitting entries worked well - we were
able to write scripts to unpack them and eliminate duplicates.
@@ -40,11 +38,11 @@ the "standard" version that the entries were compiled with.
Name and address information are separated from the actual program
prior to judging. This eliminates any chance that we would bias our
judging for/against any person or group. In the end, we are surprised
as you are to see who as won. Even so, it is worth noting that
Brian Westley has submitted a winning entry for the past 6 years!
as you are to see who has won. Even so, it is worth noting that
[Brian Westley](https://www.ioccc.org/winners.html#Brian_Westley) has submitted
a winning entry for the past 6 years!
A few notes regarding future contests:
## A few notes regarding future contests:
We did not give awards to some traditional contest categories such as
"Best Layout". We felt that to do so would deny awards to more
@@ -66,8 +64,10 @@ 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:
...!{sun,pacbell,uunet,pyramid}!hoptoad!judges
judges@toad.com
```
...!{sun,pacbell,uunet,pyramid}!hoptoad!judges
judges@toad.com
```
If you use, distribute or publish these entries in some way, please drop
@@ -76,7 +76,7 @@ us a line. We enjoy seeing who, where and how the contest is used.
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.
Credits:
## 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
1993/README.md
+16 -14
View File
@@ -1,17 +1,17 @@
1993 marked the "The Tenth International Obfuscated C Code Contest"
# 1993 marked the "The Tenth International Obfuscated C Code Contest"
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 README.md file 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!
You may then wish to look at the Author's remarks for even more details.
Use make to compile entries. It is possible that on BSD or non-unix
systems the makefile needs to be changed. See the Makefile for details.
Use `make` to compile entries. It is possible that on BSD or non-Unix
systems the Makefile needs to be changed. See the Makefiles and/or README.md
files 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/or README.md files for compile/build issues. Your
system may require certain changes (add or remove a library, add or remove a
`#define` i.e. the `-D` flag).
Name and address information are separated from the actual program
prior to judging. This eliminates any chance that we would bias our
@@ -22,13 +22,13 @@ classic K&R C was allowed so long as ANSI C compilers could still
compile the entry. If you do not have an ANSI C compiler, you may
not be able to compile the winners, sorry!
A few notes regarding future contests:
## A few notes regarding future contests:
Be sure to wait until the 1994 rules are posted before submitting entries.
Rules differ from year to year, sometimes in significant ways.
In 1994, we will retract the guideline that discouraged the use of C
constructs such as 3["curds"]. At one time, certain ANSI compilers did
constructs such as `3["curds"]`. At one time, certain ANSI compilers did
not consider such expressions to be valid ANSI C. Alert readers noted
that the current ANSI standard considered them to be valid. We were
unable to find an ANSI C compiler that flagged such expressions as
@@ -38,8 +38,10 @@ 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:
...!{sun,pacbell,uunet,pyramid}!hoptoad!judges
judges@toad.com
```
...!{sun,pacbell,uunet,pyramid}!hoptoad!judges
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.
@@ -47,7 +49,7 @@ us a line. We enjoy seeing who, where and how the contest is used.
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.
Credits:
### 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
1994/README.md
+47 -45
View File
@@ -1,24 +1,23 @@
1994 marked the "The Eleventh International Obfuscated C Code Contest"
# 1994 marked the "The Eleventh International Obfuscated C Code Contest"
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 README.md file 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!
You may then wish to look at the Author's remarks for even more details.
Use make to compile entries. It is possible that on BSD or non-unix
systems the makefile needs to be changed. See the Makefile for details.
Use `make` to compile entries. It is possible that on BSD or non-Unix
systems the Makefile needs to be changed. See the Makefile for details.
Read over the makefile for compile/build issues. Your system may
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` i.e. the `-D` flag).
Name and address information are separated from the actual program
prior to judging. This eliminates any chance that we would bias our
judging for/against any person or group.
This year we retracted the guideline that discouraged the use of C
constructs such as 3["curds"]. At one time, certain ANSI compilers did
constructs such as `3["curds"]`. At one time, certain ANSI compilers did
not consider such expressions to be valid ANSI C. Alert readers noted
that the current ANSI standard considered them to be valid. We were
unable to find an ANSI C compiler that flagged such expressions as
@@ -26,11 +25,11 @@ errors.
Rule abuse was encouraged this year - two of this year's winners found
new and interesting abuses of the rules. Next year's rules will change
due to these (smr and dodsond2) entries' forms of abuse.
due to these ([smr](smr/README.md) and [dodsond2](dodsond2/README.md)) entries'
forms of abuse.
Want to be an IOCCC Judge?
--------------------------
## Want to be an IOCCC Judge?
We are thinking about adding a 3rd judge to our team. A 3rd judge
would help distribute the work load as well as to allowing us to
@@ -38,60 +37,62 @@ possibly expand or reshape the contest.
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, libcurses, ...)
* reasonable written communication skills (able to write README.md files)
* 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
able to travel (paying your own way) to the SF Bay Area during judging, or
able to link to the other IOCCC judges some form of a a video link
* 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)
* 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
able to travel (paying your own way) to the SF Bay Area during judging, or
able to link to the other IOCCC judges by some form of a video link
Any of the following, though not required, would be a plus:
* familiar with portability issues
* some /bin/sh experience
* some Perl experience
* some C++ experience
* some experience with low-level X11 programming
* attends Usenix conferences on a regular basis
* good sense of humor
* loves chocolate and other fine foods :-)
* familiar with portability issues
* some `/bin/sh` experience
* some Perl experience
* some C++ experience
* some experience with low-level X11 programming
* attends USENIX conferences on a regular basis
* good sense of humor
* loves chocolate and other fine foods :-)
If you think this may be you, send an email before 31 Dec 1995, to:
judges@toad.com (use the Subject: 3rd judge)
```
judges@toad.com (use the Subject: 3rd judge)
```
Include in your message:
* Your name, address, email address and phone number
* Why would you want to be an IOCCC judge?
* How well do you match each of the above qualifications?
* What special skills would you bring to the team?
* Your name, address, email address and phone number
* Why would you want to be an IOCCC judge?
* How well do you match each of the above qualifications?
* What special skills would you bring to the team?
If you have any questions about the above, feel free to ask us via
email at the above address.
Looking for an IOCCC WWW site
-----------------------------
## Looking for an IOCCC WWW site
We would like to setup an IOCCC home page somewhere out in WWW land.
If you have a well known stable site that would be willing to give us
access to put up some IOCCC html pages, please send an email (say prior
to 31 Dec 1995) to:
judges@toad.com (use the Subject: www site)
```
judges@toad.com (use the Subject: www site)
```
describing your site and any other appropriate comments. Thanks!
A few notes regarding future contests
-------------------------------------
## A few notes regarding future contests
Due to changes in the Usenix conference calendar, the 1995 contest will
be delayed. Because there will be no Summer 1995 Usenix conference,
the 1995 IOCCC winners will be announced at the Jan 1996 Usenix conference.
Due to changes in the USENIX conference calendar, the 1995 contest will
be delayed. Because there will be no Summer 1995 USENIX conference,
the 1995 IOCCC winners will be announced at the Jan 1996 USENIX conference.
The 1995 contest will not open until late October 1995, and will close
sometime around the end of December 1995. The rules for the 1995
@@ -105,8 +106,10 @@ 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:
...!{sun,pacbell,uunet,pyramid}!hoptoad!judges
judges@toad.com
```
...!{sun,pacbell,uunet,pyramid}!hoptoad!judges
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.
@@ -115,8 +118,7 @@ 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.
Credits
-------
## 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
1995/README.md
+4 -4
View File
@@ -1,7 +1,6 @@
# 1995 marked the "The Twelfth International Obfuscated C Code Contest"
Look at the README.md file for the given winner for information
Look at the README.md file for the given winning entry for information
on how to compile and 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` section for even more details.
@@ -15,13 +14,13 @@ 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` i.e. the `-D` flag).
This year [Sriram Srinivasan](http://www.malhar.net/sriram/) joined the judging.
The moderator of
[comp.unix.wizards](https://groups.google.com/g/comp.unix.wizards) did not feel
that the IOCCC was "wizardly" enough to be posted to comp.unix.wizards - we will
that the IOCCC was "wizardly" enough to be posted to comp.unix.wizards so we will
no longer post the winners to this newsgroup - we'll let you the reader decide
for yourself the wizardry of these entries.
@@ -60,6 +59,7 @@ Send such email to:
...!{sun,pacbell,uunet,pyramid}!hoptoad!judges
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.
1996/README.md
+26 -28
View File
@@ -1,31 +1,27 @@
1996 marked the "The Thirteenth International Obfuscated C Code Contest"
# 1996 marked the "The Thirteenth International Obfuscated C Code Contest"
Standard IOCCC stuff
--------------------
## 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 README.md file 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!
You may then wish to look at the Author's remarks for even more details.
The IOCCC has an official home page:
https://www.ioccc.org
The IOCCC has an official home page: <https://www.ioccc.org>
containing previous winning entries, information about the judges,
announcements and much more.
Use make to compile entries. It is possible that on BSD or non-unix
systems the makefile needs to be changed. See the Makefile for details.
Use `make` to compile entries. It is possible that on BSD or non-Unix
systems the Makefile needs to be changed. See the Makefile for details.
Read over the makefile for compile/build issues. Your system may
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` i.e. the `-D` flag).
Where are Larry Bassel and Barbara Frezza?
------------------------------------------
## Where are Larry Bassel and Barbara Frezza?
It is not true that Larry Bassel avoided the 13th IOCCC on grounds of
superstition! Larry (as well as Landon) is fond of prime numbers.
@@ -39,21 +35,22 @@ sorely missed. We look forward to her return to the contest
next year as well.
Both Larry and Barbara have taken important new steps in their
lives as we wish them the best. When it is all over, Larry will
lives and we wish them the best. When it is all over, Larry will
be able to produce obfuscated mathematical proofs, and Barbara
will be able de-obfuscate the many legal obfuscations. :-)
will be able deobfuscate the many legal obfuscations. :-)
Remarks on some of the entries
------------------------------
## Remarks on some of the entries
This year, Jens Schweikhardt won 3 times ... a new IOCCC record.
Meanwhile, Brian Westley came up with his 8th winning entry, twice the
number of the next highest count. But with people like Schweikhardt
around, this lead could fall fast.
This year, [Jens
Schweikhardt](https://www.ioccc.org/winners.html#Jens_Schweikhardt) won 3 times
... a new IOCCC record. Meanwhile, [Brian
Westley](https://www.ioccc.org/winners.html#Brian_Westley) came up with his 8th
winning entry, twice the number of the next highest count. But with people like
Schweikhardt around, this lead could fall fast.
As we state in the guidelines, the names of the winners are as much
news to us as they are to you because we keep authorship separate from
As we stated in the [guidelines](guidelines.txt), the names of the winners are
as much news to us as they are to you because we keep authorship separate from
rest of the entry. Some people have it, we guess!
There were a few very good entries that might have won if it were not
@@ -61,10 +58,9 @@ 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!
A few notes regarding future contests
-------------------------------------
## A few notes regarding future contests
There is no 1997 contest.
There will be no 1997 contest.
The next contest will not open until sometime in March 1998, and will
close sometime around the end of May 1998. The rules for the 1998
@@ -82,7 +78,9 @@ 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:
judges@toad.com
```
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.
1998/README.md
+49 -50
View File
@@ -1,32 +1,29 @@
1998 marked the "The Fourteenth International Obfuscated C Code Contest"
# 1998 marked the "The Fourteenth International Obfuscated C Code Contest"
Standard IOCCC stuff
--------------------
## 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 README.md file 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!
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:
<https://www.ioccc.org>.
https://www.ioccc.org
Use `make` to compile entries. It is possible that on BSD or non-Unix
systems the Makefile needs to be changed. See the Makefile for details.
Use make to compile entries. It is possible that on BSD or non-unix
systems the makefile needs to be changed. See the Makefile for details.
Read over the makefile for compile/build issues. Your system may
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` i.e. the `-D` flag).
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 Judges
----------
## New Judges
Larry Bassel is now a graduate student in number theory at UC San Diego.
Barbara Frezza also went to San Diego to enter into law school at the
@@ -34,28 +31,31 @@ same time. Her cooking in the role of official chef was sorely missed.
Both Larry and Barbara have taken important new steps in their lives.
We wish them the best.
Landon was unable to contact with Sriram Srinivasan at the start of
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 winner, as a
co-judge. Landon and Leo together selected Jeremy Horn and Peter
Seebach. The four judges:
Seebach. The four judges (<https://www.ioccc.org/judges.html>) together worked
thru-out the 1998 IOCCC season.
https://www.ioccc.org/judges.html
### 2023 note about judges:
together worked thru-out the 1998 IOCCC season.
The number of judges now is only 2, Landon Curt Noll and Leonid A. Broukhis.
## Remarks on some of the entries
Remarks on some of the entries
------------------------------
This year, [Jens
Schweikhardt](https://www.ioccc.org/winners.html#Jens_Schweikhardt) won 3 times
... AGAIN! He is the only person who was able to do this, let alone do it in
two contests in a row. [Bas de
Bakker](https://www.ioccc.org/winners.html#Bas_de_Bakker) and [David
Lowe](https://www.ioccc.org/winners.html#J_David_Lowe) won twice this year as
well.
This year, Jens Schweikhardt won 3 times ... AGAIN! He is the only
person who was able to do this, let alone do it in two contests
in a row. Bas de Bakker and David Lowe won twice this year as well.
As we state in the guidelines, the names of the winners are as much
news to us as they are to you because we keep authorship separate from
As we stated in the [guidelines](guidelines.txt), the names of the winners are
as much news to us as they are to you because we keep authorship separate from
rest of the entry. Some people have it, we guess!
There were a few very good entries that might have won if it were not
@@ -67,61 +67,60 @@ look at all of the winners. The list of winners is a bit too long to
say something about every winner. On the other hand a partial mention
of a few is in order:
+ Audiences were very impressed with the Best of Show entry.
+ The judges were amused that for the first time we received an entry
that caused gcc to give the assembler bad input in some cases.
+ The poot entries got a good laugh from the Usenix IOCCC BOF crowd.
+ Those with Functional Programming knowledge as well as those
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.
+ Those who know the PostScript language will be ``bemused'' by
the Best Encapsulation entry.
- Audiences were very impressed with the Best of Show entry.
- The judges were amused that for the first time we received an entry
that caused gcc to give the assembler bad input in some cases.
- The poot entries got a good laugh from the USENIX IOCCC BOF (Birds Of a Feather) crowd.
- Those with Functional Programming knowledge as well as those
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/README.md).
- Those who know the PostScript language will be 'bemused' by
the [Best Encapsulation entry](bas1/README.md).
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.
- 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.
There was no 1997 contest
-------------------------
## There was no 1997 contest
So what happened to 1997? There was no summer USENIX Technical
Conference. The Technical Conference was held Jun 15-19, 1998 instead
... 18 months later than the 1996 summer USENIX Technical Conference.
In addition we had to select some new IOCCC judges. As a result IOCCC
In addition we had to select some new IOCCC judges. As a result the IOCCC
skipped over 1997.
Final Comments
--------------
## 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
```
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
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 the end of 1999. Watch:
https://www.ioccc.org
The next IOCCC is planned to start towards the end of 1999. Watch
<https://www.ioccc.org>
for news of the next contest.
thanks-for-fixes.md
-1
View File
@@ -1638,7 +1638,6 @@ specified it will feed the source code [endoh4.c](2013/endoh4/endoh4.c) to the
program rather than the file specified. It does not try and detect if the file
exists or can be read as that will be handled by the shell/program.
## [2013/endoh4](2013/endoh4/endoh4.c) ([README.md](2013/endoh4/README.md))
Cody added the [run.sh](2013/endoh4/run.sh) script which temporarily turns off
todo.md
+9 -1
View File
@@ -1,5 +1,5 @@
# A todo list of known things to check and/or do
*Last updated: Fri 06 Oct 2023 10:45:23 UTC*
*Last updated: Tue 10 Oct 2023 13:08:59 UTC*
This document is primarily for [Cody Boone
Ferguson](/winners.html#Cody_Boone_Ferguson) as he (that is I :-) ) wanted a way
@@ -128,3 +128,11 @@ entries in the respective README.md files. This cannot be done without examining
each because some names are mentioned by the author. For instance I (Cody) can
think of at least three where I have been mentioned explicitly by the author:
one in 2018, one in 2019 and one in 2020.
- For the YYYY/README.md files where it refers to emailing the judges fixes
instead change it to make pull requests. See the
[1995/README.md](1995/README.md) file for example.
- Check the YYYY/README.md files for other things besides the GitHub pull
requests rather thane mailing judges. This can be done on the final pass of the
files.