guidelin

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

	[e-mail]
anon:	n
---info---
begin 444 info.file
M0V]P>7)I9VAT("AC*2!,86YD;VX@0W5R="!.;VQL+"`Q.3DS+@I!;&P@4FEG
M:'1S(%)E<V5R=F5D+B`@4&5R;6ES<VEO;B!F;W(@<&5R<V]N86PL(&5D=6-A
M=&EO;B!O<B!N;VXM<')O9FET('5S92!I<PIG<F%N=&5D('!R;W9I9&5D('1H
M:7,@=&AI<R!C;W!Y<FEG:'0@86YD(&YO=&EC92!A<F4@:6YC;'5D960@:6X@
M:71S(&5N=&ER971Y"F%N9"!R96UA:6YS('5N86QT97)E9"X@($%L;"!O=&AE
M<B!U<V5S(&UU<W0@<F5C96EV92!P<FEO<B!P97)M:7-S:6]N(&EN('=R:71I
M;F<*9G)O;2!,86YD;VX@0W5R="!.;VQL+@H*5&AA="!T:&%T(&ES+"!I<RX*
M5&AA="!T:&%T(&ES(&YO="P*("`@(&ES(&YO="!T:&%T('1H870@;F]T(&ES
M+@I4:&%T(&ES+"!T:&%T('1H870@:7,@;F]T+"!I<R$*"@D)+2T@8VAO;F=O
M(#$Y-S0*"DQA<W0@>65A<BP@;VYE('!E<G-O;B!T;VQD('5S('1H870@=&AE
M>2!A8W1U86QL>2!D96-O9&5D('1H:7,@9FEL92X*22!W;VYD97(@:&]W(&UA
9;GD@=VEL;"!D;R!I="!T:&ES('EE87(_"@``
`
end
---build---
begin 444 build
28V,@<')O9RYC("UO('!R;V<*
`
end
---program---
begin 444 prog.c
M;6%I;B@I"GL*(VEF(&1E9FEN960H05]214=)4U1%4D5$7U9/5$527TE.7U-5
M3DY95D%,15]#04Q)1D]23DE!7U5302D*("`@('!R:6YT9B@B5F]T92!,86YD
M;VX@3F]L;"!F;W(@4W5N;GEV86QE($-I='D@0V]U;F-I;"!S96%T(",Q+EQN
:(BD["B-E;F1I9@H@("`@97AI="@P*3L*?0H`
`
end
---end---

    Typically the build file should assume that the source is prog.c
    and will compile into prog.  If an entry wins, we will rename
    its source and binary to avoid filename collision.  By tradition,
    we use the name of the entry's title, followed by an optional
    digit in case of name conflicts.

    If the above entry somehow won the 'least likely to win' award,
    we would use chonglab.c and chonglab.

    If your entry depends on, or requires that your build, source
    and/or binary files be a particular name, please say so in the
    ---remark--- section.  If this case applies, it would be be helpful
    if you did one of the following:

	* Tell us how to change the filename(s) in your entry.

	* Have the build file make copies of the files.  For example:

		cc prog.c -o special_name		need special binary

	    or  rm -f special_src.c			need special source
		cp prog.c special_src.c
		cc special_src.c -o special_name

	    or  rm -f special_build			need special build
		tail +4 build > special_build
		sh < special_build

	* Assume that we will use the entry title.  Send us a version of
	  your build/program files that uses the name convention.  You
	  should uuencode these files in ---data--- sections.

    If your entry needs to modify its source, info or binary files,
    please say so in the ---remark--- section.  You should try to avoid
    touching your original build, source and binary files.  You should
    arrange to make copies of the files you intend to modify.  This
    will allow people to re-generate your entry from scratch.

    Remember that your entry may be built without a build file.  We
    typically incorporate the build lines into a Makefile.  If the
    build file must exist, say so in the ---remark--- section.

    If your entry needs special info files, you should uuencode them
    into ---info--- sections.  In the case of multiple info files,
    use multiple ---info--- sections.  If no info files are needed,
    then skip the ---info--- section.

    Info files are intended to be input, or detailed information that
    does not fit well into the ---remark--- section.  For example, an
    entry that implements a compiler might want to provide some sample
    programs for the user to compile.  An entry might want to include a
    lengthy design document, that might not be appropriate for a
    'hints' file.

    Info files should be used only to supplement your entry.  For
    example, info files may provide sample input or detailed
    information about your entry.  Because they are supplemental,
    the entry should not require them exist.

    In some cases, your info files might be renamed to avoid name
    conflicts.  If info files should not be renamed for some reason,
    say so in the ---remark--- section.

    Info files must uudecode into the current directory.  If they
    absolutely must be renamed, or moved into a sub-directory, say
    so in the ---remark--- section.

    When submitting multiple entries, be sure that each entry has
    a unique entry number from 0 to 7.  Your first entry should
    have entry number 0.

    With the exception of the header, all text outside of the entry
    format may be ignored.  That is, don't place text outside of the
    entry and expect the judges to see it.  (Our decoding tools aren't
    AI progs!) If you need tell the the something, put it in the
    ---remark--- section, or send a Email to the judges at:

	...!{apple,pyramid,sun,uunet}!hoptoad!judges	(not the address for
	[e-mail]					 submitting entries)

    The date should be given with respect to UTC.  (Some systems refer
    to this as GMT or GMT0)  The format of the date should be that as
    returned by asctime() in the C locale.  An example of such a string is:

	Thr Apr 01 00:47:00 1993

    This format is similar to the output of the date(1) command.  The
    string does not include the timezone name before the year.  On many
    systems, one of the following command will produce a similar string:

	date -u "+%a %h %d %T 19%y"
	date -u | sed -e 's/... \(19[0-9][0-9]\)$/\1/'
	sh -c 'TZ=UTC date | sed -e "s/... \(19[0-9][0-9]\)$/\1/"'
	sh -c 'TZ=GMT date | sed -e "s/... \(19[0-9][0-9]\)$/\1/"'
	sh -c 'TZ=GMT0 date | sed -e "s/... \(19[0-9][0-9]\)$/\1/"'

    You are allowed to update/fix/revise your entry.  To do so, set
    the 'fix' line in the ---entry--- section to 'y' instead of 'n'.
    Be sure that the resubmittion uses the same title and entry number
    as well, as these are used to determine which entry is to be
    replaced.


JUDGING PROCESS:

    Entries are judged by Larry Bassel and Landon Curt Noll.

    Entries are unpacked into individual directories.  The Email message
    is unpacked into individual files, each containing:

	---entry--- section
	all ---author--- sections
	all ---info--- sections
	---build--- section
	---program--- section
	any other text, including the Email message headers

    Prior to judging, the 'any other text' file is scanned to be sure
    it does not contain useful information (or in case the entry was
    malformed and did not unpack correctly).  Information from the
    ---author--- sections are not read until the judging process is
    complete, and then only from entries that have won an award.

    The above process helps keep us biased for/against any one particular
    individual.  We are usually kept in the dark as much as you are
    until the final awards are given.  We like the surprise of finding
    out in the end, who won and where they were from.

    We attempt to keep all entries anonymous, unless they win an award.
    Because the main 'prize' of winning is being announced, we make all
    attempts to send non-winners into oblivion.  We remove all non-winning
    files, and shred all related paper.  By tradition, we do not even
    reveal the number of entries that we received.  (for the curious,
    we do indicate the volume of paper consumed when presenting the IOCCC
    winners at talks)

    After the Usenix announcement, we attempt to send Email to the
    authors of the winning entries.  One reason we do this is to give
    the authors a chance to comment on the way we have presented their
    entry.  They are given the chance to correct mistakes, typos.  We
    often accept their suggestions/comments about our remarks as well.
    This is done prior to posting the winners to the wide world.

    Judging consists of a number of elimination rounds.  During a round,
    the collection of entries are divided into two roughly equal piles;
    the pile that advances on to the next round, and the pile that does
    not.  We also re-examine the entries that were eliminated in the
    previous round.  Thus, an entry gets at least two readings.

    A reading consists of a number of actions:

	* reading the ---entry--- section
	* reading the uudecoded ---build--- section
	* reading the uudecoded ---program--- section
	* reading the uudecoded ---info--- section(s), if any
	* passing the source thru the C pre-processor
	    shipping over any #include files
	* performing a number of C beautify/cleanup edits on the source
	* passing the beautified source thru the C pre-processor
	    shipping over any #include files

    In later rounds, other actions are performed:

	* linting the source
	* compiling/building the source
	* running the program
	* performing misc tests on the source and binary

    Until we reduce the stack of entries down to about 25 entries, entries
    are judged on an individual basis.  An entry is set aside because it
    does not, in our opinion, meet the standard established by the round.
    When the number of entries thins to about 25 entries, we begin to form
    award categories.  Entries begin to compete with each other for awards.
    An entry often will compete in several categories.

    The actual award category list will vary depending on the types of entries
    we receive.  A typical category list might be:

	* best small one line program
	* best small program
	* strangest/most creative source layout
	* most useful obfuscated program
	* best game that is obfuscated
	* most creatively obfuscated program
	* most deceptive C code
	* best X client (see OUR LIKES AND DISLIKES)
	* best abuse of ANSI C
	* worst abuse of the rules
	* <anything else so strange that it deserves an award>

    We do not limit ourselves to this list.  For example, a few entries are so
    good/bad that they are declared winners at the start of the final round.
    We will invent awards categories for them, if necessary.

    In the final round process, we perform the difficult tasks of
    reducing the remaining entries (typically about 25) down to 8 or 10
    winners.  Often we are confident that the entries that make it into
    the final round are definitely better than the ones that do not
    make it.  The selection of the winners out of the final round, is
    less clear cut.

    Sometimes a final round entry good enough to win, but is beat out
    by a similar, but slightly better entry.  For this reason, it is
    sometimes worthwhile to re-enter an improved version of an entry
    that failed to win in a previous year.  This assumes, of course,
    that the entry is worth improving in the first place!

    More often that not, we select a small entry (usually one line), a
    strange/creative layout entry, and an entry that abuses the contest
    rules in some way.

    In the end, we traditionally pick one entry as 'best'.  Sometimes such
    an entry simply far exceeds any of the other entry.  More often, the
    'best' is picked because it does well in a number of categories.


ANNOUNCEMENT OF WINNERS:

    The first announcement, occurs at a Summer Usenix conference.  By tradition,
    this is done during the latter part of the UUNET/IOCCC BOF, just prior to
    the Berkeley BSD, and BSDI BOF.

    Winning entries will be posted in late June to the following groups:

	    comp.lang.c		  comp.unix.wizards	alt.sources

    In addition, pointers to these postings are posted to the following

	    comp.sources.d	  alt.sources.d		misc.misc
	    comp.sources.misc	  comp.windows.x

    Winning entries will be deposited into the uunet archives.  See
    below for details.

    Often, winning entries are published in selected magazines.  Winners
    have appeared in books ("The New Hackers Dictionary") and on T-Shirts.

    Last, but not least, winners receive international fame and flames!  :-)


FOR MORE INFORMATION:

    You may contact the judges by sending Email to the following address:

	...!{apple,pyramid,sun,uunet}!hoptoad!judges	(not the address for
	[e-mail]					 submitting entries)

    Questions and comments about the contest are welcome.

    The rules and the guidelines may (and often do) change from year to	      |
    year.  You should be sure you have the current rules and guidelines	      |
    prior to submitting entries.  To obtain them, send Email to the address   |
    above and use the subject 'send rules'.				      |

    One may obtain winners of previous contests (1984 to date), via ftp from: |

	host: ftp.uu.net	(192.48.96.9)				      |
	user: anonymous
	pass: yourname@yourhost
	dir:  ~/pub/ioccc						      |

    As a last resort, previous winners may be obtained by sending Email	      |
    to the above address.  Please use the subject 'send YEAR winners',	      |
    where YEAR is a single 4 digit year, a year range, or 'all'.	      |


chongo <Landon Curt Noll> /\cc/\  	[e-mail]			      |
Larry Bassel			  	[e-mail]			      |