guidelin

1984-1993模糊 C 源代码竞赛.zip 非常的好,不过这是DOS格式,要用UE去打开.

9th International Obfuscated C Code Contest Guidelines, Hints and Comments

Copyright (c) 1992, Landon Curt Noll & Larry Bassel.
All Rights Reserved.  Permission for personal, education 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.


ABOUT THIS FILE:

    This file is intended to help people who wish to submit entries to
    the International Obfuscated C Code Contest (IOCCC for short).

    This is not the IOCCC rules, though it does contain comments about
    them.  The guidelines should be viewed as hints and suggestions.
    Entries that violate the guidelines but remain within the rules are
    allowed.  Even so, you are safer if you remain within the guidelines.

    You should read the current IOCCC rules, prior to submitting entries.
    The rules are typically sent out with these guidelines.


WHAT IS NEW IN 1992:

    The size rules are different this year.  There is a more relaxed
    rule to encourage formatting styles beyond rectangular blobs of C
    code.  The build file (how to compile) has been expanded as well.
    See the rules, and OUR LIKES AND DISLIKES for details.

    The entry format is better (for us anyway).  The program mkentry.c
    provides a convenient way to form an entry.  See ENTRY FORMAT.

    The original entry source, build and resulting binary should be
    treated as read-only.  There is a provision to allow entries to
    modify these files indirectly.  See ENTRY FORMAT.

    This year, we are experimenting with a new category of programs:
    X clients.  X client entries should be as portable as possible.
    See OUR LIKES AND DISLIKES.


HINTS AND SUGGESTIONS:

    You are encouraged to examine the winners of previous contests.  See
    FOR MORE INFORMATION for details on how to get previous winners.

    Keep in mind that rules change from year to year, so some winning entries
    may not be valid entries this year.  What was unique and novel one year
    might be 'old' the next year.

    An entry is usually examined in a number of ways.  We typically apply
    a number of tests to an entry:

	* look at the original source
	* If it is ANSI, convert tri-graphs to ASCII
	* C pre-process the source ignoring '#include' lines
	* C pre-process the source ignoring '#define' and '#include' lines
	* run it through a C beautifier
	* examine the algorithm
	* lint it
	* compile it
	* execute it

    You should consider how your entry looks in each of the above tests.
    You should ask yourself if your entry remains obscure after it has been
    'cleaned up' by the C pre-processor and a C beautifier.

    Your entry need not do well under all, or in most tests.  In certain
    cases, a test is not important.  Entries that compete for the
    'strangest/most creative source layout' need not do as well as
    others in terms of their algorithm.  On the other hand, given
    two such entries, we are more inclined to pick the entry that
    does something interesting when you run it.

    We try to avoid limiting creativity in our rules.  As such, we leave
    the contest open for creative rule interpretation.  As in real life
    programming, interpreting a requirements document or a customer request
    is important.  For this reason, we often award 'worst abuse of the
    rules' to an entry that illustrates this point in an ironic way.

    If you do plan to abuse the rules, we suggest that you let us know
    in the remarks section.  Please note that an invitation to abuse
    is not an invitation to break.  We are strict when it comes to the
    3217 byte size limit.  Also, abusing the entry format tends to
    annoy more than amuse.

    We do realize that there are holes in the rules, and invite entries
    to attempt to exploit them.  We will award 'worst abuse of the rules'
    and then plug the hole next year.  Even so, we will attempt to use
    the smallest plug needed, if not smaller.  :-)

    Check out your program and be sure that it works.  We sometimes make
    the effort to debug an entry that has a slight problem, particularly
    in or near the final round.  On the other hand, we have seen some
    of the best entries fall down because they didn't work.

    We tend to look down on a prime number printer, that claims that
    16 is a prime number.  If you do have a bug, you are better off
    documenting it.  Noting "this entry sometimes prints the 4th power
    of a prime by mistake" would save the above entry.  And sometimes,
    a strange bug/feature can even help the entry!  Of course, a correctly
    working entry is best.


