17th International Obfuscated C Code Contest Entry Submission Details

Copyright (C) 2004 Leonid A. Broukhis, Simon Cooper, Landon Curt Noll and
Peter Seebach.

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 the contest judges.


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. Entries that violate the submission instructions may be
disqualified.

WHAT'S NEW IN 2004:

The contest runs from 07-Jan-2004 00:00 UTC to 29-Feb-2004 23:59:59 UTC

An online submission mechanism will be available after 26-Jan-2004, 00:00
UTC. See the following for details,

http://www.ioccc.org/2004/submit

SUBMISSION DETAILS

There are two ways to submit entries.

1) Via email as in previous years.

2) Using the online submission mechanism at

http://www.ioccc.org/2004/submit

NOTE: The online submission mechanism will be available after
26-Jan-2004, 00:00 UTC.

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

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.

NOTE: A copy of the mkentry program may be found at:

http://www.ioccc.org/official/mkentry.c

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 EMail to the judges. (see below)

The following is a sample entry,

---entry---
rule: 2001
fix: y
title: chlejhse
entry: 0
date: Wed Feb 2 00:47:00 2001
host: Un*x v6, pdp11/45
2.9BSD, pdp11/70
---remark---
This is a not-very-obfuscated C program. It is likely not to win a
prize, because it doesn't have what it takes to win and because the
author plans to forget to send it in before the deadline! :-)
---author---
name: Landon Curt Noll
org: IOCCC Judging Group
addr: Toad Hall
PO Box 170608
San Francisco, California
94117-0608
USA
Earth
email: chongo@no_spam.fake.address
nobody@toad.com
url: http://www.isthe.com/chongo/index.html
anon: y
---author---
name: Leonid A. Broukhis
org: IOCCC Judging Group
addr: Toad Hall
PO Box 170608
San Francisco, California
94117-0608
USA
email: leob@no_spam.fake_org
url: http://www.mailcom.com/main.shtml
anon: n
---author---
name: Simon Cooper
org: IOCCC Judging Group
addr: Toad Hall
PO Box 170608
San Francisco, California
94117-0608
USA
email: sc@no_spam.fake_edu
url: http://www.sfik.com
anon: n
---author---
name: Peter Seebach
org: IOCCC Judging Group
addr: Toad Hall
PO Box 170608
San Francisco, California
94117-0608
USA
email: seebs@no_spam.fake_com
url: none
anon: y
---info---
begin 664 info.file
M5&AI<R!F:6QE(&ES(&EN('1H92!P= 6)L:6,@9&]M86EN+@H*:'1T<#HO+W=W
M=RYI;V-C8RYO<F<*"E1H870@=&AA="!I<RP@: 7,N"E1H870@=&AA="!I<R!N
M;W0L"B`@("!I<R!N;W0@=&AA="!T: &%T(&YO="!I<RX*5&AA="!I<RP@=&A A
M="!T:&%T(&ES(&YO="P@:7,A"@H)" 2TM(&-H;VYG;R`Q.3<T"@I/;F4@;6EG
M:'0@<V%Y.@H*"3(@:7,@=&AE(&=R9 6%T97-T(&]D9"!P<FEM92!B96-A=7-E
M(&ET(&ES('1H92!L96%S="!E=F5N( '!R:6UE+@H)4V\@;6%N>2!P<FEM97, @
M+BXN('-O(&QI='1L92!T:6UE(0H*26X@,3DY, BP@;VYE('!E<G-O;B!T;VQD
M('5S('1H870@=&AE>2!A8W1U86QL> 2!D96-O9&5D('1H:7,@9FEL92X@($EN
M"C$Y.3,@86YD(#$Y.30@82!F97<@; 6]R92!D:60@=&AE('-A;64N("!);B`Q
M.3DU+"!A(&YU;6)E<B!O9B!P96]P;&4@9G)O;0I%87-T97)N($5U<F]P92!T
M;VQD('5S('1H870@=&AE>2!D96-O9&5D('1H:7,@9FEL92X@(%-E96US('1H
M97)E(&ES(&$*<VUA;&P@=75D96-O9&4@9W)O=7`@:6X@16%S=&5R;B!%= 7)O
M<&4A("`Z+2D*"E=H>2!D;VXG="!Y; W4@=&5L;"!U<R!W:'D@>6]U(&1E8V]D
M960@=&AI<R!F:6QE(&)Y('-E;F1I;F<@14UA:6P@=&\Z"@H)<75E< W1I;VYS
M0&EO8V-C+F]R9PH*4&5R:&%P<R!Y;W4@;6EG:'0@< W5G9V5S="!A(&)E='1E
M<B!E>&%M<&QE(&9I;&4@86YD('!R; V=R86T@9F]R('1H:7,*<V%M<&QE(&5N
M=')Y/R`@268@>6]U(&1O('-E;F0@:7,@82!B971T97(@97AA;7!L9 2!F:6QE
M+"!B92!W87)N960@+BXN"G1H870@: 70@8V%N;F]T(&)E(&-O;G-I9&5R960@
M87,@82!C;VYT97-T(&5N=')Y+B`@4V\@>6]U(&UI9VAT(&YO=`IW86YT('1O
M('-E;F0@:6X@>6]U<B!B97-T('=O<FL@+BXN('-A=F4@=&AA="!F;W(@=&AE
M(&-O;G1E<W0N("!/;B!T:&4@"F]T:&5R(&AA;F0@+BXN('EO=2!M:6=H= "!W
M86YT('1O('-E;F0@=7,@>6]U<B!M;W-T(&AU;6]R;W5S('=O<FLN("`@.BTI
M"E5U96YC;V1E9"!C<F5D:70@=VEL; "!B92!G:79E;B!I9B!W92!P:6-K('EO
6=7(@97AA;7!L92X*"D9I>GIB:6XA" @``
`
end
---build---
begin 664 build
M9V-C("UA;G-I('!R;V<N8R`M3R`M1%9%4EE?4TE,3 %E?1$5&24Y%("UO('!R
#;V<*
`
end
---program---
begin 664 prog.c
M;6%I;B@I"GL*("`@("\J"B`@("`@* B!.;W0@=F5R>2!O8F9U<V-A=&5D(&)U
M="!T:&5N('=H870@9&ED('EO=2!E> '!E8W0@+BXN('1H:7,@:7,@:G5S=`H @
M("`@("H@82!P;&%C96AO;&1E<B!E> &%M<&QE+@H@("`@("HO"B`@("!P<FE N
M=&8H(E-O;65D87D@22!M:6=H="!W<FET92!A( &)E='1E<B!E>&%M<&QE+EQN
M(BD["B`@("!P<FEN=&8H(D]N('-E8V]N9"!T:&]G=6AT("XN+B!N86@A7&XB
M*3L*("`@('!R:6YT9B@B4V5N9"!U< R!A(&=O;V0@97AA;7!L92!B=70@8F4 @
M=V%R;F5D+"!A;GD@97AA;7!L92!Y; W5<;B(I.PH@("`@<')I;G1F*")S96Y D
M('5S('=I;&P@;F]T(&)E(&-O;G-I9&5R960@87,@86X@96YT<GD@9F]R('1H
M92!C;VYT97-T(5QN(BD["B`@("!P<FEN=&8H(E-O('EO=2!M:6=H="!N;W0@
M=V%N="!T;R!S96YD(&%N(&5X86UP; &4@;V8@>6]U<B!B97-T('=O<FM<;B(I
M.PH@("`@<')I;G1F*"(N+BX@<V%V9 2!T:&%T(&9O<B!T:&4@8V]N=&5S="X@
M($)U="!A(&=O;V0@:'5M;W)O=7,@< ')O9R!M:6=H=%QN(BD["B`@("!P<FEN
M=&8H(F1O("XN+B!A;F0@=V4@=VEL; "!G:79E('EO=2!U=65N8V]D960@8W)E
M9&ET(&EN(')E='5R;BY<;B(I.PH@( "`@+RH@14UA:6PZ('%U97-T:6]N<T!I
M;V-C8RYO<F<@*B\*(VEF("%D969I;F5D* %9%4EE?4TE,3%E?1$5&24Y%*0H@
K("`@;6%I;B@I.PHC96YD:68*("`@( &5X:70H,C,R,#D@)2`Q,C<I.PI]"@``
`
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.

Please note that the title must match the following regexp:

^[a-zA-Z0-9_=][a-zA-Z0-9_=+-]*$

and must be 1 to 31 chars in length. Titles such as:

foo.c
this_invalid_title_is_too_long
/dev/null

are right out! :-)

Titles can be 31 chars long now, but please try to keep them short.
Why 31? Because at least one of the judges likes Mersenne primes!

It is suggested, but not required, that the title should incorporate
the author(s) username(s).

If the above entry somehow won the 'least likely to win' award,
we would use chlejhse.c and chlejhse.

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 us to see it. (Our decoding tools are not AI
progs!) If you need tell the judges something, put it in the
---remark--- section, or send a EMail to:

q.2004@ioccc.org (not the address for submitting entries)

You must include the words 'ioccc 2004 question' in the subject of your
EMail message when sending EMail to the judges.

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:

Wed Feb 2 00:47:00 2001

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 20%y"
date -u sed -e 's/... \(20[0-9][0-9]\)$/\1/'
sh -c 'TZ=UTC date sed -e "s/... \(20[0-9][0-9]\)$/\1/"'
sh -c 'TZ=GMT date sed -e "s/... \(20[0-9][0-9]\)$/\1/"'
sh -c 'TZ=GMT0 date sed -e "s/... \(20[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.

Again, you may want to use the mkentry program may be found at:

http://www.ioccc.org/official/mkentry.c

to format your entry.

Leonid A. Broukhis
Simon Cooper
chongo (Landon Curt Noll) /\cc/\
Peter Seebach