Format / typo check YYYY/README.md files

It should be pointed out that there are a few inconsistencies as noted
below.

In some years the title of entries that were explicitly listed were
linked to but as the README.md files no longer have the title it was not
as easy to locate the title (I could go back in archive/historic and I
did in some cases but I was trying to hurry this up to close #3).

It's most likely that some have backticks surrounding certain words like
gcc or something else but not in all files. An example that might be
there is '#define'.

Some wording is different. Usually this is due to the original wording
which I did not think was good to change. There might be other cases
that were missed as well. One thing is that comes to mind is that in
some README.md files it refers to the Makefile to check for build
instructions, in others it refers to the index.html file and in some it
refers to both. But the index.html has how to build so they should
probably all say index.html and not refer to the Makefile. This was also
done in a rush.

There might be other inconsistencies or things that might want to be
fixed but whether it's worth it given is unclear at this time. It can be
argued that the reference to the Makefiles for build instructions is a
historical comment to keep there as an example of why not to change it.

There were other things I noticed that I could not address or did not
feel were necessary but with this commit an important task is can likely
be considered done unless it is decided that some of these should be
fixed or if looking at the rendered output there is a problem.

1984/README.md

@@ -6,7 +6,7 @@ contest was simply "`First annual Obfuscated C Code Contest`".
 View the `index.html` web page for the given winning entry for information on how
 to compile it and how to run the winning program.  Look at the winning
 source and try to figure how it does what it does!  This year we only had
-remarks from two authors but which came years later.
+remarks from two authors but these came years later.
 
 Restrictions against machine dependent code were not in the [rules](rules.txt)
 in 1984. The source file size restriction was only 512 bytes.  Rules and results

1987/README.md

@@ -13,7 +13,8 @@ The practice of posting a preliminary set of rules for the next year was started
 this year.
 
 [Rules](rules.txt) and results were posted to comp.lang.c and comp.unix.wizards
-with an announcement in news.announce.important.  Micro/Systems Journal
+with an announcement in news.announce.important.  
+[Micro/Systems Journal](https://www.vintage-computer.com/publications.php?microsystemsjournal)
 published the 1987 winning entries.  [Mark R.
 Horton](https://www.amazon.com/stores/Mark-R.-Horton/author/B001HPGRB8) included
 a version of the [1987 winning entries](../years.html#1987) in an appendix of his C book

1988/README.md

@@ -7,7 +7,7 @@ You may then wish to look at the Author's remarks for even more details.
 
 The maximum size of entries was raised from 1024 to 1536 bytes, however smaller
 entries were encouraged.  Due to the ["Best Abuse of the Rules" entry of
-1987](../1987/biggar/), a limit of 160 chars in the compile line was introduced.
+1987](/1987/biggar/index.html), a limit of 160 chars in the compile line was introduced.
 
 This year, the Grand Prize was given to the most unusual entry and best
 abuse of the C Preprocessor rather than the most well rounded entry.

1989/README.md

@@ -11,15 +11,14 @@ System V or non-Unix systems the Makefile needs to be changed).
 This year, the Grand Prize was given to the most useful program.
 
 The ["Strangest abuse of the rules"](jar.1/indx.html) award was given this year
-to stress the fact that starting in 1990, compiling entries must result an
+to stress the fact that starting in 1990, compiling entries must result a
-executable regular file.
+regular executable file.
 
 The Makefile always uses the portable version of the ["Best
 self modifying program"](fubar/indx.html) because there is no loss of functionality in
 using it.  In the case of the ["Best game"](tromp/README) entry, however, some
 functionality is lost in the portable version and so the Makefile uses
-the original program. System V users may need to change the Makefile
+the original program.
-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

1991/README.md

@@ -9,7 +9,7 @@ Instructions for use: Run `make` to compile entries.  It is possible that
 on BSD or non-Unix systems the Makefile needs to be changed.
 
 This year, we did not single out an entry that was better than all of
-the rest.  We selected 3 entries that were, in our opinion, went beyond
+the rest.  We selected 3 entries that, in our opinion, went beyond
 all of the other entries this year:
 
 - [Grand Prize](westley/index.html) by [Brian

1992/README.md

@@ -13,12 +13,15 @@ certain changes (add or remove a library, add or remove a `#define` i.e. the
 `-D` flag).  A number of compilers had problems optimizing certain entries.
 Some compilers do optimize, but the resulting program does not work.  By default
 we have left off `-O` from compile lines.  You might want to add `-O` back, or
-add it back for certain entries where performance is important.
+add it back for certain entries where performance is important. (This was
+updated to use `-O3` in 202n though sometimes an entry does not work if the
+compiler optimises the code and in this case it is disabled or explicitly set to
+level 0.)
 
 This year marked an all time high for number of entries as well as the
 quality of entries.  Nearly twice the usual number of entries made it
 to the final judging rounds.  Even when we raised the standards for
-winning, we still wound up giving out a few more awards than in other
+winning, we still wound up giving out a few more awards than in previous
 years.  The new size rules size probably contributed to the overall
 high quality.
 

1993/README.md

@@ -60,7 +60,7 @@ See also [the IOCCC FAQ](../faq.html) for addition information on the IOCCC.
 ### Credits:
 
 We would like to thank Barbara Frezza for her role as official chef
-of the contest.  Landon Noll and Larry Bassel appreciated the opportunity
+of the contest.  Landon Curt Noll and Larry Bassel appreciated the opportunity
 to serve as official taste testers.  And as usual, the food was excellent.
 
 

1994/README.md

@@ -39,7 +39,7 @@ The ideal 3rd judge would have all of the following:
 
 * thorough knowledge of the C language (ANSI and K&R)
 * thorough knowledge of common C libs (libc, libm, curses, ...)
-* reasonable written communication skills (able to write `README.md` files)
+* reasonable written communication skills (able to write `README.md` files, for example)
 * appreciation for well-written non-obfuscated code
 * willing to devote ~4 weekend days in January (starting Jan 96) for judging
 * located in the San Francisco (California, US) Bay Area, or
@@ -112,7 +112,7 @@ judges@toad.com
 ```
 
 If you use, distribute or publish these entries in some way, please drop
-us a line.  We enjoy seeing who, where and how the contest is used.
+us a line.  We enjoy seeing who, where and how the contest is used,
 as well as details on how to provide fixes to any of the entries.
 
 
@@ -128,7 +128,7 @@ See also [the IOCCC FAQ](../faq.html) for addition information on the IOCCC.
 ## Credits
 
 We would like to thank Barbara Frezza for her role as official chef
-of the contest.  Landon Noll and Larry Bassel appreciated the opportunity
+of the contest.  Landon Curt Noll and Larry Bassel appreciated the opportunity
 to serve as official taste testers.  And as usual, the food was excellent.
 The official menu of the 1994 Obfuscated C Contest dinner:
 

1995/README.md

@@ -25,7 +25,7 @@ no longer post the winning entries to this newsgroup - we'll let you the reader
 for yourself the wizardry of these entries.
 
 This year there were several people who won more than once and several [previous
-winning entries](../authors.html) as well. The judging was done without knowledge of the
+winning authors](../authors.html) as well. The judging was done without knowledge of the
 names of the submitters - multiple winning entries were a coincidence. Since we tend to
 discount entries that are similar to previous entries, these people had to come
 with original ideas to stay in the winning entry circle.

1996/README.md

@@ -8,8 +8,7 @@ on how to compile it and how to run the winning program.
 Look at the winning source and try to figure how it does what it does!
 You may then wish to look at the Author's remarks for even more details.
 
-The IOCCC has an official home page: [www.ioccc.org](https://www.ioccc.org)
+The IOCCC has an official home page: [www.ioccc.org](https://www.ioccc.org),
-
 containing previous winning entries, information about the judges,
 announcements and much more.
 

1998/README.md

@@ -8,7 +8,7 @@ on how to compile it and how to run the winning program.
 Look at the winning source and try to figure how it does what it does!
 You may then wish to look at the Author's remarks for even more details.
 
-The IOCCC has its own domain.  The IOCCC has an official home page is now:
+The IOCCC has its own domain.  The IOCCC has an official home page:
 [www.ioccc.org](https://www.ioccc.org).
 
 Use `make` to compile entries.  It is possible that on BSD or non-Unix
@@ -35,9 +35,9 @@ Landon was unable to contact Sriram Srinivasan at the start of
 the 1998 IOCCC season.  Having not heard from Sriram, Landon put out
 a call for new IOCCC judges.  A number of excellent people applied.
 
-Landon selected Leonid A. Broukhis, a two time IOCCC author, as a
+Landon selected Leonid A. Broukhis, a two time IOCCC winning author, as a
 co-judge.   Landon and Leo together selected Jeremy Horn and Peter
-Seebach.  The four judges (../judges.html) together worked
+Seebach.  The four [judges](https://www.ioccc.org/judges.html) together worked
 thru-out the 1998 IOCCC season.
 
 
@@ -64,7 +64,7 @@ for the fact that they didn't work.  If you didn't win, but think you
 had a chance: test your program, fix it and submit it next year!
 
 This year we awarded some outstanding entries.  We recommend that you
-look at all of the winning enties.  The list of winning entries is a bit too long to
+look at all of the winning entries.  The list of winning entries is a bit too long to
 say something about every entry.  On the other hand a partial mention
 of a few is in order:
 
@@ -76,7 +76,7 @@ of a few is in order:
   impressed with CPP code expansion liked the entry that translated
   lambda expressions into combinator expressions.
 - Logic minded folks will get somewhat twisted up while following the
-  flow of the [Best Flow Control entry](1998/schnitzi/index.html).
+  flow of the [Best Flow Control entry](schnitzi/index.html).
 - Those who know the PostScript language will be 'bemused' by
   the [Best Encapsulation entry](bas1/index.html).
 
@@ -124,9 +124,7 @@ You must include the words 'ioccc question' in the subject of your email
 message when sending email to the judges.
 
 The next IOCCC is planned to start towards the end of 1999.  Watch
-[www.ioccc.org](https://www.ioccc.org)
+[www.ioccc.org](https://www.ioccc.org) for news of the next contest.
-
-for news of the next contest.
 
 
 # Copyright and License

2000/README.md

@@ -13,7 +13,7 @@ systems the Makefile needs to be changed.  See the Makefile for details.
 
 Read over the Makefile for compile/build issues.  Your system may
 require certain changes (add or remove a library, add or remove a
-#define).
+`#define`).
 
 Some ANSI C compilers are not quite as good as they should be.  If
 yours is lacking, you may need to compile using gcc instead of your
@@ -24,10 +24,9 @@ local compiler.
 
 The judges were unable to contact Jeremy Horn for judging the 2000 contest.
 
-As a result, Simon Cooper: <http://www.sfik.com/>
+As a result, [Simon Cooper](http://www.sfik.com/) joined our team.  Simon is
-
+well known for being a co-author of the 2nd edition of the Building Internet
-joined our team.  Simon is well known for being a co-author of the 2nd
+Firewalls book.
-edition of the Building Internet Firewalls book.
 
 
 ## Remarks on some of the entries
@@ -55,7 +54,7 @@ using it next time ... :-)
 
 Speaking of time, be sure to check out the [Astronomically
 Obfuscated](rince/index.html) and the [Most Timely
-Output](schneiderwent/index.html).
+Output](schneiderwent/index.html) entries.
 
 
 ## There was no 1999 contest

2001/README.md

@@ -39,7 +39,7 @@ them for the next IOCCC.
 We believe you will be impressed with this year's winning entries  The [Best of
 Show](ollinger/index.html) is a fine example of obfuscation.  But don't ignore
 the other entries!  There are games, programs that speak, ones that compile code
-and [one that might run binaries you already have](2001/anonymous/index.html).
+and [one that _might_ run binaries you already have](2001/anonymous/index.html).
 
 The [Best/Worst Abuse of the Rules](bellard/index.html) is technically allowed by the
 [rules](rules.txt).  This year we awarded it again, but don't assume you can get

2005/README.md

@@ -31,41 +31,42 @@ We believe you will be impressed with this year's winning entries.
 
 In particular:
 
-+ The [Abuse of the rules](klausler/klausler.c) used local dictionary data to
++ The [Abuse of the rules (klausler)](klausler/index.html) used local dictionary data to
 get around the size limit.
 
-+ The [Most beauteous visuals](vince/vince.c) made clever use of `{}`s and
++ The [Most beauteous visuals (vince)](vince/index.html) made clever use of `{}`s and
 whitespace in their source code and during execution.
 
-+ The [Most circuitous walk](vik/vik.c) entry is just amazing.
++ The [Most circuitous walk (vik)](vik/index.html) entry is just amazing.
 
-+ The [Best game](toledo/toledo.c) makes full use of its single function.
++ The [Best game (toledo)](toledo/index.html) makes full use of its single function.
 
-+ The [Best emulator](sykes) may allow you to reconnect to your first
++ The [Best emulator (sykes)](sykes/index.html) may allow you to reconnect to your first
 [PET](https://en.wikipedia.org/wiki/Commodore_PET).
 
-+ Our [Best of Show](persano/persano.c) this year was simply (or non-simply :-) ) the best!
++ Our [Best of Show (persano)](persano/index.html) this year was simply (or non-simply :-) ) the best!
 
-+ (And we need only mention (parenthetically speaking) that the best use of parenthesis is self reproducing).
++ (And we need only mention (parenthetically speaking) that the [Best use of
+parenthesis](mikeash/index.html) is self reproducing).
 
-+ The [Most sonorous output](jetro/jetro.c) might `sound` :-) like a good idea.
++ The [Most sonorous output (jetro)](jetro/index.html) might `sound` :-) like a good idea.
 
