home *** CD-ROM | disk | FTP | other *** search
/ Source Code 1992 March / Source_Code_CD-ROM_Walnut_Creek_March_1992.iso / usenet / altsrcs / 1 / 1251 < prev    next >
Encoding:
Internet Message Format  |  1990-12-28  |  9.4 KB
  1. From: obfuscat@hoptoad.uucp (Obfuscated C Contest)
  2. Newsgroups: comp.lang.c,comp.unix.wizards,alt.sources,comp.sources.d,misc.misc
  3. Subject: Repost of International Obfuscated C Code Contest Rules for 1990
  4. Message-ID: <11290@hoptoad.uucp>
  5. Date: 2 May 90 13:14:25 GMT
  6.  
  7. Due to the number of people requesting the IOCCC rules, we are reposting
  8. them again for the folks who missed then the first time.
  9.  
  10. The contest ends May 26.  (see below)
  11.  
  12. Due to a 2 week vacation there has been a delay in sending out "confirmation 
  13. of receipt" messages.  We have just now sent out confirmations to all entries
  14. recevied on/before 1-may-1990.  (If you think your entry was lost, wait a few
  15. days to see if the confirmation shows up.  If none does, go ahead and resend
  16. it as the net may have eaten your entry.)
  17.  
  18. chongo <sorry for the bother> /\cc/\
  19.  
  20. ==================
  21. 1990 rules follow:
  22.  
  23.     Obfuscate:  tr.v.  -cated, -cating, -cates.  1. a.  To render obscure.
  24.         b.  To darken.  2. To confuse:  his emotions obfuscated his
  25.         judgment.  [LLat. obfuscare, to darken : ob(intensive) +
  26.         Lat. fuscare, to darken < fuscus, dark.] -obfuscation n.
  27.         obfuscatory adj.
  28.  
  29. GOALS OF THE CONTEST:
  30.  
  31.     * To write the most Obscure/Obfuscated C program under the rules below.
  32.     * To show what should NOT be done in C programs.
  33.     * To provide a safe forum for poor C code.  :-)
  34.  
  35. DEDICATION:
  36.  
  37.     The 1990 International Obfuscated C Code Contest is dedicated to ANSI C.
  38.  
  39. RULES:
  40.  
  41.     To help us handle the vast volume of entries, we ask that you
  42.     follow the rules below.  Sorry for the length, but we need all
  43.     the help we can get!
  44.  
  45.     1) Your source MUST be 1536 bytes or less, and it must be a complete
  46.        program, not just a subroutine.
  47.  
  48.     2) To help us process your entries, we ask that you submit entries
  49.        in the following format.  Please be sure to include ALL --- lines,
  50.        otherwise our extraction program may skip your entry!
  51.  
  52. ---header items---
  53. name:        Your name, of course!
  54. org:        School/Company/Organization
  55. email address:    Email address from a well known site, or in a registered domain
  56. postal address:    Postal address
  57.         include your country as well
  58. environment:    Indicate the Hardware 
  59.         and OS under which your program was tested
  60. entry:        5    <number of entries sent so far including this one>
  61. remarks:    Remarks may be continued with leading whitespace until the
  62.         line ---how to compile-- is encountered.  (see #3 below)
  63. ---how to ANSI compile---
  64. X Give the command(s) needed to compile your program using an ANSI C
  65. X compiler.  If you program should not be compiled under an ANSI C compiler, 
  66. X leave this section blank.  Follow the format rules for the program 
  67. X section below, except that command size must be 160 characters or less.
  68. ---how to common compile---
  69. X Give the command(s) needed to compile your program using an K&R/traditional
  70. X C compiler.  If you program should not be compiled under a K&R style C, 
  71. X leave this section blank.  Follow the format rules for the program section
  72. X below, except that command size must be 160 characters or less.
  73. ---program---
  74. X Place obfuscated source of 1536 characters or less in this section.
  75. X Add a leading X to each line to avoid problems with mailers.
  76. X Some mailers don't like files with very long lines.  If your entry contains E
  77. C    lines longer 80 chars we ask you to form continuation line sets.  To form E
  78. C    a continuation line set, place an 'E' character at the point of a split E
  79. C    and place a C (instead of an X) at the beginning of the next line. E
  80. C    Finally, end the continuation line set as normal.
  81. X The E\nC's and leading X's will be removed prior to extraction and thus E
  82. C    they don't contribute toward the source character count.  All other E
  83. C    characters are considered to be source.  Whitespace after 'X' or 'C' E
  84. C    and before the 'E' is significant, we added it here for readability.
  85. X Newlines and tabs each count as 1 character.  Assume 8 character tab stops.
  86. X If your entry does not end in a newline, leave a final 'E' on the end. E
  87. ---end---
  88.  
  89.     3) Regarding the header items:
  90.  
  91.     * Any text outside of the above format will be kept confidential.
  92.  
  93.     * All header lines are required, but you may use 'anonymous'
  94.       for any header line other than 'remarks' or 'entry'.
  95.  
  96.     * In the 'remarks' please include:
  97.         - what this program does
  98.         - why you think the program is obfuscated
  99.         - any other remarks (humorous or otherwise)
  100.     
  101.     4) Your entry should be written in common C (K&R + common extensions)
  102.        or ANSI C.  If your program will NOT compile under an ANSI C or 
  103.        K&R C compiler, leave the particular 'how to' section blank.
  104.        If you leave a 'how to' section blank, include the '---' line.
  105.  
  106.        You do not have to fill in both 'how to' sections, though you must
  107.        fill in at least one 'how to' section.
  108.  
  109.     5) The program must be of original work.  All programs must be
  110.        in the public domain.  All copyrighted programs will be rejected.
  111.  
  112.     6) Entries must be received between 16-Mar-90 0:00 GMT and 
  113.        26-May-90 0:00 GMT.  Email your entries to:
  114.        
  115.         ...!{sun,pacbell,uunet,utzoo,pyramid,amdahl}!hoptoad!obfuscate
  116.  
  117.        We will attempt to Email a confirmation of receipt of contest
  118.        entries, however since Email is not reliable you may not receive it.
  119.        We regret that we can no longer accept entries via postal mail.
  120.  
  121.     7) Each person may submit up to 8 entries.  Multiple entries must
  122.        be sent in separate Email letters.
  123.     
  124.     8) Entries that can not be built automatically in a portable makefile 
  125.        are not allowed.  (e.g., don't use #include "/dev/tty")
  126.  
  127.     9) Starting this year, compiling entries must result an regular file
  128.        which can be executed. (No -o /dev/tty or similar compile lines)
  129.  
  130.  
  131. ANNOUNCEMENT OF WINNERS:
  132.  
  133.     * First announcement will likely be at the Summer 90 Usenix BOF.
  134.  
  135.     * Winning entries will be posted in mid June 1990 to 
  136.       comp.sources.unix as well as news groups where these rules 
  137.       were posted.  (depending on the judges work load)
  138.     
  139.     * Winning entries will be deposited into the uunet archives.
  140.  
  141.     * An article containing the winning entries will be published
  142.       in a future issue of the "Micro/Systems Journal".
  143.  
  144.     * Winners receive international fame and flames!  :-)
  145.  
  146.  
  147. JUDGING:
  148.  
  149.     Awards will be given to the best entry in a number of categories.
  150.     The actual category list will vary depending on the types of entries
  151.     we receive.  As a guide, consider using the following:
  152.  
  153.     * The best small one line program
  154.     * The strangest source layout
  155.     * The most useful obfuscated program
  156.     * The most creatively obfuscated program
  157.     * Best obfuscated entry smaller than 256 bytes
  158.     * Best obfuscated entry smaller than 1024 bytes
  159.     * Best abuse of ANSI
  160.     * Worse abuse of the rules (no abuse of entry format please!)
  161.     * <anything else so strange that it deserves an award>
  162.  
  163. POINTS TO PONDER:
  164.  
  165.     People are encouraged to examine winners of the previous
  166.     contests.  A copy of these entries was posted to
  167.     comp.sources.unix.  Contact the comp.sources.unix moderator, or
  168.     some archive site (such as uunet).  Keep in mind that rules
  169.     change from year to year, so some winning entries may not be
  170.     valid entries this year.  What was unique and novel one year
  171.     might be 'old' the next year.  In short, use your best judgment.
  172.  
  173.     We examine each entry on several levels of confusion.  For example
  174.     each entry is judged when we:
  175.  
  176.     * look at the original source
  177.     * run it through:  sed -e '/^#[     ]*define/d' | /lib/cpp
  178.     * run it through a C beautifier
  179.     * examine the algorithm
  180.     * compile and lint it
  181.     * execute it
  182.     
  183.     One line programs are best when they are short, obscure and concise.
  184.  
  185.     We tend to dislike programs that:
  186.  
  187.     * are very hardware specific
  188.     * are very OS or Un*x version specific
  189.          (index/strchr differences are ok, but socket/streams specific 
  190.           code is likely not to be)
  191.     * dump core or have compiler warnings
  192.          (it is ok only if you warn us in the 'remark' header item)
  193.     * won't compile under both BSD or SYS V Un*x
  194.     * use an excessively long compile line to get around the size limit
  195.     * are longer than they need to be
  196.     * are similar to previous winners
  197.     * are similar to previous losers  :-)
  198.  
  199.     Simply abusing #defines or -Dfoo=bar won't go as far as a program
  200.     that is more well rounded in confusion.
  201.  
  202.     Unless you are cramped for space, or unless you are entering the 
  203.     'best one liner' category, we suggest that you format your program 
  204.     in a more creative way than simply forming excessively long lines.
  205.  
  206.     We like programs that:
  207.  
  208.     * are as concise and small as they need to be
  209.     * do something quasi-interesting
  210.     * pass lint without complaint (particularly strict ANSI ones)
  211.     * are portable
  212.     * are unique or novel in their obfuscation style
  213.     * MAKE USE OF A NUMBER OF DIFFERENT TYPES OF OBFUSCATION
  214.     * make us laugh and/or throw up  :-)
  215.  
  216.     Some types of programs can't excel in some areas.  Of course, your 
  217.     program doesn't have to excel in all areas, but doing well in several 
  218.     areas really does help.
  219.  
  220.     Be creative!
  221.  
  222.     The Judging will be done by Landon Noll and Larry Bassel.  If you have
  223.     any QUESTIONS or COMMENTS, please feel free to send them to:
  224.  
  225.     ...!{sun,pacbell,uunet,pyramid,amdahl}!hoptoad!judges
  226.     judges@toad.com
  227.  
  228.     however contest entries should be sent to: 
  229.     
  230.     ...!{sun,pacbell,uunet,pyramid,amdahl}!hoptoad!obfuscate
  231.     obfuscate@toad.com
  232.  
  233.  
  234. chongo <Landon Curt Noll> /\cc/\      hoptoad!chongo
  235. Larry Bassel                  {amdahl,ucbvax,cbosgd}|sun!lab
  236.