home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / unix / volume14 / ioccc / part01 next >
Encoding:
Internet Message Format  |  1988-03-14  |  10.1 KB

  1. Subject:  v14i001:  International Obfuscated C Code Contest, Part01/05
  2. Newsgroups: comp.sources.unix
  3. Sender: sources
  4. Approved: rsalz@uunet.UU.NET
  5.  
  6. Submitted-by: Landon Curt Noll <chongo@uts.amdahl.com>
  7. Posting-number: Volume 14, Issue 1
  8. Archive-name: ioccc/part01
  9.  
  10. [  This stuff is nicely packaged by year, so I left it.  I think in the
  11.    future I'll repack things to get closer to the 60K size.  --r$  ]
  12.  
  13.  
  14. # This is a shell archive.  Remove anything before this line, then
  15. # unpack it by saving it in a file and typing "sh file".  (Files
  16. # unpacked will be owned by you and have default permissions.)
  17. #
  18. # This archive contains:
  19. # ./README ./Makefile
  20.  
  21. echo x - ./README
  22. sed -e 's/^X//' > "./README" << '//E*O*F ./README//'
  23. X               The International Obfuscated C Code Contest
  24. XObfuscate:  tr.v.  -cated, -cating, -cates.  1. a.  To render obscure.
  25. X        b.  To darken.  2. To confuse:  His emotions obfuscated his
  26. X        judgement.  [LLat. obfuscare, to darken : ob(intensive) +
  27. X        Lat. fuscare, to darken < fuscus, dark.] -obfuscation n.
  28. X        obfuscatory adj.
  29. X
  30. X
  31. X
  32. XHow it was started:
  33. X
  34. XThe original inspiration of the International Obfuscated C Code
  35. XContest came from the Bourne Shell source and the finger command as
  36. Xdistributed in 4.2BSD.  If this is what could result from what some
  37. Xpeople claim is reasonable programming practice, then to what depths
  38. Xmight quality sink if people really tried to write poor code?
  39. X
  40. XI put that question to the USENET news groups net.lang.c and
  41. Xnet.unix-wizards in the form of a contest.  I selected a form similar
  42. Xto the contest that asks people to create the worst opening line to a
  43. Xnovel.  (that contest in turn was inspired by disgust over a novel
  44. Xthat opened with the line "It was a dark and stormy night.")  The
  45. Xrules were simple: write, in 512 bytes or less, the worst complete
  46. XC program.
  47. X
  48. XThru the contest I have tried to instill two things in people.  First
  49. Xis a disgust for poor coding style.  Second was the notion of just how
  50. Xmuch utility is lost when a program is written in an unstructured
  51. Xfashion.  Contest winners help do this by what I call satirical
  52. Xprogramming.  To see why, observe one of the definitions of satire:
  53. X
  54. X    Keen or energetic activity of the mind used for the purpose 
  55. X    of exposing and discrediting vice or folly.
  56. X
  57. XThe authors of the winning entries placed a great deal of thought into
  58. Xtheir programs.  These programs in turn exposed and discredited what I
  59. Xconsidered to be the programmer's equivalent of "vice or folly".
  60. X
  61. XThere were two unexpected benefits that came from the contest winners.
  62. XFirst was an educational value to the programs.  To understand these C
  63. Xprograms is to understand subtle points of the C programming language.
  64. XThe second benefit is the entertainment value, which should become
  65. Xevident as you read further!
  66. X
  67. X
  68. X
  69. XSuggestions on how to understand the winning entries:
  70. X
  71. XYou are strongly urged to try to determine what each program will
  72. Xproduce by visual inspection.  Often this is an impossible task, but
  73. Xthe difficulty that you encounter should give you more appreciation
  74. Xfor the entry.
  75. X
  76. XIf you have the energy to type in the text, or if you have access to
  77. Xa machine readable version of these programs, you should next consider
  78. Xsome preprocessing such as:
  79. X
  80. X    sed -e '/^#.*include/d' program.c | cc -E
  81. X
  82. XThis strips away comments and expands the program's macros without
  83. Xhaving things such as <stdio.h> macros clutter up the output.  If the
  84. Xentry requires or suggests the use of compile line options (such as
  85. X-Dindex=strchr) they should be added after the '-E' flag.
  86. X
  87. XThe next stage towards understanding is to use a C beautifier or C
  88. Xindenting program on the source.  Be warned that a number of these
  89. Xentries are so twisted that such tools may abort or become very
  90. Xconfused.  You may need to help out by doing some initial formatting
  91. Xwith an editor.  You might also try remaining variables and labels to
  92. Xgive more meaningful names.
  93. X
  94. XNow try linting the program.  You may be surprised at how little lint
  95. Xcomplains about these programs.  Pay careful attention to messages
  96. Xabout unused variables, wrong types, pointer conversions, etc.  But be
  97. Xcareful, some lints produce incorrect error messages or even abort!
  98. XYour lint may detect syntax errors in the source.  See the next
  99. Xparagraph for suggestions on how to deal with this.
  100. X
  101. XWhen you get to the stage where you are ready to compile the program
  102. Xexamine the compilation comments above each entry.  A simple define or
  103. Xedit may be required due to differing semantics between operating
  104. Xsystems.  If you are able to successfully compile the program,
  105. Xexperiment with it by giving it different arguments or input.
  106. XYou may also use the makefile provided to compile the program.
  107. XKeep in mind that C compilers often have bugs, or features which
  108. Xresult the program failing to compile.  You may have to do some
  109. Xsyntax changing as we did to get old programs to compile on strict
  110. XANSI C compilers.
  111. X
  112. XLast, read the judges' comments/spoilers on the program.  Hints
  113. Xfor `foo.c' are given in `foo.hint'.  Often they will contain suggested
  114. Xarguments or recommended data to use.
  115. X
  116. XIf you do gain some understanding of how a program works, go back to
  117. Xthe source and reexamine it using some of the techniques outlined above.
  118. XSee if you can convince yourself of why the program does what it does.
  119. X
  120. X
  121. X
  122. XAbout the judges:
  123. X
  124. XAs of 1988 the contest had two judges: Landon Curt Noll (contest
  125. Xfounder) and Larry Bassel (judge since 1985).  Landon works as a
  126. Xsystems programmer for Amdahl Corporation and Larry works as an
  127. Xoperating systems specialist for Counterpoint.  In real life,
  128. Xboth judges strongly dislike obfuscated code.
  129. X
  130. X
  131. X
  132. XRegarding the source archive:
  133. X
  134. XEach sub-directory contains all the entries for a single year.  Often
  135. Xthe file names match one of the last names of the author.  Judges
  136. Xhints are given in files of the form ``*.hint''.  The make files
  137. Xgiven are setup for a System V based machine.  You may need to
  138. Xtweak this makefile to get everything to compile correctly.
  139. XRead the hint files for suggestions.  The rules for a given
  140. Xyear are given in the file named ``rules''.  The last year
  141. Xin an archive contains a copy of the rules for the upcoming
  142. Xcontest.
  143. X
  144. XThe rules are 1984 were never saved.  Does anyone have a copy?
  145. XIf so, please send it to chongo at: chongo@amdahl.amdahl.com.
  146. X
  147. X
  148. X
  149. XRegarding the distribution of sources:
  150. X
  151. XAll contest results are in the public domain.  We do ask that you observe 
  152. Xthe following request:
  153. X
  154. XYou may shar these files with others, but please do not prevent them of
  155. Xdoing the same.  If some of these files and/or contest entries are
  156. Xpublished in printed form, or if you use them in a business or classroom
  157. Xsetting, please let us know.  We ask that you drop a line to the
  158. X'judges' Email box.  As of 1988, it is:
  159. X
  160. X    judges@uts.amdahl.com    -or-    amdahl!judges
  161. X
  162. X    [this could change from year to year, so consult the current rules]
  163. X
  164. X
  165. X
  166. XSome final things to remember:
  167. X
  168. XWhile the idea for the contests has remained the same through the
  169. Xyears, the contest rules and guidelines vary.  What was novel one year
  170. Xmay be considered common the next.  The categories for awards differ
  171. Xbecause they are determined after the judges examine all of the
  172. Xentries.
  173. X
  174. XThe judges' hints assume that the program resides in a file with the
  175. Xsame username as the author.  Where there is more than one author, the
  176. Xfirst named author is used.
  177. X
  178. XSome C compilers are unable to compile some of these programs.  The
  179. Xjudges tried to select programs that were widely portable and
  180. Xcompilable, but did not always succeed.  As of 1988, only ``K&R''
  181. Xcompilers were used.  Due to the timing of the ANSI C standard, ANSI C
  182. Xissues were not addressed.  Often only a simple edit is needed to get
  183. Xa new C compiler to accept the source file.
  184. X
  185. XThe typical contest starts with the posting of the new rules around
  186. XMid march, and ends near the end of May.  The winners are announced
  187. Xat the Usenet BOF of the Summer Usenix conference.  Later they
  188. Xare posted to the net.  Newsgroup tend to change over time, but as of
  189. X1987, the rules and winners were posted to the following Usenet
  190. Xnews groups:
  191. X
  192. X    comp.sources.unix        comp.unix.wizards
  193. X    comp.lang.c            misc.misc
  194. X    alt.sources            talk.bizarre
  195. X
  196. XPeople are strongly encouraged to wait until the new contest rules
  197. Xhave been posted before sending entries.  The rules, and sometimes
  198. Xthe contest Email address itself, change from time to time.
  199. XThe typical start date for a contest is March 15.  The typical
  200. Xend date for a contest is May 25.  The current practice is to send 
  201. Xthe rules for next year's contest out with this year's winners.  
  202. XHowever the official rules are not posted until March 15 so
  203. Xthe rules posted early are subject to change until the official
  204. Xposting.
  205. X
  206. XLast, PLEASE don't code in the style of these program.  (unless you
  207. Xare submitting a contest entry of course!)  It is hoped that you will
  208. Xgain an understand that bad style distroys an otherwise correct
  209. Xprogram.  Real programmers don't write obfuscated programs that other
  210. Xpeople have to use!
  211. X
  212. XHappy pondering,
  213. X
  214. X    Landon Curt Noll   (chongo@uts.amdahl.com)
  215. //E*O*F ./README//
  216.  
  217. echo x - ./Makefile
  218. sed -e 's/^X//' > "./Makefile" << '//E*O*F ./Makefile//'
  219. X# %W% %G% %U%
  220. X#
  221. X
  222. XSHELL=/bin/sh
  223. X
  224. Xall:
  225. X    @-for i in [12][0-9][0-9]?; do \
  226. X        if [ -f $$i/[Mm]akefile ]; then \
  227. X        echo "cd $$i; make all"; \
  228. X        (cd $$i; make all); \
  229. X        fi; \
  230. X    done
  231. X
  232. Xclean:
  233. X    @-for i in [12][0-9][0-9]?; do \
  234. X        if [ -f $$i/[Mm]akefile ]; then \
  235. X        echo "cd $$i; make clean"; \
  236. X        (cd $$i; make clean); \
  237. X        fi; \
  238. X    done
  239. Xclobber:
  240. X    @-for i in [12][0-9][0-9]?; do \
  241. X        if [ -f $$i/[Mm]akefile ]; then \
  242. X        echo "cd $$i; make clobber"; \
  243. X        (cd $$i; make clobber); \
  244. X        fi; \
  245. X    done
  246. Xinstall:
  247. X    @-for i in [12][0-9][0-9]?; do \
  248. X        if [ -f $$i/[Mm]akefile ]; then \
  249. X        echo "cd $$i; make install"; \
  250. X        (cd $$i; make install); \
  251. X        fi; \
  252. X    done
  253. //E*O*F ./Makefile//
  254.  
  255. echo Possible errors detected by \'wc\' [hopefully none]:
  256. temp=/tmp/shar$$
  257. trap "rm -f $temp; exit" 0 1 2 3 15
  258. cat > $temp <<\!!!
  259.     194   1399   8358 README
  260.      34    118    655 Makefile
  261.     228   1517   9013 total
  262. !!!
  263. wc  ./README ./Makefile | sed 's=[^ ]*/==' | diff -b $temp -
  264. exit 0
  265.  
  266.