home *** CD-ROM | disk | FTP | other *** search
/ Source Code 1992 March / Source_Code_CD-ROM_Walnut_Creek_March_1992.iso / usenet / altsrcs / 3 / 3173 < prev    next >
Internet Message Format  |  1991-04-07  |  11KB

  1. From: chongo@hoptoad.uucp (Landon C. Noll)
  2. Newsgroups: comp.lang.c,comp.sources.d,comp.unix.wizards,alt.sources,misc.misc
  3. Subject: International Obfuscated C Code Contest Archive + Rules
  4. Message-ID: <16875@hoptoad.uucp>
  5. Date: 6 Apr 91 07:49:08 GMT
  6.  
  7. For folks who requested another copy of the 1991 contest rules; see the
  8. bottom of this article.  The contest ends 16-May-91 0:00 UTC.
  9.  
  10. The International Obfuscated C Code Contest Archive (previous winners
  11. from 1984 to 1990) are now available for ftp access from uunet:
  12.  
  13.     /pub/ioccc/shar.1984.01
  14.     /pub/ioccc/shar.1985.01
  15.     /pub/ioccc/shar.1986.01
  16.     /pub/ioccc/shar.1987.01
  17.     /pub/ioccc/shar.1988.01
  18.     /pub/ioccc/shar.1989.01
  19.     /pub/ioccc/shar.1989.02
  20.     /pub/ioccc/shar.1990.01
  21.     /pub/ioccc/shar.1990.02
  22.     /pub/ioccc/shar.README
  23.  
  24. If you have a collection of contest winners that is older than 09/23/1990,
  25. you may want to fetch this collection.  There have been some minor updates,
  26. typos fixes and README changes made to the archive.
  27.  
  28. chongo <For a good prime, call:  391581 * 2^216193 - 1> /\cc/\
  29.  
  30. =-=-
  31.  
  32. 8th International Obfuscated C Code Contest Rules
  33.  
  34.     Obfuscate:  tr.v.  -cated, -cating, -cates.  1. a.  To render obscure.
  35.         b.  To darken.  2. To confuse:  his emotions obfuscated his
  36.         judgment.  [LLat. obfuscare, to darken : ob(intensive) +
  37.         Lat. fuscare, to darken < fuscus, dark.] -obfuscation n.
  38.         obfuscatory adj.
  39.  
  40.  
  41. GOALS OF THE CONTEST:
  42.  
  43.     * To write the most Obscure/Obfuscated C program under the rules below.
  44.     * To show what should NOT be done in C programs.
  45.     * To provide a safe forum for poor C code.  :-)
  46.  
  47.  
  48. DEDICATION:
  49.  
  50.     The 1991 IOCCC is dedicated to the ANSI C pre-processor.
  51.  
  52.  
  53. RULES:
  54.  
  55.     To help us handle the vast volume of entries, we ask that you follow the
  56.     rules below.  SORRY FOR THE LENGTH, BUT WE NEED ALL THE HELP WE CAN GET!
  57.  
  58.     1) Your source MUST be 1536 bytes or less.   It must be a complete program.
  59.  
  60.     2) To help us process your entries, we ask that you submit entries
  61.        in the following format.  Please be sure to include ALL --- lines,
  62.        otherwise our extraction program may skip your entry!
  63.  
  64. ---header items---
  65. name:        Your name, of course!
  66.  
  67. org:        School/Company/Organization
  68.  
  69. email address:    Email address from a well known site, or in a registered domain
  70.  
  71. postal address:    Postal address
  72.         include your country as well
  73.  
  74. environment:    Indicate the Hardware
  75.         and OS under which your program was tested
  76.  
  77. entry:        5    <i.e., entry number from 0 to 7 inclusive>
  78.  
  79. remark:        Remarks about the program.  See rule #3 below for details.
  80. ---how to ANSI compile---
  81. Give the command(s) needed to compile your program using an ANSI C
  82. compiler.  If your program should not be compiled under an ANSI C compiler,
  83. leave this section blank.  The command size must be 160 characters or less.
  84. ---how to common compile---
  85. Give the command(s) needed to compile your program using an K&R/traditional
  86. C compiler.  If your program should not be compiled under a K&R style C,
  87. leave this section blank.  The command size must be 160 characters or less.
  88. ---program---
  89. Not everyone has a program such as uuencode, and we don't want to blindly
  90. process a shar file, so we ask that you format your source as follows:
  91.  
  92. Add a leading X to EACH line, unless it is a split line.   (see below)
  93.  
  94. Some mailers don't like long lines.  To be safe, split lines longer than 80
  95.     characters.  To split a line, place an E at the point of a split and
  96.     place a C (instead of an X) at the beginning of the next line.
  97.  
  98. If the program does not end in a newline, end the last line with an E.
  99.  
  100. Leading X's, trailing E's followed by the two characters "\nC", and an E
  101.     at the last character of the last line are not considered to part of the
  102.     source and thus don't contribute toward the source character count.
  103.     Be careful with lines ending in "E\n", see the example below.
  104.  
  105. Newlines and tabs each count as 1 character.  Assume 8 character tab stops.
  106.  
  107. The newlines here were placed for reasons of readability.  In your entry,
  108.     every line in this section must begin with either an X or a C.
  109.  
  110. Example:
  111.  
  112. XThis is a single line containing 79 E
  113. Ccharacters including the E
  114. Cfinal newline.
  115. XThe next line contains only a single newline.
  116. X
  117. XThis line is terminated by a newline preceded by an EE
  118. C
  119. XThis last line is not terminated by a newline and ends in an EE
  120. ---end---
  121.  
  122.     3) Regarding the header items:
  123.  
  124.     * Any text outside of the above format will be kept confidential.
  125.  
  126.     * All header lines are required, but you may use 'anonymous'
  127.       for any header line other than 'remarks' or 'entry'.
  128.  
  129.     * Only the '---program---' section uses the 'X', 'C', 'E' notation.
  130.  
  131.     * In the 'remark' item, please include:
  132.         - what this program does
  133.         - why you think the program is obfuscated
  134.         - any other remarks (humorous or otherwise)
  135.         - By default, we will select your program source and/or binary
  136.           filename.  If your entry REQUIRES a specific source and/or
  137.           binary filename, please say so in the remark section.
  138.         - If this entry is a re-submission of a previous entry.
  139.  
  140.     4) Your entry should be written in common C (K&R + common extensions)
  141.        or ANSI C.  If your program will NOT compile under an ANSI C or
  142.        K&R C compiler, leave the particular 'how to' section blank.
  143.        If you leave a 'how to' section blank, include the '---' line.
  144.  
  145.        You do not have to fill in both 'how to' sections, though you must
  146.        fill in at least one 'how to' section.  If you leave a 'how to'
  147.        section blank, include the '---' line anyway.
  148.  
  149.     5) The program must be of original work.  All programs must be
  150.        in the public domain.  All copyrighted programs will be rejected.
  151.  
  152.     6) Entries must be received between 06-Mar-91 0:00 UTC and
  153.        16-May-91 0:00 UTC.  Email your entries the address found below.
  154.        (UTC is essentially equivalent to Greenwich Mean Time)
  155.  
  156.        We will attempt to Email a confirmation of receipt of contest
  157.        entries, however since Email is not reliable you may not receive it.
  158.        We regret that we can no longer accept entries via postal mail.
  159.  
  160.     7) Each person may submit up to 8 entries.  Only 1 entry per Email
  161.        letter.  If you submit multiple entries, be sure that each has a
  162.        unique entry number.
  163.  
  164.        We will discard all but the latest email in the case of multiple
  165.        entries with the same entry number.  Thus, if you wish to correct
  166.        a previously sent entry, re-send it with the same entry number.
  167.        Just to be sure email does not arrive out or sequence, note that 
  168.        fact in the 'remark' item.
  169.  
  170.     8) Entries requiring human interaction to be built are not allowed.  
  171.        (for example, don't use #include "/dev/tty")
  172.  
  173.     9) Compiling an entry must result a regular file which may be executed.
  174.        (for example, don't use -o /dev/tty)
  175.  
  176.  
  177. ANNOUNCEMENT OF WINNERS:
  178.  
  179.     * First announcement will likely be at the Summer 91 Usenix conference.
  180.  
  181.     * Winning entries will be posted in mid June 1991 to
  182.       comp.sources.unix as well as news groups where these rules
  183.       were posted.  (depending on the judges work load)
  184.  
  185.     * Winning entries will be deposited into the uunet archives.
  186.  
  187.     * An article containing the winning entries will be published
  188.       in a future issue of the "Micro/Systems Journal".
  189.  
  190.     * Winners receive international fame and flames!  :-)
  191.  
  192.  
  193. JUDGING:
  194.  
  195.     Awards will be given to the best entry in a number of categories.
  196.     The actual category list will vary depending on the types of entries
  197.     we receive.  As a guide, consider using the following:
  198.  
  199.     * The best small one line program
  200.     * The strangest source layout
  201.     * The most useful obfuscated program
  202.     * The most creatively obfuscated program
  203.     * Best obfuscated entry smaller than 256 bytes
  204.     * Best obfuscated entry smaller than 1024 bytes
  205.     * Best abuse of ANSI C
  206.     * Worse abuse of the rules (no abuse of entry format please!)
  207.     * <anything else so strange that it deserves an award>
  208.  
  209.  
  210. POINTS TO PONDER:
  211.  
  212.     People are encouraged to examine winners of the previous contests.
  213.     A copy of these entries has been posted to comp.sources.unix.
  214.     Contact the comp.sources.unix moderator, or some archive site (such
  215.     as uunet).  Keep in mind that rules change from year to year, so some
  216.     winning entries may not be valid entries this year.  What was unique
  217.     and novel one year might be 'old' the next year.
  218.  
  219.     We examine each entry on several levels of confusion.  For example
  220.     each entry is judged when we:
  221.  
  222.     * look at the original source
  223.     * If it is ANSI, convert tri-graphs to ASCII
  224.     * C pre-process the source ignoring '#include' '#define' lines
  225.     * C pre-process the source ignoring '#define' and '#include' lines
  226.     * run it through a C beautifier
  227.     * examine the algorithm
  228.     * lint it
  229.     * compile it
  230.     * execute it
  231.  
  232.     One line programs are best when they are short, obscure and concise.
  233.  
  234.     We tend to dislike programs that:
  235.  
  236.     * are very hardware specific
  237.     * are very OS or Un*x version specific
  238.          (index/strchr differences are ok, but socket/streams specific
  239.           code is likely not to be)
  240.     * dump core or have compiler warnings
  241.          (it is ok only if you warn us in the 'remark' header item)
  242.     * won't compile under both BSD or SYS V Un*x
  243.     * use an excessively long compile line to get around the size limit
  244.     * obfuscate by excessive use of ANSI tri-graphs
  245.     * are longer than they need to be
  246.     * are similar to previous winners
  247.     * are similar to previous losers  :-)
  248.  
  249.     Simply abusing #defines or -Dfoo=bar won't go as far as a program
  250.     that is more well rounded in confusion.
  251.  
  252.     Unless you are cramped for space, or unless you are entering the
  253.     'best one liner' category, we suggest that you format your program
  254.     in a more creative way than simply forming excessively long lines.
  255.  
  256.     We like programs that:
  257.  
  258.     * are as concise and small as they need to be
  259.     * do something at least quasi-interesting
  260.     * pass lint without complaint (not a requirement, but it is nice)
  261.     * are portable
  262.     * are unique or novel in their obfuscation style
  263.     * MAKE USE OF A NUMBER OF DIFFERENT TYPES OF OBFUSCATION
  264.     * make us laugh and/or throw up  :-)
  265.  
  266.     Some types of programs can't excel in some areas.  Of course, your
  267.     program doesn't have to excel in all areas, but doing well in several
  268.     areas really does help.  A humorous note in the remark section helps.
  269.  
  270.     Be creative!
  271.  
  272.  
  273. EMAIL ADDRESSES
  274.  
  275.     Send contest entries to:
  276.  
  277.     ...!{sun,pacbell,uunet,pyramid,amdahl}!hoptoad!obfuscate
  278.     obfuscate@toad.com
  279.  
  280.     The Judging will be done by Landon Noll and Larry Bassel.  If you have 
  281.     questions or comments (no entries), please feel free to email them to:
  282.  
  283.     ...!{sun,pacbell,uunet,pyramid,amdahl}!hoptoad!judges
  284.     judges@toad.com
  285.  
  286.  
  287. chongo <Landon Curt Noll> /\cc/\      hoptoad!chongo
  288. Larry Bassel                  {amdahl,ucbvax,cbosgd}|sun!lab
  289. -- 
  290. For a good prime, call:  391581 * 2^216193 - 1
  291.