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.
4.0 KiB
Eighteenth International Obfuscated C Code Contest
Standard IOCCC stuff
View the index.html web page for the given winning entry for information on how
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.
The IOCCC has a web site and now has a number of international mirrors. The primary site can be found at https://www.ioccc.org/.
Use make(1) to compile entries. It is possible that on non-Unix / non-Linux
systems the Makefile needs to be changed. See the Makefile for details.
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).
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.
Remarks on some of the entries
We believe you will be impressed with this year's winning entries.
In particular:
-
The Abuse of the rules (klausler) used local dictionary data to get around the size limit.
-
The Most beauteous visuals (vince) made clever use of
{}s and whitespace in their source code and during execution. -
The Most circuitous walk (vik) entry is just amazing.
-
The Best game (toledo) makes full use of its single function.
-
The Best emulator (sykes) may allow you to reconnect to your first PET.
-
Our Best of Show (persano) 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).
-
The Most sonorous output (jetro) might
sound:-) like a good idea. -
The Best 2D puzzle (giljade) takes editorial license with expressions as well as the with the vi editor.
-
The Most ambiguous language (chia) entry is really a C program.
-
The Most superfluous output (boutines) entry is simply Voronoi-lific!
-
Try not to have your sense of good coding offended by the Most discourteous interpreter (timwi) entry.
-
The Best use of the www (mynx) doesn't include those letters.
-
You will be puzzled by the Best 3D puzzle (anon) entry; we are sure!
-
The Most ingenious puzzle solution (aidan) might puzzle you more while it puzzles out some puzzles: all in a puzzling way! :-)
Remarks on some of the losing entries
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; and/or
-
depended too much on a particular byte order; and/or
-
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 resubmit them for the next IOCCC.
Final Comments
IMPORTANT NOTE: See 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 for addition information on the IOCCC.
Copyright and License
Copyright (c) 2005,2023, Landon Curt Noll and Leonid A. Broukhis. All Rights Reserved. This work is licensed under a Creative Commons CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International license. If you do use this work in some form, the IOCCC judges would appreciate (but does not require) if you were to send us a note about your use.