Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/misc/volume39/ioccc.1993/part02

Text File | 1993-09-26 | 62.0 KB | 1,556 lines

Newsgroups: comp.sources.misc
From: [e-mail] (Landon Curt Noll)
Subject: v39i105:  ioccc.1993 - 1993 International Obfuscated C Code Contest winners, Part02/04
Message-ID: <[e-mail]>
X-Md4-Signature: bdb6183873fdfc0378b0208175a55f2c
Keywords: ioccc
Sender: [e-mail] (Kent Landfield)
Reply-To: [e-mail] (Landon Curt Noll)
Organization: Nebula Consultants in San Francisco
Date: Sun, 26 Sep 1993 17:25:40 GMT
Approved: [e-mail]

Submitted-by: [e-mail] (Landon Curt Noll)
Posting-number: Volume 39, Issue 105
Archive-name: ioccc.1993/part02
Environment: C

#! /bin/sh
# This is ioccc.1993, a shell archive.  Remove anything before this line,
# then feed it into a shell via "sh file" or similar.  To overwrite existing
# files, type "sh file -c".
#
# Contents:  1993/guidelines 1993/lmfjyh.c 1993/lmfjyh.hint
#   1993/plummer.hint 1993/rince.hint 1993/rules 1993/vanb.hint
#
# Send comments, questions, bugs to:
#
#    [e-mail]   -or-   ...!{sun,uunet,utzoo,pyramid}!hoptoad!judges
#
# You are strongly encouraged to read the new contest rules before
# sending any entries.  The rules, and sometimes the contest Email
# address itself, change over time.  Valid entries one year may
# be rejected in a later year due to changes in the rules.  The typical
# start date for contests is in early March.  Contest rules are normally not
# finalized and posted until the beginning of the contest.  The typical closing
# date for contests are in early May.
#
# The contest rules are posted to comp.unix.wizards, comp.lang.c,
# misc.misc, alt.sources and comp.sources.d.  If you do not have access
# to these groups, or if you missed the early March posting, you may
# request a copy from the judges, via Email, at the address above.
#
# Copyright (c) 1993, Landon Curt Noll & Larry Bassel.
# All Rights Reserved.  Permission for personal, educational 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 both Landon Curt Noll and Larry Bassel.
#
# Previous contest winners are available via anonymous ftp from
# ftp.uu.net under the directory /pub/ioccc.
#
# Wrapped by kent@sparky on Sun Sep 26 12:05:11 1993
PATH=/bin:/usr/bin:/usr/ucb:/usr/local/bin:/usr/lbin ; export PATH
echo If this archive is complete, you will see the following message:
echo '          "shar: End of archive 2 (of 4)."'
if test -f '1993/guidelines' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'1993/guidelines'\"
else
  echo shar: Extracting \"'1993/guidelines'\" \(25594 characters\)
  sed "s/^X//" >'1993/guidelines' <<'END_OF_FILE'
