From add7268842b33744f24e4a14b0207a0db771141b Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Tue, 10 Oct 2023 06:22:21 -0700 Subject: [PATCH] Format fix 1980s and 1990s README.md files I also updated the todo.md file as I left some things out that have to be done. I only explicitly named one thing but when I go over them as a final pass I will address the things in question (some will require discussion). --- 1984/README.md | 8 ++-- 1985/README.md | 9 ++--- 1986/README.md | 16 ++++---- 1987/README.md | 24 ++++++------ 1988/README.md | 21 +++++------ 1989/README.md | 25 ++++++------- 1990/README.md | 23 ++++++------ 1991/README.md | 75 +++++++++++++++++++++----------------- 1992/README.md | 52 +++++++++++++------------- 1993/README.md | 30 ++++++++------- 1994/README.md | 92 +++++++++++++++++++++++----------------------- 1995/README.md | 8 ++-- 1996/README.md | 54 +++++++++++++-------------- 1998/README.md | 99 +++++++++++++++++++++++++------------------------- todo.md | 10 ++++- 15 files changed, 278 insertions(+), 268 deletions(-) diff --git a/1984/README.md b/1984/README.md index 9cc6b6411..ab650283a 100644 --- a/1984/README.md +++ b/1984/README.md @@ -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. diff --git a/1985/README.md b/1985/README.md index 43853beae..92ee9bc6f 100644 --- a/1985/README.md +++ b/1985/README.md @@ -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. diff --git a/1986/README.md b/1986/README.md index ff4baa03e..b709248dc 100644 --- a/1986/README.md +++ b/1986/README.md @@ -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. =-= diff --git a/1987/README.md b/1987/README.md index cd0d15734..7c9d7530b 100644 --- a/1987/README.md +++ b/1987/README.md @@ -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. =-= diff --git a/1988/README.md b/1988/README.md index 1bf3af95c..896854694 100644 --- a/1988/README.md +++ b/1988/README.md @@ -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. =-= diff --git a/1989/README.md b/1989/README.md index 5f05fb49d..a12ade651 100644 --- a/1989/README.md +++ b/1989/README.md @@ -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). =-= diff --git a/1990/README.md b/1990/README.md index bd066a0e3..b8a71f735 100644 --- a/1990/README.md +++ b/1990/README.md @@ -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. =-= diff --git a/1991/README.md b/1991/README.md index 0d927b27c..f276493fc 100644 --- a/1991/README.md +++ b/1991/README.md @@ -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 , , and a character, - and not counting any ';', '{' and '}' character followed by a - character, must be 1536 bytes or less. The entire source, counting all - characters, be 4096 bytes or less. +``` +Your source, not counting any , , and a character, +and not counting any ';', '{' and '}' character followed by a +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 diff --git a/1992/README.md b/1992/README.md index 2d5b38108..2077380db 100644 --- a/1992/README.md +++ b/1992/README.md @@ -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 diff --git a/1993/README.md b/1993/README.md index 3c243d2ec..4553f12a8 100644 --- a/1993/README.md +++ b/1993/README.md @@ -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 diff --git a/1994/README.md b/1994/README.md index 5f5f74d30..5572d9f21 100644 --- a/1994/README.md +++ b/1994/README.md @@ -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 diff --git a/1995/README.md b/1995/README.md index 2fab13124..dc00163f6 100644 --- a/1995/README.md +++ b/1995/README.md @@ -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. diff --git a/1996/README.md b/1996/README.md index 9161594b8..35774393d 100644 --- a/1996/README.md +++ b/1996/README.md @@ -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: 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. diff --git a/1998/README.md b/1998/README.md index 8fd1b8b8a..897b16f96 100644 --- a/1998/README.md +++ b/1998/README.md @@ -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 +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 () 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 + for news of the next contest. diff --git a/todo.md b/todo.md index 60d49622e..8bb8089b7 100644 --- a/todo.md +++ b/todo.md @@ -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.