This is a HUGE commit:
417 files changed, 874 insertions(+), 874 deletions(-)
As the IOCCC website now is https enabled I have updated the
'http://www.ioccc' to 'https://www.ioccc'.
There was also a typo in Makefiles where it said 'for VERY WELCOME' when
it should be 'are VERY WELCOME'.
Finally slashdot.org is also https enabled so references to
'http://slashdot' were changed to 'https://slashdot'.
This was done by my sgit tool (see https://github.com/xexyl/sgit)
like:
sgit -e 's,http://www.ioccc,https://www.ioccc,g' -e 's/for VERY WELCOME/are VERY WELCOME/g' -e .
but because I didn't have a list of files that should be modified I had
to be careful which files to commit as I had files that were changed but
not ready to be committed. Since I did it in steps, finding typos as I
went along, I actually ran sgit three times but to simplify the above
(and to show that it's possible to do more than one sed command) I made
it all as one. Since I did not have a list of files ahead of time I had
to determine what files to commit, first going through them like:
for j in $(for i in $(git status|grep modified|cut -d: -f2); do \
git grep 'https://www.ioccc' "$i"; done|cut -d: -f1|sort|uniq); \
do git diff "$j"; done|less -r
(I had to pipe through less because of a strange problem with the git
diff which appears to be because of a terminal problem maybe due to the
command above but it was all I could come up with in a very tired head.)
The above and
git status | grep modified:
showed that some C files had been modified which obviously should not be
done so I had to do:
git co '*c'
to undo those changes.
Finally to commit the correct files I did:
for i in $(git status|grep modified|cut -d: -f2); do \
git grep -E 'https://www.ioccc|https://slashdot|are VERY WELCOME' "$i"; \
done |cut -d: -f1|sort|uniq|xargs git commit -v
or so (with any formatting issues or typos here due to typos in the log
due to the terminal (in)sanity issue described).
153 lines
6.0 KiB
Plaintext
153 lines
6.0 KiB
Plaintext
18th International Obfuscated C Code Contest Rules
|
|
|
|
Copyright (C) 2005 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.
|
|
|
|
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 18th IOCCC contest window is:
|
|
|
|
| 21-Mar-2005 00:00 UTC to 22-May-2005 23:59:59 UTC
|
|
|
|
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 size of your program source must be <= 4096 bytes in length.
|
|
The number of characters excluding whitespace (tab, space,
|
|
newline, formfeed, return), and excluding any ; { or } immediately
|
|
followed by whitespace or end of file, must be <= 2048.
|
|
|
|
3) Submissions should be performed using the instructions outlined at,
|
|
|
|
| https://www.ioccc.org/2005/submit
|
|
|
|
4) If your entry is selected as a winner, it will be modified as follows:
|
|
|
|
Your 'build' instructions will be incorporated into a
|
|
makefile. If your build instructions *is* a makefile then
|
|
it should be portable and usable from within a master
|
|
makefile.
|
|
|
|
Your program source will be renamed using an identifier of
|
|
our choice (usually your family name or anonymous) followed
|
|
by an optional digit, followed by '.c'
|
|
|
|
Your entry will be compiled into a file with the above name
|
|
minus the '.c'.
|
|
|
|
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) Your program source 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 "remarks" section of your submission.
|
|
|
|
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 22-May-2005 23:59:59 UTC.
|
|
|
|
An email a confirmation of submission will be sent to the sender
|
|
before the close of the contest.
|
|
|
|
9) Each person may submit up to 8 entries per contest year. Each entry
|
|
must be submitted separately.
|
|
|
|
10) Entries requiring human interaction to be built are not permitted.
|
|
|
|
11) Programs that require special privileges (setuid, setgid, super-user,
|
|
| special owner or group) are highly discouraged.
|
|
|
|
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 submitted "remarks".
|
|
|
|
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.
|
|
|
|
15) When you submit your entry you must have a valid email address
|
|
that can both send and receive email. The online submission
|
|
method is a two phase process that requires the use of an
|
|
approval code. This code will be emailed to you as part of
|
|
phase 1.
|
|
|
|
Entries submitted without a working or valid email address will
|
|
be disqualified.
|
|
|
|
The judges are not responsible for delays in email, please plan
|
|
enough time for one automated exchange of email as part of your
|
|
submission.
|
|
|
|
16) You are STRONGLY encouraged to submit an original entry.
|
|
Submissions that are similar to previous entries are discouraged.
|
|
|
|
| 17) The total size of your submission: the sum of the size of the program,
|
|
| hints, comments, build and info files MUST be less than one megabyte
|
|
| in size.
|
|
|
|
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:
|
|
|
|
| q.2005@ioccc.org (for questions only!)
|
|
|
|
| You must include the words ``ioccc 2005 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:
|
|
|
|
https://www.ioccc.org
|
|
|
|
It has rules, guidelines and winners of previous contests (1984 to date).
|
|
|
|
Details of how to submit your entry are located at,
|
|
|
|
| https://www.ioccc.org/2005/submit
|
|
|
|
Leonid A. Broukhis
|
|
Simon Cooper
|
|
chongo (Landon Curt Noll) /\cc/\
|
|
Peter Seebach
|
|
|