X10th International Obfuscated C Code Contest Guidelines, Hints and Comments
X
XCopyright (c) Landon Curt Noll & Larry Bassel, 1993.
XAll Rights Reserved.  Permission for personal, educational or non-profit use is
Xgranted provided this this copyright and notice are included in its entirety
Xand remains unaltered.  All other uses must receive prior permission in writing
Xfrom both Landon Curt Noll and Larry Bassel.
X
XABOUT THIS FILE:
X
X    This file is intended to help people who wish to submit entries to
X    the International Obfuscated C Code Contest (IOCCC for short).
X
X    This is not the IOCCC rules, though it does contain comments about
X    them.  The guidelines should be viewed as hints and suggestions.
X    Entries that violate the guidelines but remain within the rules are
X    allowed.  Even so, you are safer if you remain within the guidelines.
X
X    You should read the current IOCCC rules, prior to submitting entries.
X    The rules are typically sent out with these guidelines.
X
X    Changes from the 1993 draft are noted by change bars.  --->              |
X
X
XWHAT IS NEW IN 1993:
X
X    The entry format is better (for us anyway).  The program mkentry.c
X    has been updated.  See ENTRY FORMAT.
X
X    We will reject entries that cannot be compiled using an ANSI C
X    compiler.  Certain old Obfuscation hacks that cause ANSI C compilers
X    fits are no longer permitted.  Some of the new issues deal with
X    non-integral array types, variable number of arguments, C preprocessor
X    directives and the exit() function.  See OUR LIKES AND DISLIKES.
X
X
XHINTS AND SUGGESTIONS:
X
X    You are encouraged to examine the winners of previous contests.  See
X    FOR MORE INFORMATION for details on how to get previous winners.
X
X    Keep in mind that rules change from year to year, so some winning entries
X    may not be valid entries this year.  What was unique and novel one year
X    might be 'old' the next year.
X
X    An entry is usually examined in a number of ways.  We typically apply
X    a number of tests to an entry:
X
X    * look at the original source
X    * convert ANSI tri-graphs to ASCII
X    * C pre-process the source ignoring '#include' lines
X    * C pre-process the source ignoring '#define' and '#include' lines
X    * run it through a C beautifier
X    * examine the algorithm
X    * lint it
X    * compile it
X    * execute it
X
X    You should consider how your entry looks in each of the above tests.
X    You should ask yourself if your entry remains obscure after it has been
X    'cleaned up' by the C pre-processor and a C beautifier.
X
X    Your entry need not do well under all, or in most tests.  In certain
X    cases, a test is not important.  Entries that compete for the
X    'strangest/most creative source layout' need not do as well as
X    others in terms of their algorithm.  On the other hand, given
X    two such entries, we are more inclined to pick the entry that
X    does something interesting when you run it.
X
X    We try to avoid limiting creativity in our rules.  As such, we leave
X    the contest open for creative rule interpretation.  As in real life
X    programming, interpreting a requirements document or a customer request
X    is important.  For this reason, we often award 'worst abuse of the
X    rules' to an entry that illustrates this point in an ironic way.
X
X    If you do plan to abuse the rules, we suggest that you let us know
X    in the remarks section.  Please note that an invitation to abuse
X    is not an invitation to break.  We are strict when it comes to the
X    3217 byte size limit.  Also, abusing the entry format tends to
X    annoy more than amuse.
X
X    We do realize that there are holes in the rules, and invite entries
X    to attempt to exploit them.  We will award 'worst abuse of the rules'
X    and then plug the hole next year.  Even so, we will attempt to use
X    the smallest plug needed, if not smaller.  :-)
X
X    Check out your program and be sure that it works.  We sometimes make
X    the effort to debug an entry that has a slight problem, particularly
X    in or near the final round.  On the other hand, we have seen some
X    of the best entries fall down because they didn't work.
X
X    We tend to look down on a prime number printer, that claims that
X    16 is a prime number.  If you do have a bug, you are better off
X    documenting it.  Noting "this entry sometimes prints the 4th power
X    of a prime by mistake" would save the above entry.  And sometimes,
X    a strange bug/feature can even help the entry!  Of course, a correctly
X    working entry is best.
X
X
XOUR LIKES AND DISLIKES:
X
X    Doing masses of #defines to obscure the source has become 'old'.  We
X    tend to 'see thru' masses of #defines due to our pre-processor tests
X    that we apply.  Simply abusing #defines or -Dfoo=bar won't go as far
X    as a program that is more well rounded in confusion.
X
X    Many ANSI C compilers dislike the following code, and so do we:
X
X    #define d define
X    #d foo           <-- don't expect this to turn into #define foo
X
X    int i;
X    j;           <-- don't use such implicit type declaration
X    int k;
X
X    We suggest that you compile your entry with an ANSI C compiler.  If you
X    must use non-ANSI C, such as K&R C, you must avoid areas that result in
X    compile/link errors for ANSI C compilers.
X
X    Unfortunately, some ANSI C compilers require array indexes to be of       |
X    integral type.  Thus, the following classical obfuscation hacks should    |
X    not be used in 1993.  This rule may be relaxed in future contests.          |
X
X    int i;
X    char *c;
X    i[c];           <--- use c[i] instead
X    (i+3)["string"];   <--- use "string"[i+3] instead
X
X    If your entry uses functions that have a variable number of
X    arguments, be careful. Systems implement va_list as a wide variety
X    of ways.  Because of this, a number of operations using va_list are
X    not portable and must not be used:
X
X    * assigning a non-va_list variable to/from a va_list variable
X    * casting a non-va_list variable into/from a va_list variable
X    * passing a va_list variable to a function expecting a non-va_list arg
X    * passing a non-va_list variable to a function expecting a va_list arg
X    * performing arithmetic on va_list variables
X    * using va_list as a structure or union
X
X    In particular, do not treat va_list variables as if they were a char **'s.
X
X    Avoid using <varargs.h>, use <stdarg.h> instead.
X
X    If you use C preprocessor directives (#define, #if, #ifdef, ...),
X    the leading '#' must be the first character on a line.  While some
X    C preprocessors allow whitespace the leading '#', many do not.
X
X    Because the exit() function returns void on some systems, entries
X    must not assume that it returns an int.
X
X    Small programs are best when they are short, obscure and concise.
X    While such programs are not as complex as other winners, they do
X    serve a useful purpose.  They are often the only program that people
X    attempt to completely understand.  For this reason, we look for
X    programs that are compact, and are instructional.
X
X    One line programs should be short one line programs, say around 80
X    bytes long.  Getting close to 160 bytes is a bit too long in our opinion.
X
X    We tend to dislike programs that:
X
X    * are very hardware specific
X    * are very OS or Un*x version specific
X         (index/strchr differences are ok, but socket/streams specific
X          code is likely not to be)
X    * dump core or have compiler warnings
X         (it is ok only if you warn us in the 'remark' header item)
X    * won't compile under both BSD or SYS V Un*x
X    * abusing the build file to get around the size limit
X    * obfuscate by excessive use of ANSI tri-graphs
X    * are longer than they need to be
X    * are similar to previous winners
X    * are identical to previous losers  :-)
X
X    Unless you are cramped for space, or unless you are entering the
X    'best one liner' category, we suggest that you format your program
X    in a more creative way than simply forming excessively long lines.
X
X    The build file should not be used to try and get around the size
X    limit.  It is one thing to make use of a several -D's to help out,
X    but it is quite another to use 200+ bytes of -D's in order to
X    try and squeeze the source under the size limit.  You should feel
X    free to make use of the build file space, but you are better off
X    if you show some amount of restraint.
X
X    We allowed whitespace, and in certain cases ; { or } do not impact
X    your program size (up to a certain point), because we want to get
X    away from source that is simply a compact blob of characters.
X
X    Given two versions of the same program, one that is a compact blob
X    of code, and the other that is formatted more like a typical C
X    program, we tend to favor the second version.  Of course, a third
X    version of the same program that is formatted in an interesting
X    and/or obfuscated way, would definitely win over the first two!
X
X    We suggest that you avoid trying for the 'smallest self-replicating'
X    program.  We are amazed at the many different sizes that claim
X    to be the smallest.  There is nothing wrong with self-replicating
X    programs.  In fact, a number of winners have been self-replicating.
X    You might want to avoid the claim of 'smallest', lest we (or others)
X    know of a smaller one!
X
X    X client entries should be as portable as possible.  Entries that
X    adapt to a wide collection of environments will be favored.  Don't
X    depend on a particular type of display.  For example, don't depend
X    on color or a given size.  Don't require backing store.
X
X    X client entries should avoid using X related libraries and
X    software that is not in wide spread use.  We ask that such X client
X    entries restrict themselves to only the low level Xlib and the
X    Athena widget set (libX11.a, libXaw.a, libXmu.a and libXt.a).
X    Don't use M*tif, Xv*ew, or OpenL*ok toolkits, since not everyone
X    has them.  Avoid depending on a particular window manager.  Not
X    everyone has X11r5, and some people are stuck back in X11r4 (or
X    earlier), so try to target X11r5 without requiring X11r5.  Better
X    yet, try to make your entry run on all version 11 X Window Systems.
X
X    X client entries should not to depend on particular items on
X    .Xdefaults.  If you must do so, be sure to note the required lines
X    in the ---remark--- section.
X
X    We like programs that:
X
X    * are as concise and small as they need to be
X    * do something at least quasi-interesting
X    * pass lint without complaint (not a requirement, but it is nice)
X    * are portable
X    * are unique or novel in their obfuscation style
X    * MAKE USE OF A NUMBER OF DIFFERENT TYPES OF OBFUSCATION
X    * make us laugh and/or throw up  :-)
X
X    Some types of programs can't excel in some areas.  Of course, your
X    program doesn't have to excel in all areas, but doing well in several
X    areas really does help.
X
X    We freely admit that interesting, creative or humorous comments in
X    the ---remark--- section helps your chance of winning.  If you had to
X    read of many twisted entries, you too would enjoy a good laugh or two.
X    We think the readers of the contest winners do as well.
X
X    Be creative!
X
X
XENTRY FORMAT:
X
X    In order to help us process the many entries, we must request your
X    assistance by formatting your entries in a certain way.  This format,
X    in addition, allows us to quickly separate information about the
X    author from the program itself.  (see JUDGING PROCESS)
X
X    We have provided the program, mkentry, as an example of how to
X    format entries.  You should be aware of the following warning that
X    is found in mkentry.c:
X
X    This program attempts to implement the IOCCC rules.  Every
X    attempt has been made to make sure that this program produces
X    an entry that conforms to the contest rules.  In all cases,
X    where this program differs from the contest rules, the
X    contest rules will be used.  Be sure to check with the
X    contest rules before submitting an entry.
X
X    You are not required to use mkentry.  It is convenient, however,
X    as it attempts to uuencode the needed files, and attempt to check
X    the entry against the size rules.
X
X    If you have any suggestions, comments, fixes or complaints about
X    the mkentry.c program, please send Email to the judges.  (see below)
X
X    The following is a sample entry:
X
X---entry---
Xrule:    1993
Xfix:    n
Xtitle:    chonglab
Xentry:    0
Xdate:    Mon Mar  1 08:45:20 1993
Xhost:    Un*x v6, pdp11/45
X    2.9BSD, pdp11/70
X---remark---
X    This is a non-obfuscated obfuscated C program.
X
X    It is likely not to win a prize.  But what do you expect from
X    a short example!
X---author---
Xname:    Landon Curt Noll
Xorg:    IOCCC Judging Group
Xaddr:    Toad Hall
X    PO Box 170608
X    San Francisco, California
X    94117-0608
X    USA
Xemail:    [e-mail]
Xanon:    n
X---author---
Xname:    Larry Bassel
Xorg:    IOCCC Judging Group
Xaddr:    Toad Hall
X    PO Box 170608
X    San Francisco, California
X    94117-0608
X    USA
Xemail:    hoptoad!sun!lab
X    [e-mail]
Xanon:    n
X---info---
Xbegin 444 info.file
XM0V]P>7)I9VAT("AC*2!,86YD;VX@0W5R="!.;VQL+"`Q.3DS+@I!;&P@4FEG
XM:'1S(%)E<V5R=F5D+B`@4&5R;6ES<VEO;B!F;W(@<&5R<V]N86PL(&5D=6-A
XM=&EO;B!O<B!N;VXM<')O9FET('5S92!I<PIG<F%N=&5D('!R;W9I9&5D('1H
XM:7,@=&AI<R!C;W!Y<FEG:'0@86YD(&YO=&EC92!A<F4@:6YC;'5D960@:6X@
XM:71S(&5N=&ER971Y"F%N9"!R96UA:6YS('5N86QT97)E9"X@($%L;"!O=&AE
XM<B!U<V5S(&UU<W0@<F5C96EV92!P<FEO<B!P97)M:7-S:6]N(&EN('=R:71I
XM;F<*9G)O;2!,86YD;VX@0W5R="!.;VQL+@H*5&AA="!T:&%T(&ES+"!I<RX*
XM5&AA="!T:&%T(&ES(&YO="P*("`@(&ES(&YO="!T:&%T('1H870@;F]T(&ES
XM+@I4:&%T(&ES+"!T:&%T('1H870@:7,@;F]T+"!I<R$*"@D)+2T@8VAO;F=O
XM(#$Y-S0*"DQA<W0@>65A<BP@;VYE('!E<G-O;B!T;VQD('5S('1H870@=&AE
XM>2!A8W1U86QL>2!D96-O9&5D('1H:7,@9FEL92X*22!W;VYD97(@:&]W(&UA
X9;GD@=VEL;"!D;R!I="!T:&ES('EE87(_"@``
X`
Xend
X---build---
Xbegin 444 build
X28V,@<')O9RYC("UO('!R;V<*
X`
Xend
X---program---
Xbegin 444 prog.c
XM;6%I;B@I"GL*(VEF(&1E9FEN960H05]214=)4U1%4D5$7U9/5$527TE.7U-5
XM3DY95D%,15]#04Q)1D]23DE!7U5302D*("`@('!R:6YT9B@B5F]T92!,86YD
XM;VX@3F]L;"!F;W(@4W5N;GEV86QE($-I='D@0V]U;F-I;"!S96%T(",Q+EQN
X:(BD["B-E;F1I9@H@("`@97AI="@P*3L*?0H`
X`
Xend
X---end---
X
X    Typically the build file should assume that the source is prog.c
X    and will compile into prog.  If an entry wins, we will rename
X    its source and binary to avoid filename collision.  By tradition,
X    we use the name of the entry's title, followed by an optional
X    digit in case of name conflicts.
X
X    If the above entry somehow won the 'least likely to win' award,
X    we would use chonglab.c and chonglab.
X
X    If your entry depends on, or requires that your build, source
X    and/or binary files be a particular name, please say so in the
X    ---remark--- section.  If this case applies, it would be be helpful
X    if you did one of the following:
X
X    * Tell us how to change the filename(s) in your entry.
X
X    * Have the build file make copies of the files.  For example:
X
X        cc prog.c -o special_name        need special binary
X
X        or  rm -f special_src.c            need special source
X        cp prog.c special_src.c
X        cc special_src.c -o special_name
X
X        or  rm -f special_build            need special build
X        tail +4 build > special_build
X        sh < special_build
X
X    * Assume that we will use the entry title.  Send us a version of
X      your build/program files that uses the name convention.  You
X      should uuencode these files in ---data--- sections.
X
X    If your entry needs to modify its source, info or binary files,
X    please say so in the ---remark--- section.  You should try to avoid
X    touching your original build, source and binary files.  You should
X    arrange to make copies of the files you intend to modify.  This
X    will allow people to re-generate your entry from scratch.
X
X    Remember that your entry may be built without a build file.  We
X    typically incorporate the build lines into a Makefile.  If the
X    build file must exist, say so in the ---remark--- section.
X
X    If your entry needs special info files, you should uuencode them
X    into ---info--- sections.  In the case of multiple info files,
X    use multiple ---info--- sections.  If no info files are needed,
X    then skip the ---info--- section.
X
X    Info files are intended to be input, or detailed information that
X    does not fit well into the ---remark--- section.  For example, an
X    entry that implements a compiler might want to provide some sample
X    programs for the user to compile.  An entry might want to include a
X    lengthy design document, that might not be appropriate for a
X    'hints' file.
X
X    Info files should be used only to supplement your entry.  For
X    example, info files may provide sample input or detailed
X    information about your entry.  Because they are supplemental,
X    the entry should not require them exist.
X
X    In some cases, your info files might be renamed to avoid name
X    conflicts.  If info files should not be renamed for some reason,
X    say so in the ---remark--- section.
X
X    Info files must uudecode into the current directory.  If they
X    absolutely must be renamed, or moved into a sub-directory, say
X    so in the ---remark--- section.
X
X    When submitting multiple entries, be sure that each entry has
X    a unique entry number from 0 to 7.  Your first entry should
X    have entry number 0.
X
X    With the exception of the header, all text outside of the entry
X    format may be ignored.  That is, don't place text outside of the
X    entry and expect the judges to see it.  (Our decoding tools aren't
X    AI progs!) If you need tell the the something, put it in the
X    ---remark--- section, or send a Email to the judges at:
X
X    ...!{apple,pyramid,sun,uunet}!hoptoad!judges    (not the address for
X    [e-mail]                     submitting entries)
X
X    The date should be given with respect to UTC.  (Some systems refer
X    to this as GMT or GMT0)  The format of the date should be that as
X    returned by asctime() in the C locale.  An example of such a string is:
X
X    Thr Apr 01 00:47:00 1993
X
X    This format is similar to the output of the date(1) command.  The
X    string does not include the timezone name before the year.  On many
X    systems, one of the following command will produce a similar string:
X
X    date -u "+%a %h %d %T 19%y"
X    date -u | sed -e 's/... \(19[0-9][0-9]\)$/\1/'
X    sh -c 'TZ=UTC date | sed -e "s/... \(19[0-9][0-9]\)$/\1/"'
X    sh -c 'TZ=GMT date | sed -e "s/... \(19[0-9][0-9]\)$/\1/"'
X    sh -c 'TZ=GMT0 date | sed -e "s/... \(19[0-9][0-9]\)$/\1/"'
X
X    You are allowed to update/fix/revise your entry.  To do so, set
X    the 'fix' line in the ---entry--- section to 'y' instead of 'n'.
X    Be sure that the resubmittion uses the same title and entry number
X    as well, as these are used to determine which entry is to be
X    replaced.
X
X
XJUDGING PROCESS:
X
X    Entries are judged by Larry Bassel and Landon Curt Noll.
X
X    Entries are unpacked into individual directories.  The Email message
X    is unpacked into individual files, each containing:
X
X    ---entry--- section
X    all ---author--- sections
X    all ---info--- sections
X    ---build--- section
X    ---program--- section
X    any other text, including the Email message headers
X
X    Prior to judging, the 'any other text' file is scanned to be sure
X    it does not contain useful information (or in case the entry was
X    malformed and did not unpack correctly).  Information from the
X    ---author--- sections are not read until the judging process is
X    complete, and then only from entries that have won an award.
X
X    The above process helps keep us biased for/against any one particular
X    individual.  We are usually kept in the dark as much as you are
X    until the final awards are given.  We like the surprise of finding
X    out in the end, who won and where they were from.
X
X    We attempt to keep all entries anonymous, unless they win an award.
X    Because the main 'prize' of winning is being announced, we make all
X    attempts to send non-winners into oblivion.  We remove all non-winning
X    files, and shred all related paper.  By tradition, we do not even
X    reveal the number of entries that we received.  (for the curious,
X    we do indicate the volume of paper consumed when presenting the IOCCC
X    winners at talks)
X
X    After the Usenix announcement, we attempt to send Email to the
X    authors of the winning entries.  One reason we do this is to give
X    the authors a chance to comment on the way we have presented their
X    entry.  They are given the chance to correct mistakes, typos.  We
X    often accept their suggestions/comments about our remarks as well.
X    This is done prior to posting the winners to the wide world.
X
X    Judging consists of a number of elimination rounds.  During a round,
X    the collection of entries are divided into two roughly equal piles;
X    the pile that advances on to the next round, and the pile that does
X    not.  We also re-examine the entries that were eliminated in the
X    previous round.  Thus, an entry gets at least two readings.
X
X    A reading consists of a number of actions:
X
X    * reading the ---entry--- section
X    * reading the uudecoded ---build--- section
X    * reading the uudecoded ---program--- section
X    * reading the uudecoded ---info--- section(s), if any
X    * passing the source thru the C pre-processor
X        shipping over any #include files
X    * performing a number of C beautify/cleanup edits on the source
X    * passing the beautified source thru the C pre-processor
X        shipping over any #include files
X
X    In later rounds, other actions are performed:
X
X    * linting the source
X    * compiling/building the source
X    * running the program
X    * performing misc tests on the source and binary
X
X    Until we reduce the stack of entries down to about 25 entries, entries
X    are judged on an individual basis.  An entry is set aside because it
X    does not, in our opinion, meet the standard established by the round.
X    When the number of entries thins to about 25 entries, we begin to form
X    award categories.  Entries begin to compete with each other for awards.
X    An entry often will compete in several categories.
X
X    The actual award category list will vary depending on the types of entries
X    we receive.  A typical category list might be:
X
X    * best small one line program
X    * best small program
X    * strangest/most creative source layout
X    * most useful obfuscated program
X    * best game that is obfuscated
X    * most creatively obfuscated program
X    * most deceptive C code
X    * best X client (see OUR LIKES AND DISLIKES)
X    * best abuse of ANSI C
X    * worst abuse of the rules
X    * <anything else so strange that it deserves an award>
X
X    We do not limit ourselves to this list.  For example, a few entries are so
X    good/bad that they are declared winners at the start of the final round.
X    We will invent awards categories for them, if necessary.
X
X    In the final round process, we perform the difficult tasks of
X    reducing the remaining entries (typically about 25) down to 8 or 10
X    winners.  Often we are confident that the entries that make it into
X    the final round are definitely better than the ones that do not
X    make it.  The selection of the winners out of the final round, is
X    less clear cut.
X
X    Sometimes a final round entry good enough to win, but is beat out
X    by a similar, but slightly better entry.  For this reason, it is
X    sometimes worthwhile to re-enter an improved version of an entry
X    that failed to win in a previous year.  This assumes, of course,
X    that the entry is worth improving in the first place!
X
X    More often that not, we select a small entry (usually one line), a
X    strange/creative layout entry, and an entry that abuses the contest
X    rules in some way.
X
X    In the end, we traditionally pick one entry as 'best'.  Sometimes such
X    an entry simply far exceeds any of the other entry.  More often, the
X    'best' is picked because it does well in a number of categories.
X
X
XANNOUNCEMENT OF WINNERS:
X
X    The first announcement, occurs at a Summer Usenix conference.  By tradition,
X    this is done during the latter part of the UUNET/IOCCC BOF, just prior to
X    the Berkeley BSD, and BSDI BOF.
X
X    Winning entries will be posted in late June to the following groups:
X
X        comp.lang.c          comp.unix.wizards    alt.sources
X
X    In addition, pointers to these postings are posted to the following
X
X        comp.sources.d      alt.sources.d        misc.misc
X        comp.sources.misc      comp.windows.x
X
X    Winning entries will be deposited into the uunet archives.  See
X    below for details.
X
X    Often, winning entries are published in selected magazines.  Winners
X    have appeared in books ("The New Hackers Dictionary") and on T-Shirts.
X
X    Last, but not least, winners receive international fame and flames!  :-)
X
X
XFOR MORE INFORMATION:
X
X    You may contact the judges by sending Email to the following address:
X
X    ...!{apple,pyramid,sun,uunet}!hoptoad!judges    (not the address for
X    [e-mail]                     submitting entries)
X
X    Questions and comments about the contest are welcome.
X
X    The rules and the guidelines may (and often do) change from year to          |
X    year.  You should be sure you have the current rules and guidelines          |
X    prior to submitting entries.  To obtain them, send Email to the address   |
X    above and use the subject 'send rules'.                      |
X
X    One may obtain winners of previous contests (1984 to date), via ftp from: |
X
X    host: ftp.uu.net    (192.48.96.9)                      |
X    user: anonymous
X    pass: yourname@yourhost
X    dir:  ~/pub/ioccc                              |
X
X    As a last resort, previous winners may be obtained by sending Email          |
X    to the above address.  Please use the subject 'send YEAR winners',          |
X    where YEAR is a single 4 digit year, a year range, or 'all'.          |
X
X
Xchongo <Landon Curt Noll> /\cc/\      [e-mail]                  |
XLarry Bassel                  [e-mail]                  |
END_OF_FILE
  if test 25594 -ne `wc -c <'1993/guidelines'`; then
    echo shar: \"'1993/guidelines'\" unpacked with wrong size!
  fi
  # end of '1993/guidelines'
fi
if test -f '1993/lmfjyh.c' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'1993/lmfjyh.c'\"
else
  echo shar: Extracting \"'1993/lmfjyh.c'\" \(17 characters\)
  sed "s/^X//" >'1993/lmfjyh.c' <<'END_OF_FILE'
Xchar*_=__FILE__;
END_OF_FILE
  if test 17 -ne `wc -c <'1993/lmfjyh.c'`; then
    echo shar: \"'1993/lmfjyh.c'\" unpacked with wrong size!
  fi
  # end of '1993/lmfjyh.c'
fi
if test -f '1993/lmfjyh.hint' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'1993/lmfjyh.hint'\"
else
  echo shar: Extracting \"'1993/lmfjyh.hint'\" \(5414 characters\)
  sed "s/^X//" >'1993/lmfjyh.hint' <<'END_OF_FILE'
XMost Versatile Source: <[e-mail]> Jyrki Holopainen
X
X    Jyrki Holopainen
X    Oy LM Ericsson Ab
X    SF-02420 Jorvas
X    Finland
X
X
XJudges' comments:
X
X    To use:
X    make lmfjyh
X    ./lmfjyh
X
X    See the makefile for details.
X
X    There's more than one way to get around disk quotas. :-)
X
X    Some people have reported problems compiling this entry
X    with gcc 2.3.3.
X
X    The make command:
X
X    make tidy
X
X    will remove the "special" file that is created during the
X    make of lmfjyh.
X
X
XSelected notes from the author:
X
X    "Practical and efficient method of compressing source code"
X
X    1. Introduction
X
X    I will shortly present a totally new compression method.
X    It may be used to compress any types of files, but it works
X    best with C-source code.
X
X    As an example, I have taken a simple "Hello world!" program
X    that should be familiar to all C-programmers.
X
X    Listing 1. A simple "Hello World" program:
X
X    main()
X    {
X      puts("Hello World!");
X    }
X
X
X    2. Packing method
X
X    Normally a file name is used only to identify the file,
X    but this new revolutionary method introduces a totally new concept:
X    THE FILE NAME IS THE PROGRAM. There is no need to waste
X    valuable disk space to store source code. The program is
X    embedded in the file name, only a minor portion of it
X    is inside the file.
X
X    Listing 2. Compressed "Hello world":
X
X    char*_=__FILE__;
X
X
X    Listing 3. Code embedded in the file name:
X
X    ";main(){puts("Hello World!");}char*C=".c
X
X
X    The sample program in listing 1 is 36 bytes long. By using the new
X    compression method, the example program may be squeezed to sixteen
X    bytes. In the example the compression ratio is 2:1. It is evident
X    that the longer the program is, the better the compression ratio
X    is. The maximum compression ratio in a UNIX environment is 254:16
X    which equals approximately to 16:1.  By using the method a one
X    megabyte of source code can be compressed to 64 kilobytes.
X
X    One might easily think that the program could be compressed to a
X    single byte by writing a one character long preprocessor directive
X    in the source file and defining the actual source code in the
X    command line, eg. 'cc hello.c -DX=main(){puts...'.  With this
X    method nothing is gained, since the compiling commands must be
X    stored in a file, and that takes even more space than writing the
X    code in a source file as presented in listing 1.
X
X
X    3. Packing files in a UNIX environment
X
X    In a UNIX environment it is possible to write almost any program by
X    including the code in file names. Since '/' is used to separate
X    path components and cannot therefore exist in a file name, all
X    features of C-language cannot be used.
X
X    In C, the '/' is used as a division operator and it may also be a
X    part of a comment start and end identifier. This is, however, not a
X    dangerous limitation, since practice has shown that comments are
X    almost totally unnecessary. A real programmer can more easily
X    understand pure source code, and misleading comments are
X    disastrous. The division operation may be replaced with pow(x, -1)
X    and multiplication when using real numbers or with div() function
X    when using integers.
X
X    Large programs must be separated into small modules. This enforces
X    people to write better programs, since monolithic programming style
X    cannot be used. Program development will also be faster, no extra
X    code need not be recompiled after changes have been made.
X
X
X    4. Usage with currently available tools
X
X    I have tested how well this new method works with currently
X    available programming tools.
X
X    Any ANSI conforming C-compiler that runs under a REAL operating
X    system should be able to compile the code.  (there may be problems
X    with some older UNIX variants)
X
X    4.1. Compilers:
X
X    These worked:
X    gcc versions 2.0, 2.1, 2.3.2 (ld failed at AIX with gcc 2.1)
X    cc (HP-UX)
X    cc (VAX)
X
X    These failed miserably:
X    cc (SunOs/Solaris)      - could not start cpp properly
X    cc/xlc (AIX)            - could not open source
X
X    4.2. Other tools:
X
X    4.2.1 Debuggers: (tested at SunOs 4.1.2)
X
X    dbx     - Quit with a very 'informative' error message:
X        "dbx: fatal error: Is a directory"
X
X    gdb     - Printed almost the same error message ":Is a directory".
X        It was, however, possible to step through the code but
X        not list it.
X
X    4.2.2 Lints:
X
X        - None of the lints at tested environments were able
X          to open the file.
X
X
X    5. Conclusions
X
X    The method can be used to compress any types of files, actually the
X    compression ratios are even better when compressing other files
X    than C-source.  For example plain text files may be compressed with
X    INFINITE compression ratio. It is trivial task to compress a 100
X    kilobytes long text file in about 400 files whose lengths are zero
X    bytes.  The drawback is that the files must be unpacked before they
X    can be used, so a large amount of temporary disk space is needed,
X    while C-source is totally usable in the compressed form.
X
X    Evidently, there is a long way to go before this new programming
X    technique may be widely used, since currently there are only few
X    tools supporting it. The advantages over the traditional methods
X    are, however, so great that there is no doubt that this method will
X    be new standard.
END_OF_FILE
  if test 5414 -ne `wc -c <'1993/lmfjyh.hint'`; then
    echo shar: \"'1993/lmfjyh.hint'\" unpacked with wrong size!
  fi
  # end of '1993/lmfjyh.hint'
fi
if test -f '1993/plummer.hint' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'1993/plummer.hint'\"
else
  echo shar: Extracting \"'1993/plummer.hint'\" \(3613 characters\)
  sed "s/^X//" >'1993/plummer.hint' <<'END_OF_FILE'
XBest One Liner: <[e-mail]> Mark Plummer
X
X    Mark Plummer
X    2901 Reckord Road
X    Fallston, MD, 21047
X    USA
X
X
XJudges' comments:
X
X    To run:
X    make plummer
X    ./plummer number arg
X
X    where:
X    number    a number     (try 21701)
X    arg    any argument
X
X    For extra credit: What happens when 'number' contains non-numeric
X    characters, and why?
X
X
XSelected notes from the author:
X
X    This program prints out all numbers up to a given number of digits
X    on a single line.  When the largest number is reached, the program
X    starts again with 0.  It takes two arguments: the first argument
X    specifies the number to start counting from and uses leading 0's to
X    indicate the number of digits, the second argument can be anything
X    but must be present.
X
X    Variable names are single characters chosen for their similarity to
X    other characters (O for 0, l for 1, S for 5 (in some fonts), and _
X    for ...  well nothing really, but it is easy to miss).  To prevent
X    the need for strlen(), the fact that argv is laid out sequentially
X    is exploited (ie.  argv[i + 1] == argv[i] + strlen(argv[i]) + 1).
X    This is not portable (by the books), but it seems to work
X    everywhere I try (actually, for vms, that only holds for i > 1).
X    Also, I depend on the fact that a carriage return causes the line
X    just written to be overwritten.  lint (and most compilers) complain
X    that there is no control path leading to a return from main().  At
X    125 characters, it still fits on a single line (for those of us who
X    don't mind ruining our eyes with 132 column screens).
X
X    The first statement points the base of l (the argument vector) to
X    be the first argument by incrementing it.  It then assigns O to
X    point to the character before the first character of the second
X    argument which also happens to be the null termination of the first
X    argument.  *O gets a \r assigned to it.  Finally 0 is assigned to
X    the first character of the second argument which has the effect of
X    null terminating the first argument after the carriage return had
X    removed its null termination.  I really tried to make the last part
X    of that statement part of the original expression, but the best I
X    could do was attach it with a comma (against the advice of K&R).
X    The for loop runs the next for loop continuously (actually until
X    the machine crashes or the user gets tired of seeing the
X    counting).  The next for loop is the meat of the program.  In the
X    initialization statement, the string pointed to by l (the first
X    argument containing the digits used for counting followed by a \r)
X    is printed, and _ is started at the least significant digit in the
X    string.  In the test portion, _ is insured not to be past the
X    beginning of the string (the most significant digit), and the digit
X    pointed to by _ is incremented and checked to be sure that it _is_
X    greater than '9' (written here as (S+*O+S)*S).  If the test fails,
X    either the string has been incremented or each digit in the string
X    has been reset to '0'.  If the test succeeded, the iteration
X    statement assigns '0' (written here as (S+*O)*S (which has the
X    added bonus of having the code be a cry for help)) to *_ and
X    decrements _ to point to the next more significant digit to be
X    incremented; it is done only when a carry situation results (*_ has
X    been incremented past '9').
X
X    The inspiration for this program came from actual code which dealt
X    with scanning for a unique temporary filename by appending a
X    successively larger number to the end of a string.
END_OF_FILE
  if test 3613 -ne `wc -c <'1993/plummer.hint'`; then
    echo shar: \"'1993/plummer.hint'\" unpacked with wrong size!
  fi
  # end of '1993/plummer.hint'
fi
if test -f '1993/rince.hint' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'1993/rince.hint'\"
else
  echo shar: Extracting \"'1993/rince.hint'\" \(6839 characters\)
  sed "s/^X//" >'1993/rince.hint' <<'END_OF_FILE'
XMost Well Rounded: <[e-mail]> James Bonfield
X
X    James Bonfield
X    MRC Laboratory of Molecular Biology,
X    Hills Road,
X    Cambridge,
X    England
X
X
XJudges' comments:
X
X    To run:
X    make rince
X    rince [cabbage]
X
X    where:
X    [cabbage]    a CABBAGE description file  (default: rince.c)
X
X    The author has provided several CABBAGE files for your amusement:
X
X    rince.data1    plays breakout.  Keys are ',' for left, '/'
X            for right, and '.' for 'fire the ball'.
X
X    rince.data2    plays the old rince game from IOCCC 1991
X
X    rince.data3    Sokoban screen 11. You are the 'o' character. You
X            must push the money 'm' into the dotted region of
X            the screen. The game is considered finished when
X            all the 'm's are then 'M's.
X
X    rince.data4    Sokoban screen 13. Same rules as above.
X
X    For a brief design description, see rince.design.
X
X    The select(2) from SunOS says:
X
X    BUGS
X
X    ...
X
X    select() should probably return the time remaining from  the
X    original  timeout,  if  any,  by modifying the time value in
X    place.  This may be implemented in future  versions  of  the
X    system.   Thus,  it  is  unwise  to  assume that the timeout
X    pointer will be unmodified by the select() call.
X
X    Systems such as Linux does return the remaining time in timeout
X    field (0 if no keys were pressed), but `rince' assumes that
X    timeout remains unmodified.
X
X    It has been suggested that:
X
X        select(k,&y,0,0,&v)
X
X    should be replaced with:
X
X        select(k,&y,0,0,(v.tv_usec=1<<whatever_you_want,&v))
X
X    where whatever_you_want is some integer such as 17 or 19.
X
X    WARNING:
X
X    If you are running SunOS 4.1.x (assuming you can find an ANSI
X    compiler in the first place), this program may be used to log
X    out very quickly.  Unfortunately, you can't do anything else
X    with it.
X
X    Some people may want to slow down the game by increasing the
X    value 17 in the line:
X
X        struct timeval v= {0,1<<17} ;
X
X    to something like 18 or 19.
X
X    One may also need to do a "stty sane" if you kill the program
X    to restore your terminal state.
X
X    Some people report that rince dumps core on their system.
X
X    On some systems that use gcc, the curses.h used by gcc
X    (typically /usr/local/include/curses.h) is not compatible with
X    the curses library (typically /lib/libcurses.a) used.  It has
X    been suggested that the following gcc command may help:
X
X        gcc -fno-builtin -I/usr/include -o rince rince.c -lcurses -ltermcap
X
X
XSelected notes from the author:
X
X    This is a Cellular Automata Based, Beautifully Abysmal Game Environment (or
X    CABBAGE for short). To execute the program simply type 'jkb gamefile',
X    where `gamefile' is a game description file. A couple are supplied for
X    your enjoyment. Alternatively, with no arguments it will default to using
X    it's own datafile (the source code infact). This happens to be a game of
X    space invaders. To prevent people from firing too often a very simple
X    method is employed; you must move after firing to be able to fire again.
X
X    Keys are:   Left  :    j
X            Right :    l
X            Fire  :    k
X
X    This is a new breed of generic games. For instance:
X    Game play   : Whatever you define
X    Keys        : Whatever you define
X    Score       : If you can figure out how to update it!
X    Levels      : Ahh well... it's not *totally* generic.
X
X    The proper definition for usage would be:
X    jkb [data_filename]
X
X    Portability
X    -----------
X
X    I have compiled in on the following systems:
X
X    System              OS              Compiler
X    -------------------------------------------------------------------------
X    DECstation 5000/240 Ultrix 4.2A     c89 -std
X    SPARCstation 1+     SunOS 4.1       gcc -ansi -pedantic
X    SPARCstation 10/31  Solaris 2.1     gcc -ansi -pedantic     (*)
X    DECAlpha 3000/500   OSF/1 V1.2      c89 -std
X    SGI Indigo (R4000)  IRIX 4.0.5F     cc -ansi
X    Alliant FX2800      Conentrix 3.0.0 fxc
X
X    (*) I never said it worked! The guidelines state that you dislike programs
X        that won't *compile* under both BSD or SYS V Un*x. This compiles, and
X        indeed runs on all the others (both BSD and SYS V) correctly.
X
X    Alas, on Solaris it compiles, but mysteriously stops displaying output
X    after a while until you quit with control C, when it all catches up again.
X    I think the problem may lie in either select(), or curses, (or perhaps
X    conflict of the two).
X
X    The use of select() no doubt makes it less portable to STRICT system V
X    machines. However I have tested this on several so-called system V
X    machines, and all of them support select(). In fact, the select() they
X    support appears to be more portable between them than their poll() call.
X
X    Obfuscation details
X    -------------------
X
X    I have tried to use as many different obfuscation techniques, including
X    some of which (such as sizeof confusion) I have not seen in any winners
X    (hmmm - perhaps there's a reason for that...) so far. Also, very poor
X    structure (yes, I use goto's) has lead to apparently having an fgets() as
X    the last line of main. Note that I have still tried to aim at least some
X    efficiency (provided it makes things slightly more obfuscated of course).
X    One such thing is the way I dynamically allocate a 2-dimensional array
X    using only ONE malloc(). Hence this program could be used as a tutorial
X    for all those people who consistently ask this question in the C
X    newsgroups.
X
X    Also, the program does require a volatile type (especially when
X    optimising) to perform correctly. This is the first time I have ever
X    truly needed this when not accessing memory external to this process :-)
X
X    Of course, all the usual obfuscation lurks within, such as combining
X    multiple for loops into single ones; warped and twisted logic; plus a
X    plethora of other minor oddities. It's up to you to discover some of them
X    of course... Sometimes I have sacrificed length for obfuscation. It is all
X    too easy to change the arguments in main to one character identifiers, but
X    in my opinion they add to obfuscation in this case by being longer.
X
X    Lint complains about lots of things. Firstly the use of curses immediately
X    makes lint complain. The Alpha's lint gave me some positive encouragement!
X    'precedence confusion possible: parenthesize!' :-) :-)
X    main() does not return correctly, because, basically, it doesn't return.
X
X    Bugs
X    ----
X
X    Very little error checking is performed. I do check for not being able to
X    open the requested filename and return 1 upon failure. However, badly
X    formatted data files will cause major problems. No other checking (such as
X    insufficient memory) is performed.
X
X    There is no 'end of game' checking method. Hence games like sokoban rely
X    on the user to decide when they have had enough. Also, there is no quit
X    mechanism other than control C.
END_OF_FILE
  if test 6839 -ne `wc -c <'1993/rince.hint'`; then
    echo shar: \"'1993/rince.hint'\" unpacked with wrong size!
  fi
  # end of '1993/rince.hint'
fi
if test -f '1993/rules' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'1993/rules'\"
else
  echo shar: Extracting \"'1993/rules'\" \(9010 characters\)
  sed "s/^X//" >'1993/rules' <<'END_OF_FILE'
X10th International Obfuscated C Code Contest Rules
X
XCopyright (c) Landon Curt Noll & Larry Bassel, 1993.
XAll Rights Reserved.  Permission for personal, educational or non-profit use is
Xgranted provided this this copyright and notice are included in its entirety
Xand remains unaltered.  All other uses must receive prior permission in writing
Xfrom both Landon Curt Noll and Larry Bassel.
X
X    Obfuscate:  tr.v.  -cated, -cating, -cates.  1. a.  To render obscure.
X        b.  To darken.  2. To confuse:  his emotions obfuscated his
X        judgment.  [LLat. obfuscare, to darken : ob(intensive) +
X        Lat. fuscare, to darken < fuscus, dark.] -obfuscation n.
X        obfuscatory adj.
X
X
XGOALS OF THE CONTEST:
X
X    * To write the most Obscure/Obfuscated C program under the rules below.
X    * To show the importance of programming style, in an ironic way.
X    * To stress C compilers with unusual code.
X    * To illustrate some of the subtleties of the C language.
X    * To provide a safe forum for poor C code.  :-)
X
X
XNOTE: Changes from the 1993 draft are noted by change bars.  --->          |
X
X
XRULES:
X
X    To help us with the volume of entries, we ask that you follow these rules:
X
X    1) Your entry must be a complete program.
X
X    2) Your entry must be <= 3217 bytes in length.  The number of characters
X       excluding whitespace (tab, space, newline), and excluding any ; { or }
X       followed by either whitespace or end of file, must be <= 1536.
X
X    3) Your entry must be submitted in the following format:
X
X---entry---
Xrule:    1993
Xfix:    y or n   (n => this is a new entry, y => this replaces an older entry)
Xtitle:    title of entry              (see comments below)
Xentry:    Entry number from 0 to 7 inclusive  (your 1st entry should by 0)
Xdate:    Date/time of submission in UTC        (see comments below)
Xhost:    Machine(s) and OS(s) under which your entry was tested
X    Use tab indented lines if needed
X---remark---
X    Place remarks about this entry in this section.  It would be helpful if
X    you were to indent your remarks with 4 spaces, though it is not a
X    requirement.  Also, if possible, try to avoid going beyond the 79th
X    column.  Blank lines are permitted.
X---author---
Xname:    your name
Xorg:    School/Company/Organization
Xaddr:    postal address
X    use tab indented lines to continue
X    don't forget to include the country
Xemail:  Email address from a well known site or registered domain.
X        If you give several forms, list them on separate tab indented lines.
Xanon:    y or n   (y => remain anonymous, n => ok to publish this info)
X---info---
XIf your program needs an info file, place a uuencoded copy of it in
Xthis section.  In the case of multiple info files, use multiple info
Xsections.  If your entry does not need a info file, skip this section.
X---build---
XPlace a uuencoded copy of the command(s) used to compile/build your program
Xin this section.  It must uudecode into a file named 'build'.  The resulting
Xfile must be 255 bytes or less.
X---program---
XPlace a uuencoded copy of your program in this section.  It must uudecode
Xinto a file named is 'prog.c'.  The resulting file must follow rule #2.
X---end---
X
X      Regarding the above format:
X
X    * The title must match the expression: [a-zA-Z0-9_=][a-zA-Z0-9_=+-]*
X      and must be 1 to 12 characters in length.
X
X      It is suggested, but not required, that the title should
X      incorporate your username; in the case of multiple authors,
X      consider using parts of the usernames of the authors.
X
X    * The date in the ---entry--- section should be given with respect
X      to UTC.  The format of the date should be as returned by asctime()
X      using the C locale.  (see guidelines for more info)
X
X    * You may correct/revise a previously submitted entry by sending
X      it to the contest email address.  Be sure to set 'fix' in the
X      ---entry--- section to 'n'.  The corrected entry must use the same
X      title and entry number as submittion that is being corrected.  Be
X      sure that you note the resubmittion in the ---remark--- as well.
X
X    * With the exception of the header, all text outside of the above
X      format may be ignored by the judges.  If you need tell the judges
X      something, put it in the ---remark--- section, or send a separate
X      Email message to the judges.
X
X    * Information from the ---author--- section will be published unless
X      'y' was given to the respective author's 'anon' line.
X
X    * To credit multiple authors, include an ---author--- section for
X      each author.  Each should start with ---author--- line, and
X      should be found between the ---entry--- and ---build--- sections.
X
X    * The entry's remarks should include:
X        - what this program does
X        - how to run the program (sample args or input)
X        - special compile or execution instructions, if any
X        - special filename requirements (see rule 4 and 5)
X        - information about any ---data--- files
X        - why you think the program is obfuscated
X        - note if this entry is a re-submission of a previous entry.
X        - any other remarks (humorous or otherwise)
X
X    * Do not rot13 your entry's remarks.  You may suggest that certain
X      portions of your remarks be rot13ed if your entry wins an award.
X
X        * Info files should be used only to supplement your entry.  They
X      should not be required to exist.
X
X      If your entry does not need an info file, skip the ---info---
X      section.  If your entry needs multiple info files, use multiple
X      ---info--- sections, one per info file.  You should describe
X      each info file in the ---remark--- section.
X
X    4) If your entry is selected as a winner, it will be modified as follows:
X
X       'build' is incorporated into a makefile, and 'build' is removed
X       'prog.c' is renamed to your entry's title, followed by an optional
X           digit, followed by '.c'
X       your entry is compiled into a file with the name of your entry's
X           title, possibly followed by a digit
X
X       If your entry requires that a build file exist, state so in your
X       entry's remark section.  The makefile will be arranged to execute a
X       build shell script containing the 'build' information.  The name of
X       this build shell script will be your entry's title, possibly followed
X       by a digit, followed by '.sh'.
X
X       If needed, your entry's remarks should indicate how your entry must
X       be changed in order to deal with the new filenames.
X
X    5) The build file, the source and the resulting executable should be
X       treated as read-only files.  If your entry needs to modify these files,
X       it should make and modify a copy of the appropriate file.  If this
X       occurs, state so in your entry's remarks.
X
X    6) Entries that cannot be compiled by an ANSI C compiler will be rejected.
X       Use of common C (K&R + extensions) is permitted, as long as it does not
X       cause compile errors for ANSI C compilers.
X
X    7) The program must be of original work.  All programs must be in the
X       public domain.  All copyrighted programs will be rejected.
X
X    8) Entries must be received prior to 07-May-93 0:00 UTC.  (UTC is
X       essentially equivalent to Greenwich Mean Time)  Email your entries to:
X
X        ...!{apple,pyramid,sun,uunet}!hoptoad!obfuscate
X        [e-mail]
X
X       We request that your message use the subject 'ioccc entry'.
X
X       If possible, we request that you hold off on Emailing your entries
X       until 1-Mar-93 0:00 UTC.  Early entries will be accepted, however.
X       We will attempt to email a confirmation to the the first author for
X       all entries received after 1-Mar-93 0:00 UTC.
X
X    9) Each person may submit up to 8 entries per contest year.  Each entry
X       must be sent in a separate Email letter.
X
X   10) Entries requiring human interaction to be built are not allowed.
X       Compiling an entry (must) produce a file (or files) which may           |
X       be executed.                                  |
X
X   11) Programs that require special privileges (setuid, setgid, super-user,
X       special owner or group) are not allowed.
X
X
XFOR MORE INFORMATION:
X
X    The Judging will be done by Landon Noll and Larry Bassel.  Please send
X    questions or comments about the contest, to:
X
X    ...!{apple,pyramid,sun,uunet}!hoptoad!judges    (not the address for  |
X    [e-mail]                     submitting entries)  |
X
X    The rules and the guidelines may (and often do) change from year to
X    year.  You should be sure you have the current rules and guidelines
X    prior to submitting entries.  To obtain them, send Email to the address   |
X    above and use the subject 'send rules'.                      |
X
X    One may obtain winners of previous contests (1984 to date), via ftp from: |
X
X    host: ftp.uu.net    (192.48.96.9)                      |
X    user: anonymous
X    pass: yourname@yourhost
X    dir:  ~/pub/ioccc                              |
X
X    As a last resort, previous winners may be obtained by sending Email       |
X    to the above address.  Please use the subject 'send YEAR winners',        |
X    where YEAR is a single 4 digit year, a year range, or 'all'.          |
X
X
Xchongo <Landon Curt Noll> /\cc/\      [e-mail]                  |
XLarry Bassel                  [e-mail]                  |
END_OF_FILE
  if test 9010 -ne `wc -c <'1993/rules'`; then
    echo shar: \"'1993/rules'\" unpacked with wrong size!
  fi
  # end of '1993/rules'
fi
if test -f '1993/vanb.hint' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'1993/vanb.hint'\"
else
  echo shar: Extracting \"'1993/vanb.hint'\" \(5857 characters\)
  sed "s/^X//" >'1993/vanb.hint' <<'END_OF_FILE'
XMost Irregular Expression: <[e-mail]> David Van Brackle
X
X    David Van Brackle
X    ISX Corporation
X    1165 Northchase Parkway, Suite 120
X    Marietta, GA  30067
X    USA
X
X
XJudges' comments:
X
X    To run:
X    make vanb
X    ./vanb 'exp'
X
X    where:
X    'exp'    an octal expression
X
X    The octal expression may contain:
X
X    unary operators:    +, -
X    binary operators    +, -, *, /, %
X    hex numbers:        x or X follow by hex digits
X    decimal numbers:    d or D follow by decimal digits
X    octal numbers:        octal digits
X    grouping:        ()
X
X    No spaces are allowed in the expression.  To avoid shell expansion,
X    one should surround the expression in single quotes.
X
X    It is a good thing that this program consists of only one
X    expression, otherwise it might become hard to understand.  :-)
X
X
XSelected notes from the author:
X
X    The program does no error checking - erroneous expressions will
X    produce spurious results. Note that unary '-' is an operator. Thus,
X    decimal -46 would be entered as -d46 and not d-46.
X
X    What Makes This Program Special:
X
X    0) Of course, the fact that the program takes input and produces output
X       in octal, rather than a more useful system like decimal, makes
X       it "special".
X
X    1) The entire program consists of a single expression, returned from main.
X
X    2) There are no global or local variables other than the parameters
X       to main
X
X    3) All of the constants in the program are expressed in octal - including
X       the printf string.
X
X    4) The variables are given names which cause visual confusion with the
X       octal constants.
X
X    5) The program is formatted like a roman numeral 8. The significance of
X       8 is obvious. I chose roman numerals because it is a numbering
X       system even more arcane than octal. It's not very 'deceptive',
X       but it's difficult to deceptively format a program which has no
X       explicit control structures (other than ?:'s).
X
X    6) Many simple tasks are done many times. I tried to do these differently
X       each time, to make the program harder to understand.
X
X    How It Works:
X
X    It's a recursive descent parser, calling main
X    for all of its recursion. O2 is a state variable, telling main
X    what grammar non-terminal to parse. **O7 is the next character.
X    O3 is an intermediate result. Whenever you see a construct like:
X
X      !(expression with O2)?
X
X    it's decrementing & testing O2 to see what state it's in. Comparisons
X    involving **O7 and octal constants are looking for certain characters.
X
X    Here's the grammar ('e' denotes the empty string) :
X
X    <E>  ::=  <T><E'>
X    <E'> ::=  +<T><E'> | -<T><E'> | e
X    <T>  ::=  <F><T'>
X    <T'> ::=  *<F><T'> | /<F><T'> | %<F><T'> | e
X    <F>  ::=  +<F> | -<F> | (<E><C> | d<D> | D<D> |  x<X> | X<X> | <O>
X    <C>  ::=  )
X    <D>  ::=  [0-9]<D> | e
X    <X>  ::=  [0-9]<X> | [A-F]<X> | [a-f]<X> | e
X    <O>  ::=  [0-7]<O> | e
X
X    Here's how the grammar nonterminals map to octal state numbers:
X
X    <E>  is  012
X    <E'> is  011
X    <T>  is  010
X    <T'> is   07
X    <F>  is   06
X    <C>  is  013
X    <D>  is   04
X    <X>  is   05
X    <O>  is   03
X
X    Here's a version of the program before it got formatted into the VIII,
X    augmented with comments showing where each state begins. N1 and N2 are
X    notes:
X
X    #define O5 main
X    O5(O2,O7,O3)char**O7;
X    {
X             return
X    /* N1 */ !(O2+=~01+01) ?
X              00:
X    /* N2 */ !(O2-=02>01) ?
X              printf("\045\157\012",O5(012,O7+01,00)):
X    /* O  */ !(O2-=02>>01) ?
X                  (**O7<=067 && **O7>057 ? O5(03,O7,*(*O7)++-060+010*O3):O3):
X    /* D  */ !(O2-=-O3-~O3) ?
X                  (072>**O7 && 060<=**O7 ? O5(04,O7,012*O3-060+*(*O7)++):O3):
X    /* X  */ !(O2-=!O3+!!O3) ?
X                  (**O7>057 && **O7<=071 ? O5(05,O7,*(*O7)+++O3*020-060):
X                  **O7<=0106 && 0101<=**O7 ? O5(05,O7,020*O3+*(*O7)++-067):
X                  0140<**O7 && **O7<0147 ? O5(05,O7,-0127+*(*O7)+++020*O3):O3):
X    /* F  */ !(O2-=02-01) ?
X                  (**O7==050 ? 050**++*O7,O5(013,O7,O5(012,O7,00)):
X                  **O7<056 && 054<**O7 ? 055**++*O7,-O5(06,O7,00):
X                  054>**O7 && 052<**O7 ? 050**(*O7)++,O5(06,O7,00):
X                  !(**O7^0170)||!(0130^**O7) ? *++*O7,O5(05,O7,00):
X                  **O7==0144||**O7==0104 ? ++*O7,O5(04,O7,00):O5(03,O7,00)):
X    /* T' */ !--O2 ?
X              (**O7==052 ? O5(07,O7,O3*(*++*O7,O5(06,O7,00))):
X                  !(045-**O7) ? O5(07,O7,O3%(03+(*O7)++,O5(06,O7,00))):
X                  !(**O7^057) ? O5(07,O7,O3/(03-*++*O7,O5(06,O7,00))):O3):
X    /* T  */ !(O2+=01-02) ?
X              O5(07,O7,O5(06,O7,00)):
X    /* E' */ !(O2+=-02/02) ?
X              (!(**O7-053)?O5(011,O7,O3+(++*O7,O5(010,O7,00))):
X                  !(055^**O7) ? O5(011,O7,O3-(03+*(*O7)++,O5(010,O7,00))):O3):
X    /* E  */ !(O2-=0563&0215) ?
X              O5(011,O7,O5(010,O7,00)):
X    /* C  */ (++*O7,O3);
X    }
X
X    Note N1: It should never enter this state, unless the user invokes the
X         program with no parameters, in which case it just returns 0.
X
X    Note N2: Since the program is properly invoked with 1 parameter, this is
X         the first state it will go into. This state just invokes
X         printf, and sends the parser to state 012 (which is <E>).
X
X    The E and T states work like this:
X
X    int e(){ return eprime( t() ); }
X
X    The E' and T' states work like this:
X
X    int eprime( int intermediate )
X    {
X    if( ch == '+' )
X    {
X        ch = nextchar();
X        return eprime( intermediate + t() );
X    }
X    else return intermediate;
X    }
X
X    The D, X and O states work like this (they assume that they're initially
X    called with 0):
X
X    int octal( int intermediate )
X    {
X    if( ch>='0' && ch<='7' )
X    {
X        intermediate = intermediate * 8 + ch - '0';
X        ch = nextchar();
X        return octal( intermediate );
X    }
X    else return intermediate;
X    }
X
X    F and C work similarly.
END_OF_FILE
  if test 5857 -ne `wc -c <'1993/vanb.hint'`; then
    echo shar: \"'1993/vanb.hint'\" unpacked with wrong size!
  fi
  # end of '1993/vanb.hint'
fi
echo shar: End of archive 2 \(of 4\).
cp /dev/null ark2isdone
MISSING=""
for I in 1 2 3 4 ; do
    if test ! -f ark${I}isdone ; then
    MISSING="${MISSING} ${I}"
    fi
done
if test "${MISSING}" = "" ; then
    echo You have unpacked all 4 archives.
    rm -f ark[1-9]isdone
else
    echo You still must unpack the following archives:
    echo "        " ${MISSING}
fi
exit 0
exit 0 # Just in case...