-+ The [Best 2D puzzle](giljade/giljade.c) takes editorial license with expressions as well as the
++ The [Best 2D puzzle (giljade)](giljade/index.html) takes editorial license with expressions as well as the
 with the [vi editor](https://en.wikipedia.org/wiki/Vi).
 
-+ The [Most ambiguous language](chia/chia.c) entry is really a C program.
++ The [Most ambiguous language (chia)](chia/index.html) entry is really a C program.
 
-+ The [Most superfluous output](boutines/boutines.c) entry is simply
++ The [Most superfluous output (boutines)](boutines/index.html) entry is simply
 [Voronoi](Voronoi)-lific!
 
 + Try not to have your sense of good coding offended by the [Most
-discourteous interpreter](timwi/timwi.c) entry.
+discourteous interpreter (timwi)](timwi/index.html) entry.
 
-+ The [Best use of the www](mynx/mynx.c) doesn't include those letters.
++ The [Best use of the www (mynx)](mynx/index.html) doesn't include those letters.
 
-+ You will be puzzled by the [Best 3D puzzle](anon/anon.c) entry; we are sure!
++ You will be puzzled by the [Best 3D puzzle (anon)](anon/index.html) entry; we are sure!
 
-+ The [Most ingenious puzzle solution](aidan/aidan.c) might puzzle you more while it
++ The [Most ingenious puzzle solution (aidan)](aidan/index.html) might puzzle you more while it
 puzzles out some puzzles: all in a puzzling way!  :-)
 
 ### Remarks on some of the losing entries

