v15i106: International Obfuscated C Code Contest, Part02/07
Rich Salz
rsalz at uunet.uu.net
Wed Aug 3 06:37:35 AEST 1988
Submitted-by: Landon Curt Noll <chongo at uts.amdahl.com>
Posting-number: Volume 15, Issue 106
Archive-name: ioccc/part02
# This is a shell archive. Remove anything before this line, then
# unpack it by saving it in a file and typing "sh file". (Files
# unpacked will be owned by you and have default permissions.)
#
# This archive contains:
#
# ./README ./Makefile
mkdir 1984 1985 1986 1987 1988
echo x - ./README
sed -e 's/^X//' > "./README" << '//E*O*F ./README//'
X The International Obfuscated C Code Contest
X
X
XObfuscate: tr.v. -cated, -cating, -cates. 1. a. To render obscure.
X b. To darken. 2. To confuse: His emotions obfuscated his
X judgement. [LLat. obfuscare, to darken : ob(intensive) +
X Lat. fuscare, to darken < fuscus, dark.] -obfuscation n.
X obfuscatory adj.
X
X
X
XHow it was started:
X
XThe original inspiration of the International Obfuscated C Code
XContest came from the Bourne Shell source and the finger command as
Xdistributed in 4.2BSD. If this is what could result from what some
Xpeople claim is reasonable programming practice, then to what depths
Xmight quality sink if people really tried to write poor code?
X
XI put that question to the USENET news groups net.lang.c and
Xnet.unix-wizards in the form of a contest. I selected a form similar
Xto the contest (Bulwer-Lytton) that asks people to create the worst
Xopening line to a novel. (that contest in turn was inspired by disgust
Xover a novel that opened with the line "It was a dark and stormy
Xnight.") The rules were simple: write, in 512 bytes or less, the worst
Xcomplete C program.
X
XThru the contest I have tried to instill two things in people. First
Xis a disgust for poor coding style. Second was the notion of just how
Xmuch utility is lost when a program is written in an unstructured
Xfashion. Contest winners help do this by what I call satirical
Xprogramming. To see why, observe one of the definitions of satire:
X
X Keen or energetic activity of the mind used for the purpose
X of exposing and discrediting vice or folly.
X
XThe authors of the winning entries placed a great deal of thought into
Xtheir programs. These programs in turn exposed and discredited what I
Xconsidered to be the programmer's equivalent of "vice or folly".
X
XThere were two unexpected benefits that came from the contest winners.
XFirst was an educational value to the programs. To understand these C
Xprograms is to understand subtle points of the C programming language.
XThe second benefit is the entertainment value, which should become
Xevident as you read further!
X
X
X
XSuggestions on how to understand the winning entries:
X
XYou are strongly urged to try to determine what each program will
Xproduce by visual inspection. Often this is an impossible task, but
Xthe difficulty that you encounter should give you more appreciation
Xfor the entry.
X
XIf you have the energy to type in the text, or if you have access to
Xa machine readable version of these programs, you should next consider
Xsome preprocessing such as:
X
X sed -e '/^#.*include/d' program.c | cc -E
X
XThis strips away comments and expands the program's macros without
Xhaving things such as <stdio.h> macros clutter up the output. If the
Xentry requires or suggests the use of compile line options (such as
X-Dindex=strchr) they should be added after the '-E' flag.
X
XThe next stage towards understanding is to use a C beautifier or C
Xindenting program on the source. Be warned that a number of these
Xentries are so twisted that such tools may abort or become very
Xconfused. You may need to help out by doing some initial formatting
Xwith an editor. You might also try renaming variables and labels to
Xgive more meaningful names.
X
XNow try linting the program. You may be surprised at how little lint
Xcomplains about these programs. Pay careful attention to messages
Xabout unused variables, wrong types, pointer conversions, etc. But be
Xcareful, some lints produce incorrect error messages or even abort!
XYour lint may detect syntax errors in the source. See the next
Xparagraph for suggestions on how to deal with this.
X
XWhen you get to the stage where you are ready to compile the program
Xexamine the compilation comments above each entry. A simple define or
Xedit may be required due to differing semantics between operating
Xsystems. If you are able to successfully compile the program,
Xexperiment with it by giving it different arguments or input.
XYou may also use the makefile provided to compile the program.
XKeep in mind that C compilers often have bugs, or features which
Xresult the program failing to compile. You may have to do some
Xsyntax changing as we did to get old programs to compile on strict
XANSI C compilers.
X
XLast, read the judges' comments/spoilers on the program. Hints
Xfor `foo.c' are given in `foo.hint'. Often they will contain suggested
Xarguments or recommended data to use.
X
XIf you do gain some understanding of how a program works, go back to
Xthe source and reexamine it using some of the techniques outlined above.
XSee if you can convince yourself of why the program does what it does.
X
X
X
XAbout the judges:
X
XAs of 1988 the contest had two judges: Landon Curt Noll (contest
Xfounder) and Larry Bassel (judge since 1985). Landon works as a
Xsystems programmer for Amdahl Corporation and Larry works as an systems
Xprogrammer for Sun Microsystems. In real life, both judges strongly
Xdislike obfuscated code.
X
X
X
XRegarding the source archive:
X
XEach sub-directory contains all the entries for a single year. Often
Xthe file names match one of the last names of the author. Judges'
Xhints are given in files of the form ``*.hint''. The makefiles
Xgiven are set up for a System V based machine. You may need to
Xtweak this makefile to get everything to compile correctly.
XRead the hint files for suggestions. The rules for a given
Xyear are given in the file named ``rules''. The last year
Xin an archive contains a copy of the rules for the upcoming
Xcontest.
X
X
X
XRegarding the distribution of sources:
X
XAll contest results are in the public domain. We do ask that you observe
Xthe following request:
X
XYou may shar these files with others, but please do not prevent them of
Xdoing the same. If some of these files and/or contest entries are
Xpublished in printed form, or if you use them in a business or classroom
Xsetting, please let us know. We ask that you drop a line to the
X'judges' Email box. As of 1988, it is:
X
X judges at uts.amdahl.com -or- amdahl!judges
X
X [this could change from year to year, so consult the current rules]
X
X
X
XSome final things to remember:
X
XWhile the idea for the contests has remained the same through the
Xyears, the contest rules and guidelines vary. What was novel one year
Xmay be considered common the next. The categories for awards differ
Xbecause they are determined after the judges examine all of the
Xentries.
X
XThe judges' hints assume that the program resides in a file with the
Xsame username as the author. Where there is more than one author, the
Xfirst named author is used.
X
XSome C compilers are unable to compile some of these programs. The
Xjudges tried to select programs that were widely portable and
Xcompilable, but did not always succeed. As of 1988, only ``K&R''
Xcompilers were used. Due to the timing of the ANSI C standard, ANSI C
Xissues were not addressed until 1988 at all (and in 1988 there were
Xjust a few comments in the hint files). Often only a simple edit is
Xneeded to get a new C compiler to accept the source file.
X
XThe contest rules are posted in early March. The winners are announced
Xat the Usenet BOF of the Summer Usenix conference. Later they
Xare posted to the net.
X
XThe rules are posted to the following Usenet news groups:
X
X comp.unix.wizards
X comp.lang.c
X
XAs of 1988, the winners were posted to the following Usenet news groups:
X
X comp.sources.unix
X comp.lang.c
X alt.sources
X
XPeople are strongly encouraged to wait until the new contest rules
Xhave been posted before sending entries. The rules, and sometimes
Xthe contest Email address itself, change from time to time.
XThe typical start date for a contest is March 15. The typical
Xend date for a contest is May 20.
X
XLast, PLEASE don't code in the style of these programs (unless you
Xare submitting a contest entry of course!) It is hoped that you will
Xgain an understanding that bad style destroys an otherwise correct
Xprogram. Real programmers don't write obfuscated programs that other
Xpeople have to use!
X
XHappy pondering,
X
X Landon Curt Noll (chongo at uts.amdahl.com)
X Larry Bassel (lab at sun.com)
//E*O*F ./README//
echo x - ./Makefile
sed -e 's/^X//' > "./Makefile" << '//E*O*F ./Makefile//'
X# %W% %G% %U%
X#
X
XSHELL=/bin/sh
X
Xall:
X @-for i in [12][0-9][0-9]?; do \
X if [ -f $$i/[Mm]akefile ]; then \
X echo "cd $$i; make all"; \
X (cd $$i; make all); \
X fi; \
X done
X
Xclean:
X @-for i in [12][0-9][0-9]?; do \
X if [ -f $$i/[Mm]akefile ]; then \
X echo "cd $$i; make clean"; \
X (cd $$i; make clean); \
X fi; \
X done
Xclobber:
X @-for i in [12][0-9][0-9]?; do \
X if [ -f $$i/[Mm]akefile ]; then \
X echo "cd $$i; make clobber"; \
X (cd $$i; make clobber); \
X fi; \
X done
Xinstall:
X @-for i in [12][0-9][0-9]?; do \
X if [ -f $$i/[Mm]akefile ]; then \
X echo "cd $$i; make install"; \
X (cd $$i; make install); \
X fi; \
X done
//E*O*F ./Makefile//
echo Possible errors detected by \'wc\' [hopefully none]:
temp=/tmp/shar$$
trap "rm -f $temp; exit" 0 1 2 3 15
cat > $temp <<\!!!
193 1346 8065 README
34 118 655 Makefile
227 1464 8720 total
!!!
wc ./README ./Makefile | sed 's=[^ ]*/==' | diff -b $temp -
exit 0
--
Please send comp.sources.unix-related mail to rsalz at uunet.uu.net.
More information about the Comp.lang.c
mailing list