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

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
+In [1984](/years.html#1984), the first contest was held.  The name of the
-"`Obfuscated C Code Contest`".
+contest was simply "`Obfuscated C Code Contest`".
 
-Look at the `README.md`file for the given winner for information on how to
+Look at the `README.md`file for the given winning entry for information on how
-compile the entry and how to run the winning program.  Look at the winning
+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

@@ -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
+Look at the `README.md` file for the given winning entry for information on how
-on how to compile the entry and how to run the winning program.
+to compile it and how to run the winning program.  Look at the winning source
-Look at the winning source and try to figure how it does what it does!
+and try to figure how it does what it does!  You may then wish to look at the
-You may then wish to look at the Author's remarks for even more details.
+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

@@ -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 winning entry for information on how
-Look at the `README.md` file for the given winner for information
+to compile it and how to run the winning program.  Look at the winning source
-on how to compile the entry and how to run the winning program.
+and try to figure how it does what it does!  You may then wish to look at the
-Look at the winning source and try to figure how it does what it does!
+Author's remarks for even more details.
-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)
+[1985](/years.html#1985) judging method.  The maximum size was increased from
-judging method.  The maximum size was increased from 512 to 1024 bytes.
+512 to 1024 bytes.  Larry Bassel joined as the second official judge.
-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

@@ -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 winning entry for information on how to
-Look at the README.md file for the given winner for information
+compile it and how to run the winning program.  Look at the winning source and
-on how to compile the winner and how to run the winning program.
+try to figure how it does what it does!  You may then wish to look at the
-Look at the winning source and try to figure how it does what it does!
+Author's remarks for even more details.
-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
+[Rules](rules.txt) and results were posted to comp.lang.c and comp.unix.wizards
-an announcement in news.announce.important.  Micro/Systems Journal
+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
+Horton](https://www.amazon.com/stores/Mark-R.-Horton/author/B001HPGRB8) included
-winners](../years.html#1987) in an appendix of his C book [Portable C Software International
+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

@@ -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 winning entry for information
-Look at the README.md file for the given winner for information
+on how to compile it and how to run the winning program.
-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.
 
-The maximum size of entries was raised from 1024 to 1536 bytes, however
+The maximum size of entries was raised from 1024 to 1536 bytes, however smaller
-smaller entries were encouraged.  Due to the ["Best Abuse of the Rules"
+entries were encouraged.  Due to the ["Best Abuse of the Rules" winner of
-winner of 1987](../1987/biggar/), a limit of 160 chars in the compile line was
+1987](../1987/biggar/), a limit of 160 chars in the compile line was introduced.
-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
+The package was posted to the comp.sources.unix newsgroup.  They are
-also available on a wide number of Usenet archive sites.
+also available on a wide number of USENET archive sites.
 
 =-=
 

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 winning entry for information
-Look at the README.md file for the given winner for information
+on how to compile it and how to run the winning program.
-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.
 
-Instructions for use: Run make to compile entries (it is possible
+Instructions for use: Run `make` to compile entries (it is possible that on
-that on System V or non-unix systems the Makefile needs to be
+System V or non-Unix systems the Makefile needs to be changed).
-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
+self modifying program"](fubar/README.md) because there is no loss of functionality in
-using it.  In the case of the ["Best game"](tromp/) winner, however, some
+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
+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.
+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

@@ -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 winning entry for information
-Look at the README.md file for the given winner for information
+on how to compile it and how to run the winning program.
-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.
 
 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 ["Strangest abuse of the rules"](1990/stig/README.md) award was given this
-the fact that starting in 1991, entries should be shell-specific.
+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
+interesting to note that the ANSI C entries were as a whole less portable than
-portable than the K&R C entries.  We hope that in future contests
+the K&R C entries.  We hope that in future contests people will enter more
-people will enter more obfuscated and challenging ANSI C programs.
+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
+[Rules](rules.txt) and [results](https://www.ioccc.org/years.html#1990) were
-alt.sources.  They have been made available on a wide number of Usenet
+posted to comp.lang.c, comp.sources.unix, and alt.sources.  They have been made
-archive sites such as uunet.
+available on a wide number of USENET archive sites such as uunet.
 
 =-=
 

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 winning entry for information
-Look at the README.md file for the given winner for information
+on how to compile it and how to run the winning program.
-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.
 
-Instructions for use: Run make to compile entries.  It is possible that
+Instructions for use: Run `make` to compile entries.  It is possible that
-on BSD or non-unix systems the makefile needs to be changed.
+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
+- [Grand Prize](westley/README.md) by [Brian
-	Most Well Rounded		by Diomidis Spinellis
+Westley](https://www.ioccc.org/winners.html#Brian_Westley)
-	Best Of Show    		by Daniel J. Bernstein
+- [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
+as you are to see who has won.  Even so, it is worth noting that
-Brian Westley has submitted a winning entry for the past 5 years!
+[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
+```c
-	#X foo bar
+#define X define
+#X foo bar
+```
 
-This is not permitted under ANSI C.  Some ANSI C compilers do allow
+This is not permitted under ANSI C.  Some ANSI C compilers do allow this.  In
-this.  In the future, we do not want programs to use this feature.
+the future, we do not want programs to use this feature.  Because this request
-Because this request was not stated in the 1991 rules, we did not
+was not stated in the [1991 rules](rules.txt), we did not reject entries of this
-reject entries of this type.  However we provided more portable
+type.  However we provided more portable versions so that more people could
-versions so that more people could compile these programs.
+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,
+specific display hardware, or a specific user interface (`Openl**k`,
-M*tif, ...) is likely not to be allowed.  We will provide a more detailed
+`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>
+Your source, not counting any <space>, <tab>, and a <newline> character,
-    character, must be 1536 bytes or less.  The entire source, counting all
+and not counting any ';', '{' and '}' character followed by a <newline>
-    characters, be 4096 bytes or less.
+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
+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
+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

@@ -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 winning entry for information
-Look at the README.md file for the given winner for information
+on how to compile it and how to run the winning program.
-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.
 
-Use make to compile entries.  It is possible that on BSD or non-unix
+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.
+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
-require certain changes (add or remove a library, add or remove a
+certain changes (add or remove a library, add or remove a `#define` i.e. the
-#define).  A number of compilers had problems optimizing certain
+`-D` flag).  A number of compilers had problems optimizing certain entries.
-entries.  Some compilers do optimize, but the resulting program
+Some compilers do optimize, but the resulting program does not work.  By default
-does not work.  By default we have left off -O from compile lines.
+we have left off `-O` from compile lines.  You might want to add `-O` back, or
-You might want to add -O back, or add it back for certain entries
+add it back for certain entries where performance is important.
-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,
+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
+nor do we give our our guess as to the number of entries
-     received.  For folks who wonder, we can say that we consumed
+received.  For folks who wonder, we can say that we consumed
-     about 2000 pages of output (printing between 2 and 4 normal
+about 2000 pages of output (printing between 2 and 4 normal
-     pages per side) during the judging process this year.
+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
+as you are to see who has won.  Even so, it is worth noting that
-Brian Westley has submitted a winning entry for the past 6 years!
+[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

@@ -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 winning entry for information
-Look at the README.md file for the given winner for information
+on how to compile it and how to run the winning program.
-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.
 
-Use make to compile entries.  It is possible that on BSD or non-unix
+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.
+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
+Read over the Makefile and/or README.md files for compile/build issues.  Your
-require certain changes (add or remove a library, add or remove a
+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
@@ -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

@@ -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 winning entry for information
-Look at the README.md file for the given winner for information
+on how to compile it and how to run the winning program.
-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.
 
-Use make to compile entries.  It is possible that on BSD or non-unix
+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.
+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 the C language (ANSI and K&R)
-    * thorough knowledge of common C libs (libc, libm, libcurses, ...)
+* thorough knowledge of common C libs (libc, libm, curses, ...)
-    * reasonable written communication skills (able to write README.md files)
+* reasonable written communication skills (able to write README.md files)
-    * appreciation for well-written non-obfuscated code
+* appreciation for well-written non-obfuscated code
-    * willing to devote ~4 weekend days in January (starting Jan 96) for judging
+* willing to devote ~4 weekend days in January (starting Jan 96) for judging
-    * located in the San Francisco (California, US) Bay Area, or
+* 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 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
+  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
+* familiar with portability issues
-    * some /bin/sh experience
+* some `/bin/sh` experience
-    * some Perl experience
+* some Perl experience
-    * some C++ experience
+* some C++ experience
-    * some experience with low-level X11 programming
+* some experience with low-level X11 programming
-    * attends Usenix conferences on a regular basis
+* attends USENIX conferences on a regular basis
-    * good sense of humor
+* good sense of humor
-    * loves chocolate and other fine foods  :-)
+* 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
+* Your name, address, email address and phone number
-    * Why would you want to be an IOCCC judge?
+* Why would you want to be an IOCCC judge?
-    * How well do you match each of the above qualifications?
+* How well do you match each of the above qualifications?
-    * What special skills would you bring to the team?
+* 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
+Due to changes in the USENIX conference calendar, the 1995 contest will
-be delayed.  Because there will be no Summer 1995 Usenix conference,
+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 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

@@ -1,7 +1,6 @@
 # 1995 marked the "The Twelfth International Obfuscated C Code Contest"
 
-
+Look at the README.md file for the given winning entry for information
-Look at the README.md file for the given winner 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

@@ -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
+Look at the README.md file for the given winning entry for information
-on how to compile the winner and how to run the winning program.
+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:
+The IOCCC has an official home page: <https://www.ioccc.org>
-
-	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
+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.
+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.
+This year, [Jens
-Meanwhile, Brian Westley came up with his 8th winning entry, twice the
+Schweikhardt](https://www.ioccc.org/winners.html#Jens_Schweikhardt) won 3 times
-number of the next highest count.  But with people like Schweikhardt
+... a new IOCCC record.  Meanwhile, [Brian
-around, this lead could fall fast.
+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
+As we stated in the [guidelines](guidelines.txt), the names of the winners are
-news to us as they are to you because we keep authorship separate from
+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

@@ -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
+Look at the README.md file for the given winning entry for information
-on how to compile the winner and how to run the winning program.
+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
+Read over the Makefile for compile/build issues.  Your system may
-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).
 
 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
+As we stated in the [guidelines](guidelines.txt), the names of the winners are
-person who was able to do this, let alone do it in two contests
+as much news to us as they are to you because we keep authorship separate from
-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
 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.
+- Audiences were very impressed with the Best of Show entry.
-    + The judges were amused that for the first time we received an 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.
+  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.
+- 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
+- Those with Functional Programming knowledge as well as those
-      impressed with CPP code expansion liked the entry that translated
+  impressed with CPP code expansion liked the entry that translated
-      lambda expressions into combinator expressions.
+  lambda expressions into combinator expressions.
-    + Logic minded folks will get somewhat twisted up while following the
+- Logic minded folks will get somewhat twisted up while following the
-      flow of the Best Flow Control entry.
+  flow of the [Best Flow Control entry](1998/schnitzi/README.md).
-    + Those who know the PostScript language will be ``bemused'' by
+- Those who know the PostScript language will be 'bemused' by
-      the Best Encapsulation entry.
+  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 non-portable side effects in expressions;
-    + depended too much on a particular byte order;
+- depended too much on a particular byte order;
-    + required the use of a special script, data file or pseudo-machine
+- required the use of a special script, data file or pseudo-machine language
-      language that was not supplied with the entry.
+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:
+The next IOCCC is planned to start towards the end of 1999.  Watch
-
+<https://www.ioccc.org>
-	https://www.ioccc.org
 
 for news of the next contest.
 

thanks-for-fixes.md

@@ -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

@@ -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.