64830

神经网络昆斯林的新闻组分类2006

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, ANSI C requires array indexes to be of integral type.
X    Thus, the following classical obfuscation hacks are no longer allowed:
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