Files
ioccc/2013
Cody Boone Ferguson 8125a24fdb Make award titles more consistent
A lot of the award titles that had more than one word capitalised were
changed to just one word capitalised, the first. Some were changed to
have multiple words capitalised. This happened when it was something
like '... prize' or '... award'. An exception to this is 2020/ferguson1:
'Don't tread on me award'. This is because I am not quite sure if I like
'Don't Tread On Me Award' or if it should be 'Don't Tread on Me Award'
(probably not that). For some like 'Grand Prize' or 'Bill Gates Award'
it's simple but I'm not so sure for my Snake entry of 2020. I will try
changing it and comparing it side-by-side to see which looks nicest.

This commit should make it easier to update the form of the award titles
in that they should all be consistent (or more consistent if not
completely) though it should be noted that the macOS Numbers application
(spreadsheet) is case-insensitive. A reason I did not change 'Don't
tread on me award' to 'Don't Tread On Me Award', yet, besides the above
reasons, is that it's a longer title and I am not sure how I like that
many words capitalised. Still it's a title of a slogan/whatever so it
might be better that way. This will be determined in the near future.

The tmp/year_prize.numbers had the text size increased a fair bit as
the default is too small for my pitiful vision (I changed it within
reason as it can become harder in another way if it's too big - 16"
MacBook Pro screen). One of the columns was also widened as it was too
short even for the smaller size.
2024-06-14 06:52:23 -07:00
..
2024-06-14 06:52:23 -07:00
2024-06-14 06:52:23 -07:00
2024-06-14 06:52:23 -07:00
2024-02-01 14:35:49 -08:00
2024-03-20 16:03:01 -07:00
2024-06-07 02:10:24 -07:00
2024-06-07 02:10:24 -07:00
2023-10-07 04:35:47 -07:00

Twenty Second International Obfuscated C Code Contest

Standard IOCCC stuff

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 IOCCC has a website and now has a number of international mirrors. The primary site can be found at 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 might require certain changes (add or remove a library, add or remove a #define i.e. -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.

Remarks on some of the entries

We believe you will again be impressed with this year's winning entries.

This year, 9 won 15 awards. For the first time in the history of the contest, one person, Yusuke Endoh won 4 times while Adrian Cable won 3 times! It is also worth noting that Chris Mills last win was in 1993. Welcome back Chris!

We, the judges, were very surprised by this as many of the multiple authors submitted very different styles of entries.

This year was the first time the IOCCC size tool was used. Entries had to print a value 2053 or less when the -i flag was used.

Several people discovered an undocumented feature in that certain comments such as:

	///*

or:

	*\
	/

were not correctly parsed by the tool. The guidelines stated:

    In cases where the above summary and the algorithm implemented by
    the IOCCC size tool source code conflict, the algorithm implemented
    by the IOCCC size tool source code is preferred by the judges.

so this abuse was allowed (and encouraged). The judges hope that the IOCCC size tool author will patch the tool to block this kind of size abuse in future contests.

There were some outstanding entries that did not win. Unfortunately some very good entries lost because they:

  • were way way oversized and didn't even attempt to justify their excess by a clever abuse of the rules
  • depended on a single obfuscation trick
  • could only be run on a particular vendor's platform
  • were very similar to previous winning entry
  • didn't work as documented

We hope that the authors of some of those entries will fix and resubmit them for the next IOCCC.

There is a risk in submitting an entry that is similar to a well used theme by previous winning entries. Previous entries set a very high bar. A new entry must not only compete against other submissions from the current year but they must also excel over similar previous winning entry in some particularly impressive way.

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 additional information on the IOCCC.