235 lines
10 KiB
Plaintext
235 lines
10 KiB
Plaintext
16th International Obfuscated C Code Contest Rules |
|
|
|
|
Copyright (c) Leonid A. Broukhis, Simon Cooper, Landon Curt Noll and |
|
|
Peter Seebach, 2001. |
|
|
|
|
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.
|
|
|
|
Obfuscate: tr.v. -cated, -cating, -cates. 1. a. To render obscure.
|
|
b. To darken. 2. To confuse: his emotions obfuscated his
|
|
judgment. [LLat. obfuscare, to darken : ob(intensive) +
|
|
Lat. fuscare, to darken < fuscus, dark.] -obfuscation n.
|
|
obfuscatory adj.
|
|
|
|
|
|
GOALS OF THE CONTEST:
|
|
|
|
* To write the most Obscure/Obfuscated C program under the rules below.
|
|
* To show the importance of programming style, in an ironic way.
|
|
* To stress C compilers with unusual code.
|
|
* To illustrate some of the subtleties of the C language.
|
|
* To provide a safe forum for poor C code. :-)
|
|
|
|
The 16th IOCCC contest window is: |
|
|
|
|
01-Oct-2001 00:00 UTC to 01-Dec-2001 23:59:59 UTC |
|
|
|
|
NOTE: Some of the changes from the 2000 rules are denoted by change bars. ---> |
|
|
|
|
|
|
RULES:
|
|
|
|
To help us with the volume of entries, we ask that you follow these rules:
|
|
|
|
1) Your entry must be a complete program.
|
|
|
|
2) The uudecoded size of your program source must be <= 4096 bytes in |
|
|
length. The number of characters (after uudecoding your program) |
|
|
excluding whitespace (tab, space, newline, formfeed, return), and |
|
|
excluding any ; { or } immediately followed by whitespace or end |
|
|
of file, must be <= 2048.
|
|
|
|
3) Your entry must be submitted in the following format:
|
|
|
|
|
NOTE: The change bars are not part of the rules, don't add the |
|
|
change bars to your entry! |
|
|
|
|
---entry---
|
|
rule: 2001 |
|
|
fix: y or n (n => this is a new entry, y => this replaces an older entry)
|
|
title: title of entry (see comments below)
|
|
entry: Entry number from 0 to 7 inclusive (your 1st entry should by 0)
|
|
date: Date/time of submission in UTC (see comments below)
|
|
host: Machine(s) and OS(s) under which your entry was tested
|
|
Use tab indented lines if needed
|
|
---remark---
|
|
Place remarks about this entry in this section. It would be helpful if
|
|
you were to indent your remarks with 4 spaces, though it is not a
|
|
requirement. Also, if possible, try to avoid going beyond the 79th
|
|
column. Blank lines are permitted.
|
|
---author---
|
|
name: your name
|
|
org: School/Company/Organization
|
|
addr: postal address
|
|
use tab indented lines to continue
|
|
don't forget to include the country
|
|
email: email address from a well known site or registered domain.
|
|
If you give several forms, list them on separate tab indented lines.
|
|
url: http://your/home/page.html or say none if you don't have one
|
|
anon: y or n (y => remain anonymous, n => OK to publish this info)
|
|
---info---
|
|
If your program needs an info file, place a uuencoded copy of it in
|
|
this section. In the case of multiple info files, use multiple info
|
|
sections. If your entry does not need a info file, skip this section.
|
|
---build---
|
|
Place a uuencoded copy of the command(s) used to compile/build your program
|
|
in this section. It must uudecode into a file named 'build'. The resulting
|
|
file must be 521 bytes or less. |
|
|
---program---
|
|
Place a uuencoded copy of your program in this section. It must uudecode
|
|
into a file named is 'prog.c'. The resulting file must follow rule #2.
|
|
---end---
|
|
|
|
Regarding the above format:
|
|
|
|
* The title must match the expression:
|
|
|
|
^[a-zA-Z0-9_=][a-zA-Z0-9_=+-]*$
|
|
|
|
and must be 1 to 31 characters in length.
|
|
|
|
It is suggested, but not required, that the title should
|
|
incorporate the author(s) username(s).
|
|
|
|
* The date in the ---entry--- section should be given with respect
|
|
to UTC. The format of the date should be as returned by asctime()
|
|
using the C locale. (see guidelines for more info)
|
|
|
|
* You may correct/revise a previously submitted entry by sending
|
|
it to the contest email address. Be sure to set 'fix' in the
|
|
---entry--- section to 'y'. The corrected entry must use the same
|
|
title and entry number as submission that is being corrected. Be
|
|
sure that you note the re-submission in the ---remark--- as well.
|
|
|
|
* With the exception of the header, all text outside of the above
|
|
format may be ignored by the judges. If you need to tell the judges
|
|
something, put it in the ---remark--- section, or send a separate
|
|
email to the judges.
|
|
|
|
* Information from the ---author--- section will be published unless
|
|
'y' was given to the respective author's 'anon' line.
|
|
|
|
* To credit multiple authors, include an ---author--- section for
|
|
each author. Each should start with ---author--- line, and
|
|
should be found between the ---entry--- and ---build--- sections.
|
|
|
|
* The home page URL in the ---author--- section must be fully
|
|
qualified or must be the word `none'.
|
|
|
|
* The entry's remarks should include:
|
|
- note if this entry is a re-submission of a previous entry.
|
|
- what this program does
|
|
- how to run the program (sample args or input)
|
|
- special compile or execution instructions, if any
|
|
- special filename requirements (see rule 4 and 5)
|
|
- information about any ---info--- files
|
|
- why you think the program is obfuscated
|
|
- any other remarks (humorous or otherwise)
|
|
|
|
* Do not rot13 your entry's remarks. You may suggest that certain
|
|
portions of your remarks be rot13ed if your entry wins an award.
|
|
|
|
* Info files should be used only to supplement your entry. They
|
|
should not be required to exist.
|
|
|
|
* If your entry does not need an info file, skip the ---info---
|
|
section. If your entry needs multiple info files, use multiple
|
|
---info--- sections, one per info file. You should describe
|
|
each info file in the ---remark--- section.
|
|
|
|
* Your sections must in the same order as in the above template.
|
|
|
|
|
* The size limits of the program source apply to the decoded version |
|
|
of the ---program--- section. |
|
|
|
|
4) If your entry is selected as a winner, it will be modified as follows:
|
|
|
|
'build' is incorporated into a makefile, and 'build' is removed
|
|
'prog.c' is renamed to your entry's title, followed by an optional
|
|
digit, followed by '.c'
|
|
your entry is compiled into a file with the name of your entry's
|
|
title, possibly followed by a digit
|
|
|
|
If your entry requires that a build file exist, state so in your
|
|
entry's remark section. The makefile will be arranged to execute a
|
|
build shell script containing the 'build' information. The name of
|
|
this build shell script will be your entry's title, possibly followed
|
|
by a digit, followed by '.sh'.
|
|
|
|
If needed, your entry's remarks should indicate how your entry must
|
|
be changed in order to deal with the new filenames.
|
|
|
|
5) The build file, the source and the resulting executable should be
|
|
treated as read-only files. If your entry needs to modify these files,
|
|
it should make and modify a copy of the appropriate file. If this
|
|
occurs, state so in your entry's remarks.
|
|
|
|
6) The uudecoded ---program--- section must be able to be compiled
|
|
cleanly by an ANSI C compiler, or if there are any compile errors,
|
|
they must be documented in the ---remark--- section.
|
|
|
|
7) The program must be of original work. All submitted programs are |
|
|
are thereby put in the public domain. All explicitly copyrighted |
|
|
programs will be rejected. |
|
|
|
|
8) Entries must be received prior to 01-Dec-2001 23:59:59 UTC (UTC is |
|
|
essentially equivalent to Greenwich Mean Time). Email your entries to:
|
|
|
|
entry@ioccc.org
|
|
|
|
|
You must include the words ``ioccc entry'' in the subject |
|
|
of your email when sending in your entry! Failure to do so may |
|
|
result in the loss of your entry! !
|
|
|
|
If possible, we request that you hold off on emailing your entries
|
|
until 01-Oct-2001 00:00 UTC. Early entries will be accepted, however. |
|
|
We will attempt to email a confirmation to the sender of any entry
|
|
received after 01-Oct-2001 00:00 UTC and before the close |
|
|
of the contest.
|
|
|
|
9) Each person may submit up to 8 entries per contest year. Each entry
|
|
must be sent in a separate email.
|
|
|
|
10) Entries requiring human interaction to be built are not allowed.
|
|
|
|
11) Programs that require special privileges (setuid, setgid, super-user,
|
|
special owner or group) are not allowed.
|
|
|
|
12) Legal abuse of the rules is somewhat encouraged. An entry that, in
|
|
the opinion of the judges, violates the rules will be disqualified.
|
|
Entries that attempt to abuse the rules must try to justify why
|
|
their rule abuse is legal in the ---remark--- section.
|
|
|
|
|
13) Your source may not contain unescaped octets with the high bit set. |
|
|
I.e., your source may not contain octet values between 128 and 255. |
|
|
|
|
|
14) Any program that fails to compile because of lines with trailing |
|
|
control-M's (\r or \015) will be rejected. |
|
|
|
|
|
|
FOR MORE INFORMATION:
|
|
|
|
The judging will be done by Leonid A. Broukhis, Simon Cooper, Landon |
|
|
Curt Noll and Peter Seebach. Please send questions or comments
|
|
about the contest, to:
|
|
|
|
questions@ioccc.org (not the address for submitting entries)
|
|
|
|
You must include the words ``ioccc question'' in the subject of your |
|
|
email when sending email to the judges. |
|
|
|
|
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. To obtain them, visit the IOCCC web page:
|
|
|
|
http://www.ioccc.org
|
|
|
|
It has rules, guidelines and winners of previous contests (1984 to date).
|
|
|
|
|
NOTE: A copy of the mkentry program may be found at: |
|
|
|
|
|
http://www.ioccc.org/official/mkentry.c |
|