/
rules
234 lines (180 loc) · 10.1 KB
/
rules
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
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 message 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 letter.
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 message 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 |