2006/README.md

@@ -18,7 +18,7 @@ This year we included most of the information included by the submitters
 in the `README.md` files (that were used to build the `index.html` web pages).
 
 Read over the Makefile for compile/build issues.  Your system may require
-certain changes (add or remove a library, add or remove a #define).
+certain changes (add or remove a library, add or remove a `#define`).
 
 Some ANSI C compilers are not quite as good as they should be.  If
 yours is lacking, you may need to compile using gcc instead of your

2011/README.md

@@ -18,7 +18,7 @@ This year we included most of the information included by the submitters
 in the `README.md` files (that were used to build the `index.html` web pages).
 
 Read over the Makefile for compile/build issues.  Your system may require
-certain changes (add or remove a library, add or remove a #define).
+certain changes (add or remove a library, add or remove a `#define`).
 
 Some ANSI C compilers are not quite as good as they should be.  If
 yours is lacking, you may need to compile using gcc instead of your
@@ -41,7 +41,8 @@ them for the next IOCCC.
 
 We believe you will be impressed with this year's winning entries. The Best
 of Show is a fine example of character stitching.  But don't ignore the other
-entries!  There are games, puzzle solvers, utilities, eye candy, calculators and graphical and audio tools.
+entries!  There are games, puzzle solvers, utilities, eye candy, calculators and
+graphical and audio tools.
 
 This year all authors are different, and there is a authors from a new country -
 China!  Many authors won for the first time. (Please note that judging is done

2012/README.md

@@ -15,7 +15,7 @@ Use `make` to compile entries.  It is possible that on non-Unix / non-Linux
 systems the Makefile needs to be changed.  See the Makefile for details.
 
 Read over the Makefile for compile/build issues.  Your system may require
-certain changes (add or remove a library, add or remove a #define).
+certain changes (add or remove a library, add or remove a `#define`).
 
 Some ANSI C compilers are not quite as good as they should be.  If
 yours is lacking, you may need to compile using gcc instead of your
@@ -33,7 +33,7 @@ This year we selected the top 4 entries for particularly high honors:
 *   Gold award - Balanced use of obfuscation
 
     A very extremely subtle and twisted piece of source code!
-    Even if you start with the zeitak_deobfucate.c source,
+    Even if you start with the zeitak.alt.c source,
     you will still have a very challenging time to understand it!
 
 *   Silver award - Most elementary use of C
@@ -55,9 +55,9 @@ This year we selected the top 4 entries for particularly high honors:
 But don't ignore the other winning entries!  There are games, utilities,
 eye candy, calculators and graphical tools to explore.
 
-This year, Yusuke Endoh won with two entries, one of which (endoh1)
+This year, Yusuke Endoh won with two entries, one of which
-won the special Honorable mention award.  Eight of the winning entries
+([endoh1](endoh1/index.html)) won the special Honorable mention award.  Eight of
-were from people who won in previous years.
+the winning entries were from people who won in previous years.
 
 This year we had a number of authors from Asia.  We saw our second
 authors from China and first from Korea.  We are pleased to see

2014/README.md

@@ -11,16 +11,16 @@ the Author's remarks for even more details.
 The IOCCC has a web site and now has a number of international mirrors.
 The primary site can be found at [www.ioccc.org](https://www.ioccc.org).
 
-Use make to compile entries.  It is possible that on non-Un\*x / non-Linux
+Use make to compile entries.  It is possible that on non-Unix / non-Linux
-systems the makefile needs to be changed.  See the Makefile for details.
+systems the Makefile needs to be changed.  See the Makefile for details.
 
 Look at the source and try to figure out what the programs do, and run
 them with various inputs.  If you want to, look at the hints files for
 spoilers - this year we included most of the information included
 by the submitter.
 
-Read over the makefile for compile/build issues.  Your system may require
+Read over the README.md for compile/build issues.  Your system may require
-certain changes (add or remove a library, add or remove a #define).
+certain changes (add or remove a library, add or remove a `#define`).
 
 Some ANSI C compilers are not quite as good as they should be.  If
 yours is lacking, you may need to compile using gcc instead of your
@@ -38,14 +38,14 @@ authors submitted very different styles of entries.
 
 This year was the second time the IOCCC size tool was used. Rule 2
 required that when program source is fed as input to the current IOCCC size
-tool, and the IOCCC size tool -i command line option is used, the value
+tool, and the IOCCC size tool `-i` command line option is used, the value
 printed should be less than or equal to 2053.
 
-We were pleased to see that abuse of the rules was extended to abuse
+We were pleased to see that abuse of the rules was extended to abuse to the
-to the IOCCC size tool.  Matt Zucker, followed by a few users, were
+IOCCC size tool.  [Matt Zucker](../authors.html#Matt_Zucker), followed by a few
-able to discover cleaver use of certain // comments to perplex the size tool.
+users, were able to discover clever use of certain `//` comments to perplex the
-The abuse was so bad that the judges released a critical and mandatory
+size tool.  The abuse was so bad that the judges released a critical and
-patch to the IOCCC size tool on 2014-09-23.
+mandatory patch to the IOCCC size tool on 2014-09-23.
 
 There were some great entries that did not win.  Unfortunately
 some entries lost because they:
@@ -71,7 +71,7 @@ in some particularly impressive way.
 
 We apologize on the delay of sending the authors the tarball for them
 to review.  There were some unforeseen events, such as unplanned mandatory
-business travel, the death of a IOCCC judge mother, etc. that impacted
+business travel, the death of an IOCCC judge's mother, etc. that impacted
 our planned schedule for building the tarball of this year's winning entries.
 
 During some of these forced delays, we took the time to better automate
@@ -81,7 +81,7 @@ these changes made during those delays will make releasing future winning IOCCC
 entries a faster procedure.
 
 p.s. The final advice given to Landon by his mom: "Have fun."
-We recommend following this advice were possible.
+We recommend following this advice where possible.
 
 
 ## Final Comments

2015/README.md

@@ -6,21 +6,20 @@
 View the `index.html` web page for the given winning entry for information on how
 compile the entry and how to run the winning program.  Look at the winning
 source and try to figure how it does what it does!  You may then wish to look at
-the Author's remarks for even more details.
+the Author's remarks for even more details. This year we included most of the
+information included by the submitter.
 
 The IOCCC has a web site and now has a number of international mirrors.
 The primary site can be found at [www.ioccc.org](https://www.ioccc.org).
 
-Use make to compile entries.  It is possible that on non-Un\*x / non-Linux
+Use `make` to compile entries.  It is possible that on non-Unix / non-Linux
-systems the makefile needs to be changed.  See the Makefile for details.
+systems the Makefile needs to be changed.  See the Makefile for details.
 
 Look at the source and try to figure out what the programs do, and run
-them with various inputs.  If you want to, look at the hints files for
+them with various inputs.
-spoilers - this year we included most of the information included
-by the submitter.
 
-Read over the makefile for compile/build issues.  Your system may require
+Read over the Makefile for compile/build issues.  Your system may require
-certain changes (add or remove a library, add or remove a #define).
+certain changes (add or remove a library, add or remove a `#define`).
 
 Some ANSI C compilers are not quite as good as they should be.  If
 yours is lacking, you may need to compile using gcc instead of your
@@ -33,28 +32,28 @@ We believe you will again be impressed with this year's winning entries.
 
 The fraction of worthy entries was higher than usual.
 
-We call to your attention, the _hou_ entry, that performs the MD5
+We call to your attention the [hou](hou/index.html) entry that performs the MD5
-cryptographic hash.  Normally implemented with a set of integer and
+cryptographic hash.  Normally implemented with a set of integer and boolean
-boolean operations, this code uses floating point variables inside
+operations, this code uses floating point variables inside a single `while` loop
-a single while loop filled with unusual constants, cosine, square
+filled with unusual constants, cosine, square root, and exponent function calls.
-root, and exponent function calls. The number of lines of code
+The number of lines of code is also smaller than the original algorithm.
-is also smaller than the original algorithm.
 
-The _mills2_ source code is a very compressed version of a decompression
+The [mills2](mills2/index.html) source code is a very compressed version of a
-algorithm.  We think those who enjoy compression algorithms will
+decompression algorithm.  We think those who enjoy compression algorithms will
 particularly enjoy this entry.
 
-We suggest that you attempt to completely understand the _endoh4_
+We suggest that you attempt to completely understand the
-1-liner program: another impressive compact piece of C code.
+[endoh4](endoh4/index.html) 1-liner program: another impressive compact piece of
+C code.
 
-And while you are at it, cat the _endoh2_ prog.c code.  Compile it
+And while you are at it, cat the [endoh2 prog.c](endoh2/prog.c) code.  Compile it
 and look at the source code again.
 
-In a "Back to the Future" moment, _endoh3_ gave us a twist on one of
+In a "Back to the Future" moment, [endoh3](endoh3/index.html) gave us a twist on
-the all time best IOCCC entries from 1984.
+one of the all time best IOCCC entries from 1984.
 
-We also suggest that you take a very good look at how the _muth_ code
+We also suggest that you take a very good look at how the
-makes full use of the C Pre-Processor.
+[muth](muth/index.html) code makes full use of the C Pre-Processor.
 
 ...We'll stop spouting spoilers now. Have fun exploring all the entries!
 
@@ -78,12 +77,14 @@ Rule 22, now known as **Catch 22** states:
 |      to be Peter Honeyman, will be grounds for disqualification of your entry.
 ```
 
-A number of other entries were based on iocccsize.c, making derivative works
+A number of other entries were based on [iocccsize.c](iocccsize.c), making
-rather than original works.
+derivative works rather than original works.
 
 Still other entries were too large, violating the first line of rule 2:
 
+```
 2) The size of your program source must be <= 4096 bytes in length.
+```
 
 While these entries might have passed under the 2053 limit for iocccsize,
 they were larger than <= 4096 bytes, sometimes by an order or magnitude.

2018/README.md

@@ -6,7 +6,8 @@
 View the `index.html` web page for the given winning entry for information on how
 compile the entry and how to run the winning program.  Look at the winning
 source and try to figure how it does what it does!  You may then wish to look at
-the Author's remarks for even more details.
+the Author's remarks for even more details. This year we included most of the
+information included by the submitter.
 
 The primary site can be found at [www.ioccc.org](https://www.ioccc.org).
 
@@ -14,12 +15,11 @@ Use `make` to compile entries.  It is possible that on non-Unix / non-Linux
 systems the Makefile needs to be changed.  See the Makefile for details.
 
 Look at the source and try to figure out what the programs do, and run
-them with various inputs.  If you want to, look at the hints files for
+them with various inputs.
-spoilers - this year we included most of the information included
-by the submitter.
 
-Read over the Makefile for compile/build issues.  Your system may require
+Read over the Makefile and index.html files for compile/build issues.  Your
-certain changes (add or remove a library, add or remove a #define).
+system may require certain changes (add or remove a library, add or remove a
+`#define`).
 
 Some C compilers are not quite as good as they should be.  If yours is
 lacking, you may need to compile using clang or gcc instead of your local
@@ -30,24 +30,24 @@ compiler.
 
 We believe you will again be impressed with this year's winning entries.
 
-The "Best of show" (mills) is an amazing tribute to entrues
+The ["Best of show" (mills)](mills/index.html) is an amazing tribute to entries
 from 1984 and 2015.
 
-Take a close look at the "Most likely to top the charts" [2018/hou](hou/index.html)
+Take a close look at the "[Most likely to top the charts" (hou)](hou/index.html).
 Observe that while it contains no variables and no operators, it
 remains functional in what it does.
 
-The "Best one-liner" (burton1), at 109 characters, is a short and sweet
+The ["Best one-liner" (burton1)](burton1/index.html), at 109 characters, is a
-implementation of a classic utility and a nod to a winning entry from 1986.
+short and sweet implementation of a classic utility and a nod to a winning entry
-Sometimes it takes 20 ox years to do things the true IOCCC way.
+from 1986.  Sometimes it takes 20 some years to do things the true IOCCC way.
 
 The color of the remarks text this year was inspired by one of the stars
-of the "Most stellar" [2018/poikola](poikola/index.html).
+of the ["Most stellar" (poikola)](poikola/index.html).
 
-The "Best use of python" (endoh2) is a not what you might think it is.
+The ["Best use of python" (endoh2)](endoh2/index.html) is a not what you might think it is.
 It is something completely different.
 
-The "Most likely to be awarded" (ciura) has an amazing vocabulary!
+The ["Most likely to be awarded" (ciura)](ciura/index.html) has an amazing vocabulary!
 
 There are also nods to entries of the years [2000/bellard](2000/bellard/index.htmk),
 [1989/yang](1989/yang/index.html), ...
@@ -63,21 +63,23 @@ and 22 (one third of 666).
 
 Rule 22, now known as "Catch 22" states:
 
-    |  22) Your source code, data files, remarks and program output must NOT
+```
-    |      identify the authors of your code.  The judges STRONGLY prefer to
+|  22) Your source code, data files, remarks and program output must NOT
-    |      not know who is submitting entries to the IOCCC.
+|      identify the authors of your code.  The judges STRONGLY prefer to
+|      not know who is submitting entries to the IOCCC.
 
-    |      The "Peter Honeyman is exempt" guideline also applies to this rule.
+|      The "Peter Honeyman is exempt" guideline also applies to this rule.
-    |      Identifying yourself, in an obvious way in your code, data, remarks
+|      Identifying yourself, in an obvious way in your code, data, remarks
-    |      or program output, unless you are Peter Honeyman or pretending
+|      or program output, unless you are Peter Honeyman or pretending
-    |      to be Peter Honeyman, will be grounds for disqualification of your entry.
+|      to be Peter Honeyman, will be grounds for disqualification of your entry.
+```
 
-A number of other entries were based on iocccsize.c, making derivative works
+A number of other entries were based on [iocccsize.c](iocccsize.c), making
-rather than original works.
+derivative works rather than original works.
 
 Still other entries were too large, violating the first line of rule 2:
 
-    2) The size of your program source must be <= 4096 bytes in length.
+> 2) The size of your program source must be <= 4096 bytes in length.
 
 While these entries might have passed under the 2053 limit for iocccsize,
 they were larger than <= 4096 bytes, sometimes by an order or magnitude.

2019/README.md

@@ -13,8 +13,9 @@ The primary site can be found at [www.ioccc.org](https://www.ioccc.org).
 Use `make` to compile entries.  It is possible that on non-Unix / non-Linux
 systems the Makefile needs to be changed.  See the Makefile for details.
 
-Read over the Makefile for compile/build issues.  Your system may require
+Read over the Makefile and index.html files for compile/build issues.  Your
-certain changes (add or remove a library, add or remove a #define).
+system may require certain changes (add or remove a library, add or remove a
+`#define`).
 
 Some C compilers are not quite as good as they should be.  If yours is
 lacking, you may need to compile using clang or gcc instead of your local
@@ -25,9 +26,11 @@ compiler.
 
 This year's winning entries are impressive!
 
-The "Most in need of debugging" (endoh) is very inventive in a way it produces its own text!
+The ["Most in need of debugging" (endoh)](endoh/index.html) is very inventive in
+a way it produces its own text!
 
-The "Most likely to be awarded" (ciura) has an amazing vocabulary!
+The ["Most likely to be awarded" (ciura)](ciura/index.html) has an amazing
+vocabulary!
 
 There are again nods to entries of the years:
 
@@ -36,12 +39,14 @@ There are again nods to entries of the years:
 
 These nods to not run afoul of the guideline:
 
-	We tend to dislike programs that:
+```
-	...
+We tend to dislike programs that:
-	are rather similar to previous entries
+...
+are rather similar to previous entries
+```
 
-because the entry [2019/dogon](2019/dogon/index.html) appropriately pays homage to past entries
+because the entry [2019/dogon](2019/dogon/index.html) appropriately pays homage
-without blatantly reusing their code.
+to past entries without blatantly reusing their code.
 
 ...We'll stop spouting spoilers now. Have fun exploring all the entries!
 
@@ -56,7 +61,7 @@ uninitialized locals and/or reading-writing below the stack.
 We advise running your entry through valgrind to make sure those mistakes
 are avoided.
 
-Using extra arguments to main, or arguments of wrong types as a quick and dirty
+Using extra arguments to `main`, or arguments of wrong types as a quick and dirty
 way of declaring variables is now passé. Clang, for example, rejects them outright.
 
 We hope the authors of some of those entries will fix and re-submit

2020/README.md

@@ -13,8 +13,9 @@ The primary site can be found at [www.ioccc.org](https://www.ioccc.org).
 Use `make` to compile entries.  It is possible that on non-Unix / non-Linux
 systems the Makefile needs to be changed.  See the Makefile for details.
 
-Read over the Makefile for compile/build issues.  Your system may require
+Read over the Makefile and index.html files for compile/build issues.  Your
-certain changes (add or remove a library, add or remove a #define).
+system may require certain changes (add or remove a library, add or remove a
+`#define`).
 
 Some C compilers are not quite as good as they should be.  If yours is
 lacking, you may need to compile using clang or gcc instead of your local
@@ -23,37 +24,42 @@ compiler.
 
 ## Remarks on some of the winning entries
 
-This year's Best of Show (carlini) is such a novel way of obfuscation that it would be
+This year's [Best of Show (carlini)](carlini/index.html) is such a novel way of
-worth of a special mention in the (future) Best of IOCCC list!
+obfuscation that it would be worth of a special mention in the (future) Best of
+IOCCC list!
 
 For some reason, this year's set of winning entries contains three nostalgic games,
-Asteroids (tsoj), Minesweeper (endoh1), and Snake (ferguson1).
+[Asteroids (tsoj)](tsoj/index.html), [Minesweeper (endoh1)](endoh1/index.html),
+and [Snake (ferguson1)](ferguson1/index.html).
 
-An entry (kurdyukov1) pays homage to a previous entry [2015/hou](2015/hou/index.htm0).
+An entry ([kurdyukov1](kurdyukov1/index.html)) pays homage to previous entry
+[2015/hou](2015/hou/index.htm0).
 
 ...We'll stop spouting spoilers now. Have fun exploring all the entries!
 
 
 ## Remarks on some of submissions that did not win
 
-As a rule, we try to compile the entries on a variety of platforms.
+As a rule, we try to compile the entries on a variety of platforms.  Quite a few
-Quite a few entries this year could not be built or executed on some of them due to reliance on
+entries this year could not be built or executed on some of them due to reliance
-library internals or the system runtime.
+on library internals or the system runtime.
 
-A few entries were violating the "2053 significant bytes" rule. If an entry could not be brought to
+A few entries were violating the "2053 significant bytes" rule. If an entry
-compliance within a few seconds of looking at the source, it was disqualified.
+could not be brought to compliance within a few seconds of looking at the
+source, it was disqualified.
 
 One entry tried to get around the size limit by putting the code into
-Makefile variables and using -D. This is already called out as discouraged
+Makefile variables and using `-D`. This is already called out as discouraged
 technique in the guidelines, but it is worth a reminder.
 
-Several promising entries attempted to make use of the `syscall` function using literal syscall numbers.
+Several promising entries attempted to make use of the `syscall` function using
-This is utterly non-portable.
+literal syscall numbers.  This is utterly non-portable.
 
-A note to the authors: when submitting multiple entries, don't let us easily correlate them by
+A note to the authors: when submitting multiple entries, don't let us easily
-coding style or documentation content, and definitely don't submit nearly identical versions
+correlate them by coding style or documentation content, and definitely don't
-of your program separately. As we try to judge the entries anonymously, the similarities will cause such
+submit nearly identical versions of your program separately. As we try to judge
-entries to compete against one another, making each less likely to win.
+the entries anonymously, the similarities will cause such entries to compete
+against one another, making each less likely to win.
 
 We hope the authors of non-winning entries will refine their entries and
 perhaps re-submit them for the next IOCCC.
@@ -61,6 +67,8 @@ perhaps re-submit them for the next IOCCC.
 
 ## Final Comments
 
+One more thing that feels dated is digraphs and trigraphs.
+
 **IMPORTANT NOTE**: See [contact.html](../contact.html) for up to date contact details
 as well as details on how to provide fixes to any of the entries.
 See also [the IOCCC FAQ](../faq.html) for addition information on the IOCCC.

tmp/things-todo.md

@@ -1,5 +1,5 @@
 # A todo list of known things to check and/or do
-*Last updated: Thu 07 Mar 2024 16:59:49 UTC*
+*Last updated: Thu 07 Mar 2024 18:16:13 UTC*
 
 This document is for [Cody Boone Ferguson](/authors.html#Cody_Boone_Ferguson) as
 he (that is I :-) ) wanted a way to keep track of things in a way that did not
@@ -15,15 +15,6 @@ something needs to be done is thought of it is also updated unless it can be
 done right then and there or it seems more appropriate to add to the issue (#3)
 todo list.
 
-- Typo fix ALL markdown files. For the README.md files the entries have all been
-done (along with format fixes) but the YYYY/README.md files have not been
-completed.
-    * Go through all year README.md files: that is 1984/README.md,
-    1985/README.md and so on. As of **Mon 16 Oct 11:22:52 UTC 2023** the
-    following years have had a first pass: 1984 through 2001. However there are
-    changes that might be required in those years too so a pass over all of them
-    will have to be done at the time the files are to be reviewed.
-
 - Check that the following todo tasks at:
     <https://github.com/ioccc-src/temp-test-ioccc/issues/3#issuecomment-1583833132>
     and