Cody Boone Ferguson
73fc551f70
This is not only to help with formatting - especially important in markdown files - but it's no longer really necessary to do it. One might not feel the need to do it in non-markdown files but I did it anyway to be consistent. Thus instead of showing Un*x/UN*X it shows Unix/UNIX. A question of whether or not it should all be the same case is another thing entirely but if this is desired at some point it should be easy to do anyway - with some care in case it's in formatted text. A note about the glob: why '.' when there are C files and other file types where it could be dangerous to modify? Because I did a git grep first so I knew that it was safe.
678 lines
29 KiB
Plaintext
678 lines
29 KiB
Plaintext
11th International Obfuscated C Code Contest Guidelines, Hints and Comments
|
|
|
|
Copyright (c) Landon Curt Noll & Larry Bassel, 1994.
|
|
All Rights Reserved. Permission for personal, education or non-profit use is
|
|
granted provided this this copyright and notice are included in its entirety
|
|
and remains unaltered. All other uses must receive prior permission in writing
|
|
from both Landon Curt Noll and Larry Bassel.
|
|
|
|
|
|
ABOUT THIS FILE:
|
|
|
|
This file is intended to help people who wish to submit entries to
|
|
the International Obfuscated C Code Contest (IOCCC for short).
|
|
|
|
This is not the IOCCC rules, though it does contain comments about
|
|
them. The guidelines should be viewed as hints and suggestions.
|
|
Entries that violate the guidelines but remain within the rules are
|
|
allowed. Even so, you are safer if you remain within the guidelines.
|
|
|
|
You should read the current IOCCC rules, prior to submitting entries.
|
|
The rules are typically sent out with these guidelines.
|
|
|
|
Changes from the original 1993 rules are denoted by change bars. ---> |
|
|
|
|
|
|
WHAT IS NEW IN 1994: |
|
|
|
|
It now appears that most ANSI C compilers allow indexes to be of |
|
|
non-integral type. Unlike last year, we now allow one to use |
|
|
constructs such as: |
|
|
|
|
int h; |
|
|
char *i; |
|
|
... |
|
|
h[i] = (h+3)["string"]; |
|
|
|
|
The ---build--- section may use "gcc" or "cc" commands. However, your |
|
|
entry should be compilable with any ANSI C compiler. You should not |
|
|
depend on a gcc specific feature. |
|
|
|
|
The order of your entry's sections must be the same as the order of |
|
|
the rule template or the example below. |
|
|
|
|
We have added a new rule regarding rule abuse. The guidelines expand |
|
|
on the rule abuse aspect of the contest. |
|
|
|
|
A suggestion regarding VTxxx/ANSI escape sequences has been given. |
|
|
|
|
|
|
HINTS AND SUGGESTIONS:
|
|
|
|
You are encouraged to examine the winners of previous contests. See
|
|
FOR MORE INFORMATION for details on how to get previous winners.
|
|
|
|
Keep in mind that rules change from year to year, so some winning entries
|
|
may not be valid entries this year. What was unique and novel one year
|
|
might be 'old' the next year.
|
|
|
|
An entry is usually examined in a number of ways. We typically apply
|
|
a number of tests to an entry:
|
|
|
|
* look at the original source
|
|
* convert ANSI trigraphs to ASCII
|
|
* C pre-process the source ignoring '#include' lines
|
|
* C pre-process the source ignoring '#define' and '#include' lines
|
|
* run it through a C beautifier
|
|
* examine the algorithm
|
|
* lint it
|
|
* compile it
|
|
* execute it
|
|
|
|
You should consider how your entry looks in each of the above tests.
|
|
You should ask yourself if your entry remains obscure after it has been
|
|
'cleaned up' by the C pre-processor and a C beautifier.
|
|
|
|
Your entry need not do well under all, or in most tests. In certain
|
|
cases, a test is not important. Entries that compete for the
|
|
'strangest/most creative source layout' need not do as well as
|
|
others in terms of their algorithm. On the other hand, given
|
|
two such entries, we are more inclined to pick the entry that
|
|
does something interesting when you run it.
|
|
|
|
We try to avoid limiting creativity in our rules. As such, we leave
|
|
the contest open for creative rule interpretation. As in real life
|
|
programming, interpreting a requirements document or a customer request
|
|
is important. For this reason, we often award 'worst abuse of the
|
|
rules' to an entry that illustrates this point in an ironic way.
|
|
|
|
We do realize that there are holes in the rules, and invite entries
|
|
to attempt to exploit them. We will award 'worst abuse of the rules'
|
|
and then plug the hole next year. Even so, we will attempt to use
|
|
the smallest plug needed, if not smaller. :-)
|
|
|
|
Check out your program and be sure that it works. We sometimes make
|
|
the effort to debug an entry that has a slight problem, particularly
|
|
in or near the final round. On the other hand, we have seen some
|
|
of the best entries fall down because they didn't work.
|
|
|
|
We tend to look down on a prime number printer, that claims that
|
|
16 is a prime number. If you do have a bug, you are better off
|
|
documenting it. Noting "this entry sometimes prints the 4th power
|
|
of a prime by mistake" would save the above entry. And sometimes,
|
|
a strange bug/feature can even help the entry! Of course, a correctly
|
|
working entry is best.
|
|
|
|
People who are considering to just use some complex mathematical |
|
|
function or state machine to spell out something such as "hello, |
|
|
world!" may want to try and be more creative. |
|
|
|
|
Ultra-obfuscated programs are in some cases some cases easier to |
|
|
deobfuscate than subtly-obfuscated programs. Consider using |
|
|
misleading or subtitle tricks layered on top of or under an |
|
|
appropriate level of obfuscation. |
|
|
|
|
Programs that use VTxxx/ANSI sequences that are NOT limited to a |
|
|
specific terminal brand and that can also work in a standard xterm |
|
|
are considered portable. |
|
|
|
|
|
|
OUR LIKES AND DISLIKES:
|
|
|
|
Doing masses of #defines to obscure the source has become 'old'. We
|
|
tend to 'see thru' masses of #defines due to our pre-processor tests
|
|
that we apply. Simply abusing #defines or -Dfoo=bar won't go as far
|
|
as a program that is more well rounded in confusion.
|
|
|
|
Many ANSI C compilers dislike the following code, and so do we:
|
|
|
|
#define d define
|
|
#d foo <-- don't expect this to turn into #define foo
|
|
|
|
When declaring local or global variables, you should declare the type: |
|
|
|
|
int this_is_ok; |
|
|
this_is_not; <-- don't use such implicit type declaration |
|
|
|
|
We suggest that you compile your entry with an ANSI C compiler. If you
|
|
must use non-ANSI C, such as K&R C, you must avoid areas that result in
|
|
compile/link errors for ANSI C compilers.
|
|
|
|
If your entry uses functions that have a variable number of
|
|
arguments, be careful. Systems implement va_list as a wide variety
|
|
of ways. Because of this, a number of operations using va_list are
|
|
not portable and must not be used:
|
|
|
|
* assigning a non-va_list variable to/from a va_list variable
|
|
* casting a non-va_list variable into/from a va_list variable
|
|
* passing a va_list variable to a function expecting a non-va_list arg
|
|
* passing a non-va_list variable to a function expecting a va_list arg
|
|
* performing arithmetic on va_list variables
|
|
* using va_list as a structure or union
|
|
|
|
In particular, do not treat va_list variables as if they were a char **'s.
|
|
|
|
Avoid using <varargs.h>. Use <stdarg.h> instead.
|
|
|
|
If you use C preprocessor directives (#define, #if, #ifdef, ...),
|
|
the leading '#' must be the first character on a line. While some
|
|
C preprocessors allow whitespace the leading '#', many do not.
|
|
|
|
Because the exit() function returns void on some systems, entries
|
|
must not assume that it returns an int.
|
|
|
|
Small programs are best when they are short, obscure and concise.
|
|
While such programs are not as complex as other winners, they do
|
|
serve a useful purpose. They are often the only program that people
|
|
attempt to completely understand. For this reason, we look for
|
|
programs that are compact, and are instructional.
|
|
|
|
One line programs should be short one line programs, say around 80
|
|
bytes long. Getting close to 160 bytes is a bit too long in our opinion.
|
|
|
|
We tend to dislike programs that:
|
|
|
|
* are very hardware specific
|
|
* are very OS or Unix version specific
|
|
(index/strchr differences are ok, but socket/streams specific
|
|
code is likely not to be)
|
|
* dump core or have compiler warnings
|
|
(it is ok only if you warn us in the 'remark' header item)
|
|
* won't compile under both BSD or SYS V like Unix systems |
|
|
* abusing the build file to get around the size limit
|
|
* obfuscate by excessive use of ANSI trigraphs
|
|
* are longer than they need to be
|
|
* are similar to previous winners
|
|
* are identical to previous losers :-)
|
|
|
|
Unless you are cramped for space, or unless you are entering the
|
|
'best one liner' category, we suggest that you format your program
|
|
in a more creative way than simply forming excessively long lines.
|
|
|
|
The build file should not be used to try and get around the size
|
|
limit. It is one thing to make use of a several -D's to help out,
|
|
but it is quite another to use 200+ bytes of -D's in order to
|
|
try and squeeze the source under the size limit. You should feel
|
|
free to make use of the build file space, but you are better off
|
|
if you show some amount of restraint.
|
|
|
|
We want to get away from source that is simply a compact blob of |
|
|
characters. To help, we give a break to source that contains |
|
|
whitespace, and in certain cases ; { or } characters. While the |
|
|
number of characters excluding whitespace (tab, space, newline), |
|
|
and excluding any ; { or } followed by either whitespace or end of |
|
|
file, must be <= 1536, the total size may be less than 3217 |
|
|
bytes. This means that one may use "free of charge" up to 1681 |
|
|
bytes of whitespace, or ; { or } followed by either whitespace |
|
|
or end of file. |
|
|
|
|
Given two versions of the same program, one that is a compact blob
|
|
of code, and the other that is formatted more like a typical C
|
|
program, we tend to favor the second version. Of course, a third
|
|
version of the same program that is formatted in an interesting
|
|
and/or obfuscated way, would definitely win over the first two!
|
|
|
|
We suggest that you avoid trying for the 'smallest self-replicating'
|
|
program. We are amazed at the many different sizes that claim
|
|
to be the smallest. There is nothing wrong with self-replicating
|
|
programs. In fact, a number of winners have been self-replicating.
|
|
You might want to avoid the claim of 'smallest', lest we (or others)
|
|
know of a smaller one!
|
|
|
|
We tend to dislike writable strings. That is, we want to avoid: |
|
|
|
|
char *T = "So many primes, so little time!"; |
|
|
... |
|
|
T[14] = ';'; |
|
|
|
|
You may use writable strings if you really must. If you do depend |
|
|
on them, you must say do in the ---remark--- section. |
|
|
|
|
X client entries should be as portable as possible. Entries that
|
|
adapt to a wide collection of environments will be favored. Don't
|
|
depend on a particular type of display. For example, don't depend
|
|
on color or a given size. Don't require backing store.
|
|
|
|
X client entries should avoid using X related libraries and
|
|
software that is not in wide spread use. We ask that such X client
|
|
entries restrict themselves to only the low level Xlib and the
|
|
Athena widget set (libX11.a, libXaw.a, libXmu.a and libXt.a).
|
|
Don't use M*tif, Xv*ew, or OpenL*ok toolkits, since not everyone
|
|
has them. Avoid depending on a particular window manager. Not
|
|
everyone has X11r5, and some people are stuck back in X11r4 (or
|
|
earlier), so try to target X11r5 without requiring X11r5. Better
|
|
yet, try to make your entry run on all version 11 X Window Systems.
|
|
|
|
X client entries should not to depend on particular items on
|
|
.Xdefaults. If you must do so, be sure to note the required lines
|
|
in the ---remark--- section.
|
|
|
|
We like programs that:
|
|
|
|
* are as concise and small as they need to be
|
|
* do something at least quasi-interesting
|
|
* pass lint without complaint (not a requirement, but it is nice)
|
|
* are portable
|
|
* are unique or novel in their obfuscation style
|
|
* MAKE USE OF A NUMBER OF DIFFERENT TYPES OF OBFUSCATION
|
|
* make us laugh and/or throw up :-)
|
|
|
|
Some types of programs can't excel in some areas. Of course, your
|
|
program doesn't have to excel in all areas, but doing well in several
|
|
areas really does help.
|
|
|
|
We freely admit that interesting, creative or humorous comments in
|
|
the ---remark--- section helps your chance of winning. If you had to
|
|
read of many twisted entries, you too would enjoy a good laugh or two.
|
|
We think the readers of the contest winners do as well.
|
|
|
|
Be creative!
|
|
|
|
|
|
ABUSING THE RULES: |
|
|
|
|
Legal abuse of the rules is somewhat encouraged. Legal rule abuse may |
|
|
involve, but is not limited to, doing things that are technically |
|
|
allowed by the rules and yet do not fit the spirit of what we |
|
|
intended to be submitted. |
|
|
|
|
Legal rule abuse is encouraged to help promote creativity. Rule |
|
|
abuse entries, regardless of if they receive an award, result in |
|
|
changes to the next year's rules and guidelines. |
|
|
|
|
Legal abuse of the rules is NOT an invitation to violate the |
|
|
rules. An entry that violates the rules in the opinion of the |
|
|
judges, WILL be disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL |
|
|
OF RISK! If you have an entry that might otherwise be interesting, |
|
|
you might want to submit two versions; one that does not abuse the |
|
|
rules and one that does. |
|
|
|
|
If you intend to abuse the rules, indicate so in the ---remark--- |
|
|
section. You must try to justify why you consider your rule abuse |
|
|
to be allowed under the rules. That is, you must plead your case |
|
|
as to why your entry is valid. Humor and/or creativity help plead |
|
|
a case. |
|
|
|
|
Abusing the entry format tends to annoy us more than amuse us. |
|
|
|
|
We are often asked why the contest rules and guidelines seem to |
|
|
strange or contain mistakes, flaws or grammatical errors. |
|
|
One reason is that we sometimes make genuine mistakes. But in many |
|
|
cases such problems, flaws or areas of confusion are deliberate. |
|
|
Changes to rules and guidelines in response to a rule abuses, are |
|
|
done in a minimal fashion. Often the we will deliberately leave |
|
|
behind holes (or introduce new ones) so that future rule abuse may |
|
|
continue.
|
|
|
|
At the risk of stating the obvious, this contest is a parity the |
|
|
software development process. The rules and guidelines are |
|
|
only a small part of the overall contest. Even so, one may think |
|
|
the contest rule and guideline process as a parody of the sometimes |
|
|
tragic mismatch between what a customer (or marketing) wants and |
|
|
what engineering delivers. |
|
|
|
|
|
|
ENTRY FORMAT:
|
|
|
|
In order to help us process the many entries, we must request your
|
|
assistance by formatting your entries in a certain way. This format,
|
|
in addition, allows us to quickly separate information about the
|
|
author from the program itself. (see JUDGING PROCESS)
|
|
|
|
We have provided the program, mkentry, as an example of how to
|
|
format entries. You should be aware of the following warning that
|
|
is found in mkentry.c:
|
|
|
|
This program attempts to implement the IOCCC rules. Every
|
|
attempt has been made to make sure that this program produces
|
|
an entry that conforms to the contest rules. In all cases,
|
|
where this program differs from the contest rules, the
|
|
contest rules will be used. Be sure to check with the
|
|
contest rules before submitting an entry.
|
|
|
|
You are not required to use mkentry. It is convenient, however,
|
|
as it attempts to uuencode the needed files, and attempt to check
|
|
the entry against the size rules.
|
|
|
|
If you have any suggestions, comments, fixes or complaints about
|
|
the mkentry.c program, please send an email to the judges. (see below)
|
|
|
|
The following is a sample entry:
|
|
|
|
---entry---
|
|
rule: 1994
|
|
fix: n
|
|
title: chonglab
|
|
entry: 0
|
|
date: Thu Mar 3 13:23:14 1994
|
|
host: Unix v6, pdp11/45
|
|
2.9BSD, pdp11/70
|
|
---remark---
|
|
This is a non-obfuscated obfuscated C program.
|
|
|
|
It is likely not to win a prize. But what do you expect from
|
|
a short example!
|
|
---author---
|
|
name: Landon Curt Noll
|
|
org: IOCCC Judging Group
|
|
addr: Toad Hall
|
|
PO Box 170608
|
|
San Francisco, California
|
|
94117-0608
|
|
USA
|
|
email: {chongo,noll}@{toad,sgi}.com
|
|
anon: n
|
|
---author---
|
|
name: Larry Bassel
|
|
org: IOCCC Judging Group
|
|
addr: Toad Hall
|
|
PO Box 170608
|
|
San Francisco, California
|
|
94117-0608
|
|
USA
|
|
email: hoptoad!sun!lab
|
|
lab@sun.com
|
|
anon: n
|
|
---info---
|
|
begin 444 info.file
|
|
M0V]P>7)I9VAT("AC*2!,86YD;VX@0W5R="!.;VQL+"`Q.3DS+@I!;&P@4FEG
|
|
M:'1S(%)E<V5R=F5D+B`@4&5R;6ES<VEO;B!F;W(@<&5R<V]N86PL(&5D=6-A
|
|
M=&EO;B!O<B!N;VXM<')O9FET('5S92!I<PIG<F%N=&5D('!R;W9I9&5D('1H
|
|
M:7,@=&AI<R!C;W!Y<FEG:'0@86YD(&YO=&EC92!A<F4@:6YC;'5D960@:6X@
|
|
M:71S(&5N=&ER971Y"F%N9"!R96UA:6YS('5N86QT97)E9"X@($%L;"!O=&AE
|
|
M<B!U<V5S(&UU<W0@<F5C96EV92!P<FEO<B!P97)M:7-S:6]N(&EN('=R:71I
|
|
M;F<*9G)O;2!,86YD;VX@0W5R="!.;VQL+@H*5&AA="!T:&%T(&ES+"!I<RX*
|
|
M5&AA="!T:&%T(&ES(&YO="P*("`@(&ES(&YO="!T:&%T('1H870@;F]T(&ES
|
|
M+@I4:&%T(&ES+"!T:&%T('1H870@:7,@;F]T+"!I<R$*"@D)+2T@8VAO;F=O
|
|
M(#$Y-S0*"DEN(#$Y.3(L(&]N92!P97)S;VX@=&]L9"!U<R!T:&%T('1H97D@
|
|
M86-T=6%L;'D@9&5C;V1E9"!T:&ES(&9I;&4N("!);@HQ.3DS(&$@9F5W(&UO
|
|
M<F4@9&ED('1H92!S86UE+B`@22!W;VYD97(@:&]W(&UA;GD@=VEL;"!D;R!I
|
|
-="!T:&ES('EE87(_"@``
|
|
`
|
|
end
|
|
---build---
|
|
begin 444 build
|
|
99V-C("UA;G-I('!R;V<N8R`M;R!P<F]G"@``
|
|
`
|
|
end
|
|
---program---
|
|
begin 444 prog.c
|
|
M;6%I;B@I"GL*(VEF("%D969I;F5D*$Y/5%]!7U)%1TE35$52141?5D]415)?
|
|
M24Y?4U5.3EE604Q%7T-!3$E&3U).24%?55-!*0H@("`@<')I;G1F*"),86YD
|
|
M;VX@3F]L;"!W87,@96QE8W1E9"!T;R!A(#0@>65A<B!T97)M(&]N('1H92!3
|
|
M=6YN>79A;&5<;B(I.PH@("`@<')I;G1F*")#:71Y($-O=6YC:6PN("!4:&%N
|
|
M:R!Y;W4A7&Y<;B(I.PHC96YD:68*("`@('!R:6YT9B@B4W5N;GEV86QE(')E
|
|
M;&%T960@14UA:6P@;6%Y(&)E('-E;G0@=&\Z(&YO;&Q`;F-D+F-O;2Y<;EQN
|
|
M(BD["@H@("`@<')I;G1F*")!="!T:&4@=&EM92!T:&ES('=A<R!W<FET=&5N
|
|
M+"!3=6YN>79A;&4@:&%D(&YO="!Y970@;V)T86EN961<;B(I.PH@("`@<')I
|
|
M;G1F*")A(&1O;6%I;BP@8G5T('!L86YN960@=&\@9&\@<V\@:6X@9G5T=7)E
|
|
@+EQN(BD["B`@("!E>&ET*#(Q-S`Q("4@,3(W*3L*?0H`
|
|
`
|
|
end
|
|
---end---
|
|
|
|
Your entry's sections must be the same order as in the above example. |
|
|
|
|
Typically the build file should assume that the source is prog.c
|
|
and will compile into prog. If an entry wins, we will rename
|
|
its source and binary to avoid filename collision. By tradition,
|
|
we use the name of the entry's title, followed by an optional
|
|
digit in case of name conflicts.
|
|
|
|
If the above entry somehow won the 'least likely to win' award,
|
|
we would use chonglab.c and chonglab.
|
|
|
|
If your entry depends on, or requires that your build, source
|
|
and/or binary files be a particular name, please say so in the
|
|
---remark--- section. If this case applies, it would be be helpful
|
|
if you did one of the following:
|
|
|
|
* Tell us how to change the filename(s) in your entry.
|
|
|
|
* Have the build file make copies of the files. For example:
|
|
|
|
cc prog.c -o special_name |
|
|
|
|
or rm -f special_src.c |
|
|
cp prog.c special_src.c
|
|
cc special_src.c -o special_name
|
|
|
|
or rm -f special_build |
|
|
tail +4 build > special_build
|
|
sh < special_build
|
|
|
|
* Assume that we will use the entry title. Send us a version of
|
|
your build/program files that uses the name convention. You
|
|
should uuencode these files in ---info--- sections. |
|
|
|
|
If your entry needs to modify its source, info or binary files,
|
|
please say so in the ---remark--- section. You should try to avoid
|
|
touching your original build, source and binary files. You should
|
|
arrange to make copies of the files you intend to modify. This
|
|
will allow people to re-generate your entry from scratch.
|
|
|
|
Remember that your entry may be built without a build file. We
|
|
typically incorporate the build lines into a Makefile. If the
|
|
build file must exist, say so in the ---remark--- section.
|
|
|
|
Typically the ---build--- command will contain a "cc" command. |
|
|
It is also ok to use a "gcc" command (and gcc args). However keep |
|
|
in mind that your entry should be compilable by any standard ANSI C |
|
|
compiler and thus should not depend on a special gcc feature. |
|
|
|
|
If your entry needs special info files, you should uuencode them
|
|
into ---info--- sections. In the case of multiple info files,
|
|
use multiple ---info--- sections. If no info files are needed,
|
|
then skip the ---info--- section.
|
|
|
|
Info files are intended to be input, or detailed information that
|
|
does not fit well into the ---remark--- section. For example, an
|
|
entry that implements a compiler might want to provide some sample
|
|
programs for the user to compile. An entry might want to include a
|
|
lengthy design document, that might not be appropriate for a
|
|
'hints' file.
|
|
|
|
Info files should be used only to supplement your entry. For
|
|
example, info files may provide sample input or detailed
|
|
information about your entry. Because they are supplemental,
|
|
the entry should not require them exist.
|
|
|
|
In some cases, your info files might be renamed to avoid name
|
|
conflicts. If info files should not be renamed for some reason,
|
|
say so in the ---remark--- section.
|
|
|
|
Info files must uudecode into the current directory. If they
|
|
absolutely must be renamed, or moved into a sub-directory, say
|
|
so in the ---remark--- section.
|
|
|
|
When submitting multiple entries, be sure that each entry has
|
|
a unique entry number from 0 to 7. Your first entry should
|
|
have entry number 0.
|
|
|
|
With the exception of the header, all text outside of the entry
|
|
format may be ignored. That is, don't place text outside of the
|
|
entry and expect the us to see it. (Our decoding tools are |
|
|
not AI progs!) If you need tell the something, put it in |
|
|
the ---remark--- section, or send an email to the us at: |
|
|
|
|
...!{apple,pyramid,sun,uunet}!hoptoad!judges (not the address for
|
|
judges@toad.com submitting entries)
|
|
|
|
The date should be given with respect to UTC. (Some systems refer
|
|
to this as GMT or GMT0) The format of the date should be that as
|
|
returned by asctime() in the C locale. An example of such a string is:
|
|
|
|
Fri Apr 01 00:47:00 1994 |
|
|
|
|
This format is similar to the output of the date(1) command. The
|
|
string does not include the timezone name before the year. On many
|
|
systems, one of the following command will produce a similar string:
|
|
|
|
date -u "+%a %h %d %T 19%y"
|
|
date -u | sed -e 's/... \(19[0-9][0-9]\)$/\1/'
|
|
sh -c 'TZ=UTC date | sed -e "s/... \(19[0-9][0-9]\)$/\1/"'
|
|
sh -c 'TZ=GMT date | sed -e "s/... \(19[0-9][0-9]\)$/\1/"'
|
|
sh -c 'TZ=GMT0 date | sed -e "s/... \(19[0-9][0-9]\)$/\1/"'
|
|
|
|
You are allowed to update/fix/revise your entry. To do so, set
|
|
the 'fix' line in the ---entry--- section to 'y' instead of 'n'.
|
|
Be sure that the resubmission uses the same title and entry number
|
|
as well, as these are used to determine which entry is to be
|
|
replaced.
|
|
|
|
|
|
JUDGING PROCESS:
|
|
|
|
Entries are judged by Larry Bassel and Landon Curt Noll.
|
|
|
|
Entries are unpacked into individual directories. The email
|
|
is unpacked into individual files, each containing:
|
|
|
|
---entry--- section
|
|
all ---author--- sections
|
|
all ---info--- sections
|
|
---build--- section
|
|
---program--- section
|
|
any other text, including the email headers
|
|
|
|
Prior to judging, the 'any other text' file is scanned to be sure
|
|
it does not contain useful information (or in case the entry was
|
|
malformed and did not unpack correctly). Information from the
|
|
---author--- sections are not read until the judging process is
|
|
complete, and then only from entries that have won an award.
|
|
|
|
The above process helps keep us biased for/against any one particular
|
|
individual. We are usually kept in the dark as much as you are
|
|
until the final awards are given. We like the surprise of finding
|
|
out in the end, who won and where they were from.
|
|
|
|
We attempt to keep all entries anonymous, unless they win an award.
|
|
Because the main 'prize' of winning is being announced, we make all
|
|
attempts to send non-winners into oblivion. We remove all non-winning
|
|
files, and shred all related paper. By tradition, we do not even
|
|
reveal the number of entries that we received. (for the curious,
|
|
we do indicate the volume of paper consumed when presenting the IOCCC
|
|
winners at talks)
|
|
|
|
After the Usenix announcement, we attempt to send an email to the
|
|
authors of the winning entries. One reason we do this is to give
|
|
the authors a chance to comment on the way we have presented their
|
|
entry. They are given the chance to correct mistakes, typos. We
|
|
often accept their suggestions/comments about our remarks as well.
|
|
This is done prior to posting the winners to the wide world.
|
|
|
|
Judging consists of a number of elimination rounds. During a round,
|
|
the collection of entries are divided into two roughly equal piles;
|
|
the pile that advances on to the next round, and the pile that does
|
|
not. We also re-examine the entries that were eliminated in the
|
|
previous round. Thus, an entry gets at least two readings.
|
|
|
|
A reading consists of a number of actions:
|
|
|
|
* reading the ---entry--- section
|
|
* reading the uudecoded ---build--- section
|
|
* reading the uudecoded ---program--- section
|
|
* reading the uudecoded ---info--- section(s), if any
|
|
* passing the source thru the C pre-processor
|
|
shipping over any #include files
|
|
* performing a number of C beautify/cleanup edits on the source
|
|
* passing the beautified source thru the C pre-processor
|
|
shipping over any #include files
|
|
|
|
In later rounds, other actions are performed:
|
|
|
|
* linting the source
|
|
* compiling/building the source
|
|
* running the program
|
|
* performing misc tests on the source and binary
|
|
|
|
Until we reduce the stack of entries down to about 25 entries, entries
|
|
are judged on an individual basis. An entry is set aside because it
|
|
does not, in our opinion, meet the standard established by the round.
|
|
When the number of entries thins to about 25 entries, we begin to form
|
|
award categories. Entries begin to compete with each other for awards.
|
|
An entry often will compete in several categories.
|
|
|
|
The actual award category list will vary depending on the types of entries
|
|
we receive. A typical category list might be:
|
|
|
|
* best small one line program
|
|
* best small program
|
|
* strangest/most creative source layout
|
|
* most useful obfuscated program
|
|
* best game that is obfuscated
|
|
* most creatively obfuscated program
|
|
* most deceptive C code
|
|
* best X client (see OUR LIKES AND DISLIKES)
|
|
* best abuse of ANSI C
|
|
* worst abuse of the rules
|
|
* <anything else so strange that it deserves an award>
|
|
|
|
We do not limit ourselves to this list. For example, a few entries are so
|
|
good/bad that they are declared winners at the start of the final round.
|
|
We will invent awards categories for them, if necessary.
|
|
|
|
In the final round process, we perform the difficult tasks of
|
|
reducing the remaining entries (typically about 25) down to 8 or 10
|
|
winners. Often we are confident that the entries that make it into
|
|
the final round are definitely better than the ones that do not
|
|
make it. The selection of the winners out of the final round, is
|
|
less clear cut.
|
|
|
|
Sometimes a final round entry good enough to win, but is beat out
|
|
by a similar, but slightly better entry. For this reason, it is
|
|
sometimes worthwhile to re-enter an improved version of an entry
|
|
that failed to win in a previous year. This assumes, of course,
|
|
that the entry is worth improving in the first place!
|
|
|
|
More often that not, we select a small entry (usually one line), a
|
|
strange/creative layout entry, and an entry that abuses the contest
|
|
rules in some way.
|
|
|
|
In the end, we traditionally pick one entry as 'best'. Sometimes such
|
|
an entry simply far exceeds any of the other entry. More often, the
|
|
'best' is picked because it does well in a number of categories.
|
|
|
|
|
|
ANNOUNCEMENT OF WINNERS:
|
|
|
|
The first announcement, occurs at a Summer Usenix conference. By tradition,
|
|
this is done during the latter part of the UUNET/IOCCC BOF, just prior to
|
|
the Berkeley BSD, and BSDI BOF.
|
|
|
|
Winning entries will be posted in late June to the following groups:
|
|
|
|
comp.lang.c comp.unix.wizards alt.sources
|
|
|
|
In addition, pointers to these postings are posted to the following
|
|
|
|
comp.sources.d alt.sources.d misc.misc
|
|
comp.sources.misc comp.windows.x
|
|
|
|
Winning entries will be deposited into the uunet archives. See
|
|
below for details.
|
|
|
|
Often, winning entries are published in selected magazines. Winners
|
|
have appeared in books ("The New Hackers Dictionary") and on T-Shirts.
|
|
|
|
Last, but not least, winners receive international fame and flames! :-)
|
|
|
|
|
|
FOR MORE INFORMATION:
|
|
|
|
You may contact the judges by sending an email to the following address:
|
|
|
|
...!{apple,pyramid,sun,uunet}!hoptoad!judges (not the address for
|
|
judges@toad.com submitting entries)
|
|
|
|
Questions and comments about the contest are welcome. Comments about |
|
|
confusing rules and guidelines are also welcome. |
|
|
|
|
The rules and the guidelines may (and often do) change from year to |
|
|
year. You should be sure you have the current rules and guidelines |
|
|
prior to submitting entries.
|
|
|
|
|
|
chongo <Landon Curt Noll> /\cc/\ {chongo,noll}@{toad,sgi}.com
|
|
Larry Bassel lab@sun.com
|