OUR LIKES AND DISLIKES:

    Doing masses of #defines to obscure the source has become 'old'.  We
    tend to 'see thru' masses of #defines due to our pre-processor tests
    that we apply.  Simply abusing #defines or -Dfoo=bar won't go as far
    as a program that is more well rounded in confusion.

    Many ANSI C compilers dislike the following code, and so do we:

	#define d define
	#d foo		   <-- don't expect this to turn into #define foo

	int i;
	j;		   <-- don't use such implicit type declarations
	int k;

    We suggest that you use ANSI C compilers if possible.  If you must
    use non-ANSI C, such as K&R C, try to avoid areas that give ANSI C
    compilers problems.

    Small programs are best when they are short, obscure and concise.
    While such programs are not as complex as other winners, they do
    serve a useful purpose.  They are often the only program that people
    attempt to completely understand.  For this reason, we look for
    programs that are compact, and are instructional.

    One line programs should be short one line programs, say around 80
    bytes long.  Getting close to 160 bytes is a bit too long for one liners
    in our books.

    We tend to dislike programs that:

	* are very hardware specific
	* are very OS or Un*x version specific
	     (index/strchr differences are ok, but socket/streams specific
	      code is likely not to be)
	* dump core or have compiler warnings
	     (it is ok only if you warn us in the 'remark' header item)
	* won't compile under both BSD or SYS V Un*x
	* abusing the build file to get around the size limit
	* obfuscate by excessive use of ANSI tri-graphs
	* are longer than they need to be
	* are similar to previous winners
	* are identical to previous losers  :-)

    Unless you are cramped for space, or unless you are entering the
    'best one liner' category, we suggest that you format your program
    in a more creative way than simply forming excessively long lines.

    The build file should not be used to try and get around the size
    limit.  It is one thing to make use of a several -D's to help out,
    but it is quite another to use 200+ bytes of -D's in order to
    try and squeeze the source under the size limit.  You should feel
    free to make use of the build file space, but you are better off
    if you show some amount of restraint.

    We allowed whitespace, and in certain cases ; { or } do not impact
    your program size (up to a certain point), because we want to get
    away from source that is simply a compact blob of characters.

    Given two versions of the same program, one that is a compact blob
    of code, and the other that is formatted more like a typical C
    program, we tend to favor the second version.  Of course, a third
    version of the same program that is formatted in an interesting
    and/or obfuscated way, would definitely win over the first two!

    We suggest that you avoid trying for the 'smallest self-replicating'
    program.  We are amazed at the many different sizes that claim
    to be the smallest.  There is nothing wrong with self-replicating
    programs.  In fact, a number of winners have been self-replicating.
    You might want to avoid the claim of 'smallest', lest we (or others)
    know of a smaller one!

    X client entries should be as portable as possible.  Entries that
    adapt to a wide collection of environments will be favored.  Don't
    depend on a particular type of display.  For example, don't depend
    on color or a given size.  Don't require backing store.

    X client entries should avoid using X related libraries and
    software that is not in wide spread use.  We ask that such X client
    entries restrict themselves to only the low level Xlib and the
    Athena widget set (libX11.a, libXaw.a, libXmu.a and libXt.a).
    Don't use M*tif, Xv*ew, or OpenL*ok toolkits, since not everyone
    has them.  Avoid depending on a particular window manager.  Not
    everyone has X11r5, and some people are stuck back in X11r3 (or
    earlier), so try to target X11r4 without requiring X11r4.  Better
    yet, try to make your entry run on all version 11 X Window Systems.

    X client entries should not to depend on particular items on
    .Xdefaults.  If you must do so, be sure to note the required lines
    in the ---remark--- section.  Better yet, give an xrdb -merge
    command as part of the build.

    We like programs that:

	* are as concise and small as they need to be
	* do something at least quasi-interesting
	* pass lint without complaint (not a requirement, but it is nice)
	* are portable
	* are unique or novel in their obfuscation style
	* MAKE USE OF A NUMBER OF DIFFERENT TYPES OF OBFUSCATION
	* make us laugh and/or throw up  :-)

    Some types of programs can't excel in some areas.  Of course, your
    program doesn't have to excel in all areas, but doing well in several
    areas really does help.

    We freely admit that interesting, creative or humorous comments in
    the ---remark--- section helps your chance of winning.  If you had to
    read of many twisted entries, you too would enjoy a good laugh or two.
    We think the readers of the contest winners do as well.

    Be creative!


ENTRY FORMAT:

    In order to help us process the many entries, we must request your
    assistance by formatting your entries in a certain way.  This format,
    in addition, allows us to quickly separate information about the
    author from the program itself.  (see JUDGING PROCESS)

    We have provided the program, mkentry, as an example of how to
    format entries.  You should be aware of the following warning that
    is found in mkentry.c:

	This program attempts to implement the IOCCC rules.  Every
	attempt has been made to make sure that this program produces
	an entry that conforms to the contest rules.  In all cases,
	where this program differs from the contest rules, the
	contest rules will be used.  Be sure to check with the
	contest rules before submitting an entry.

    You are not required to use mkentry.  It is convenient, however,
    as it attempts to uuencode the needed files, and attempt to check
    the entry against the size rules.

    If you have any suggestions, comments, fixes or complaints about
    the mkentry.c program, please send Email to the judges.  (see below)

    The following is a sample entry:

---entry---
rule:	1992
title:	chonglab
entry:	0
date:	Mon Feb 17 13:58:57 1992
host:	Un*x v6, pdp11/45
	2.9BSD, pdp11/70
---remark---
    This is a non-obfuscated obfuscated C program.

    It is likely not to win a prize.  But what do you expect from
    a short example!  (yes, Hello world progs have become old too)
---author---
name:	Landon Curt Noll
org:	IOCCC Judging Group
addr:	Toad Hall
	San Francisco, CA 94101
	USA
email:	[e-mail]
anon:	n
---author---
name:	Larry Bassel
org:	IOCCC Judging Group
addr:	Toad Hall
	San Francisco, CA 94101
	USA
email:	hoptoad!sun!lab