NetNews Usenet Archive 1992 #20

home *** CD-ROM | disk | FTP | other *** search

/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / c / 13350 < prev next >

Wrap

Internet Message Format | 1992-09-08 | 64.0 KB

Xref: sparky comp.lang.c:13350 comp.sources.d:1249 comp.unix.wizards:3849 alt.sources:2019 misc.misc:3274 Path: sparky!uunet!cis.ohio-state.edu!ucbvax!hoptoad!chongo From: chongo@hoptoad.uucp (Landon C. Noll) Newsgroups: comp.lang.c,comp.sources.d,comp.unix.wizards,alt.sources,misc.misc Subject: 1992 International Obfuscated C Code Contest winners, 1 of 4 Keywords: ioccc Message-ID: <34848@hoptoad.uucp> Date: 9 Sep 92 01:38:12 GMT Expires: 28 Nov 92 00:00:00 GMT Reply-To: chongo@hoptoad.UUCP (Landon C. Noll) Organization: Nebula Consultants in San Francisco Lines: 1825 Enclosed is the first of a 4 part shar file containing the winners of the 1992 International Obfuscated C Code Contest. First, we congratulate the winners for doing a fine job. Their efforts and feedback have resulted another good year for the contest. Second, the 1993 contest will not open until early March 1993. The rules are expected to be very similar to the 1992 rules, though the input format will change slightly. Please wait for the 1993 rules to be posted before submitting 1993 entries. Third, an International Obfuscated Perl contest is being considered. Larry Wall and Landon Curt Noll plan to formulate the contest rules (and a contest name) sometime this year. Watch comp.lang.perl for details. Send contest ideas (but not entries!) to chongo@toad.com. Last, we would like to make an apology to the 1992 winners and to the net for the delay in posting of these results. The poster of this article (chongo) went on vacation, held extended discussions with several of the contest winners and attempted to deal with one entry that appears to conflict with US export regulations. If you find problems with some of the contest entries, or find typos in our notes, please send ->PATCH FILES OR COMPLETE FILES<- containing the corrections to: judges@toad.com -or- ...!{sun,uunet,utzoo,pyramid}!hoptoad!judges chongo <Landon Curt Noll> /\cc/\ hoptoad!chongo Larry Bassel {uunet,ucbvax,cbosgd}|sun!lab p.s. previous winners are available on ftp.uu.net via anonymous ftp under the directory ~/pub/ioccc. Any 'patches' to the 1992 winners will be deposited there in a few months. =-= Submitted-by: chongo@toad.com (Landon Curt Noll) # # Send comments, questions, bugs to: # # judges@toad.com -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. A valid entry one year may # be rejected in a later year due to changes in the rules. The typical # start date for a contest is early March. The typical end date for a # contest is 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. # Archive-name: ioccc.1992/part01 ---- Cut Here and unpack ---- #!/bin/sh # This is ioccc.1992, a shell archive (shar 3.32) # made 09/09/1992 00:40 UTC by chongo@toad.com (Landon Curt Noll) # # Send comments, questions, bugs to: # # judges@toad.com -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. A valid entry one year may # be rejected in a later year due to changes in the rules. The typical # start date for a contest is early March. The typical end date for a # contest is 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. # # Source directory /u4/chongo/bench/ioccc # # existing files WILL be overwritten # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 3693 -r--r--r-- 1992/README # 7451 -r--r--r-- 1992/rules # 22215 -r--r--r-- 1992/guidelines # 5632 -r--r--r-- 1992/Makefile # 2583 -r--r--r-- 1992/adrian.c # 131 -r--r--r-- 1992/adrian.grep.1 # 64 -r--r--r-- 1992/adrian.grep.2 # 99 -r--r--r-- 1992/adrian.grep.3 # 48 -r--r--r-- 1992/adrian.grep.4 # 60 -r--r--r-- 1992/adrian.grep.5 # 92 -r--r--r-- 1992/adrian.grep.from # 101 -r--r--r-- 1992/adrian.grep.try # 7292 -r--r--r-- 1992/adrian.hint # 2581 -r--r--r-- 1992/adrian.orig.c # 3164 -r--r--r-- 1992/albert.c # 3193 -r--r--r-- 1992/albert.hint # 3153 -r--r--r-- 1992/albert.orig.c # 8745 -r-------- 1992/ant.README # 2547 -r--r--r-- 1992/ant.c # 656 -r--r--r-- 1992/ant.hint # 3164 -r--r--r-- 1992/ant.test.mk # 2236 -r--r--r-- 1992/buzzard.1.c # 8217 -r--r--r-- 1992/buzzard.1.hint # 756 -r--r--r-- 1992/buzzard.2.README # 791 -r--r--r-- 1992/buzzard.2.c # 25773 -r--r--r-- 1992/buzzard.2.design # 8915 -r--r--r-- 1992/buzzard.2.hint # 794 -r--r--r-- 1992/buzzard.2.orig.c # 212 -r--r--r-- 1992/demo1.1st # 34 -r--r--r-- 1992/demo1.th # 135 -r--r--r-- 1992/demo2.th # 245 -r--r--r-- 1992/demo3.th # 439 -r--r--r-- 1992/demo4.th # 339 -r--r--r-- 1992/demo5.th # 388 -r--r--r-- 1992/demo6.th # 1513 -r--r--r-- 1992/gson.c # 10891 -r--r--r-- 1992/gson.hint # 1774 -r--r--r-- 1992/help.th # 1965 -r--r--r-- 1992/imc.c # 6479 -r--r--r-- 1992/imc.hint # 1937 -r--r--r-- 1992/imc.orig.c # 2119 -r--r--r-- 1992/kivinen.c # 2547 -r--r--r-- 1992/kivinen.hint # 2084 -r--r--r-- 1992/kivinen.orig.c # 1885 -r--r--r-- 1992/lush.c # 695 -r--r--r-- 1992/lush.hint # 1885 -r--r--r-- 1992/lush.orig.c # 1766 -r--r--r-- 1992/marangon.c # 1062 -r--r--r-- 1992/marangon.hint # 1743 -r--r--r-- 1992/marangon.orig.c # 878 -r--r--r-- 1992/nathan.c # 4546 -r--r--r-- 1992/nathan.hint # 6605 -r--r--r-- 1992/third # 3203 -r--r--r-- 1992/vern.c # 6513 -r--r--r-- 1992/vern.hint # 305 -r--r--r-- 1992/westley.c # 4374 -r--r--r-- 1992/westley.hint # 3201 -r--r--r-- 1992/vern.orig.c # if touch 2>&1 | fgrep 'amc' > /dev/null then TOUCH=touch else TOUCH=true fi # ============= 1992/README ============== if test ! -d '1992'; then echo "x - creating directory 1992" mkdir '1992' fi echo "x - extracting 1992/README (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/README && X1992 marked the "The Ninth International Obfuscated C Code Contest" X XUse make to compile entries. It is possible that on BSD or non-unix Xsystems the makefile needs to be changed. See the Makefile for details. X XLook at the source and try to figure out what the programs do, and run Xthem with various inputs. If you want to, look at the hints files for Xspoilers - this year we included most of the information included Xby the submitters. X XRead over the makefile for compile/build issues. Your system may Xrequire certain changes (add or remove a library, add or remove a X#define). A number of compilers had problems optimizing certain Xentries. Some compilers do optimize, but the resulting program Xdoes not work. By default we have left off -O from compile lines. XYou might want to add -O back, or add it back for certain entries Xwhere performance is important. X XThis year marked an all time high for number of entries as well as the Xquality of entries. Nearly twice the usual number of entries made it Xto the final judging rounds. Even when we raised the standards for Xwinning, we still wound giving out a few more awards than in other Xyears. The new size rules size probably contributed to the overall Xhigh quality. X XFYI: By tradition, we do not record the count the number entries, X nor do we give our our guess as to the number of entries X received. For folks who wonder, we can say that we consumed X about 2000 pages of output (printing between 2 and 4 normal X pages per side) during the judging process this year. X XThe new instructions for submitting entries worked well - we were Xable to write scripts to unpack them and eliminate duplicates. X XAs promised last year, we accepted programs that made use of the X Xlibraries for the first time. We now consider ANSI C compilers to be Xthe "standard" version that the entries were compiled with. X XName and address information are separated from the actual program Xprior to judging. This eliminates any chance that we would bias our Xjudging for/against any person or group. In the end, we are surprised Xas you are to see who as won. Even so, it is worth noting that XBrian Westley has submitted a winning entry for the past 6 years! X X XA few notes regarding future contests: X XWe did not give awards to some traditional contest categories such as X"Best Layout". We felt that to do so would deny awards to more Xdeserving entries. These categories have not been eliminated. We will Xlikely be awarding them in future years. X XWe received a few entries whose instructions were rot13'd. While Xnothing was said about this in the rules, we found that it made the Xjudging process a little harder, so we may request that this not Xbe done this in the future. X XSome thought has been given to a separate obfuscated perl contest. XWatch comp.lang.perl for details! X XBe sure to wait until the 1993 rules are posted before submitting entries. XWe may fine tune the rules to reflect the some ideas above. X XPlease send us comments and suggestions what we have expressed above. XAlso include anything else that you would like to see in future contests. XSend such email to: X X ...!{sun,pacbell,uunet,pyramid}!hoptoad!judges X judges@toad.com X X XIf you use, distribute or publish these entries in some way, please drop Xus a line. We enjoy seeing who, where and how the contest is used. X XIf you have problems with any of the entries, AND YOU HAVE A FIX, please XEmail the fix (patch file or the entire changed file) to the above address. X XCredits: X XWe would like to thank Barbara Frezza for her role as official chef of Xthe contest. Landon Noll and Larry Bassel appreciated the opportunity Xto serve as official taste testers. Yummo! SHAR_EOF $TOUCH -am 0908163992 1992/README && chmod 0444 1992/README || echo "restore of 1992/README failed" set `wc -c 1992/README`;Wc_c=$1 if test "$Wc_c" != "3693"; then echo original size 3693, current size $Wc_c fi # ============= 1992/rules ============== echo "x - extracting 1992/rules (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/rules && X9th International Obfuscated C Code Contest Rules 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 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: 1992 Xtitle: title of entry (see comments below) Xentry: Entry number from 0 to 7 inclusive Xdate: Date/time of submission (use the format of the date command) 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 ok. 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 expression: [a-zA-Z0-9_+=,][a-zA-Z0-9_+=,.-]* X and must be 1 to 10 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 * All text outside of the above format will be kept confidential, X unless otherwise stated. Notes about an author of a winning entry X will be published unless 'y' was given to that 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 * 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) Your entry must be written in C. Use of ANSI C is preferred. Use X of common C (K&R + extensions) is permitted, as long as it does not X cause major problems 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 09-May-92 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 obfuscate@toad.com 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-92 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-92 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 produce a file (or files) which may be executed. X X XFOR MORE INFORMATION: X X The Judging will be done by Landon Noll and Larry Bassel. Please send X questions or comments (but not entries) about the contest, to: X X ...!{apple,pyramid,sun,uunet}!hoptoad!judges X judges@toad.com 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. The IOCCC rules and guidelines may be X obtained from the judges at the address above. Please use one of X the following subjects in your request: X X send rules to obtain the current IOCCC rules X send guidelines to obtain the current IOCCC guidelines X send mkentry to obtain the current IOCCC mkentry program X send all to obtain the current IOCCC rules,guidelines,mkentry X X One may also obtain them via anonymous ftp from: X X host: ftp.uu.net (137.39.1.9) X user: anonymous X pass: yourname@yourhost X dir: /pub/ioccc X X Xchongo <Landon Curt Noll> /\cc/\ hoptoad!chongo XLarry Bassel {uunet,ucbvax,cbosgd}|sun!lab SHAR_EOF $TOUCH -am 0817110092 1992/rules && chmod 0444 1992/rules || echo "restore of 1992/rules failed" set `wc -c 1992/rules`;Wc_c=$1 if test "$Wc_c" != "7451"; then echo original size 7451, current size $Wc_c fi # ============= 1992/guidelines ============== echo "x - extracting 1992/guidelines (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/guidelines && X9th International Obfuscated C Code Contest Guidelines, Hints and Comments X 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 XWHAT IS NEW IN 1992: X X The size rules are different this year. There is a more relaxed X rule to encourage formatting styles beyond rectangular blobs of C X code. The build file (how to compile) has been expanded as well. X See the rules, and OUR LIKES AND DISLIKES for details. X X The entry format is better (for us anyway). The program mkentry.c X provides a convenient way to form an entry. See ENTRY FORMAT. X X The original entry source, build and resulting binary should be X treated as read-only. There is a provision to allow entries to X modify these files indirectly. See ENTRY FORMAT. X X This year, we are experimenting with a new category of programs: X X clients. X client entries should be as portable as possible. X 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 * If it is ANSI, convert 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 declarations X int k; X X We suggest that you use ANSI C compilers if possible. If you must X use non-ANSI C, such as K&R C, try to avoid areas that give ANSI C X compilers problems. 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 for one liners X in our books. 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 X11r3 (or X earlier), so try to target X11r4 without requiring X11r4. 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. Better yet, give an xrdb -merge X command as part of the build. 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: 1992 Xtitle: chonglab Xentry: 0 Xdate: Mon Feb 17 13:58:57 1992 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! (yes, Hello world progs have become old too) X---author--- Xname: Landon Curt Noll Xorg: IOCCC Judging Group Xaddr: Toad Hall X San Francisco, CA 94101 X USA Xemail: chongo@toad.com Xanon: n X---author--- Xname: Larry Bassel Xorg: IOCCC Judging Group Xaddr: Toad Hall X San Francisco, CA 94101 X USA Xemail: hoptoad!sun!lab X lab@sun.com Xanon: n X---info--- Xbegin 444 info.file XM2&$A("!792!G;W0@>6]U('1O(&QO;VLA"@I4:&%T('1H870@:7,L(&ES+@I4 XM:&%T('1H870@:7,@;F]T+`H@("`@:7,@;F]T('1H870@=&AA="!N;W0@:7,N XM"E1H870@:7,L('1H870@=&AA="!I<R!N;W0L(&ES(0H*"0DM+2!C:&]N9V\@ X%,3DW-`H@ X` Xend X---build--- Xbegin 444 build X28V,@<')O9RYC("UO('!R;V<* X` Xend X---program--- Xbegin 444 prog.c XC;6%I;B@I>W!R:6YT9B@B2&5L;&\L('=O<FQD(5QN(BD[?0H` X` Xend X---end--- X X Where build uudecodes into: X Xcc prog.c -o prog X X and prog.c uudecodes into: X Xmain(){printf("Hello, world!\n");} 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 lengthly 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 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 entry that failed to win on a X previous year. There have been winners that lost in a previous X year. Of course, in those cases, improving on the entry made X the difference! 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 X tradition, this is done during the latter part of the UUNET/IOCCC BOF, X just prior to 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 X X Winning entries will be deposited into the uunet archives. See X below for details. X X Often, winning entries are published in magazines such as "The C Users X Journal". Winners have appeared in books ("The New Hackers Dictionary") X 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 judges@toad.com submitting entries) X X Questions and comments about the contest are welcome. X X One may obtain a copy of the current rules, guidelines or mkentry X program as well. To stream line these common requests, we request X that you use the following subjects when making such requests: X X subject to request X ------- ---------- X send rules to obtain the current IOCCC rules X send guidelines to obtain the current IOCCC guidelines X send mkentry to obtain the current IOCCC mkentry program X send allinfo to obtain the current IOCCC rules,guidelines,mkentry X X One may also obtain the above items, we well as winners of previous X contests, via anonymous ftp from: X X host: ftp.uu.net (137.39.1.9) X user: anonymous X pass: yourname@yourhost X dir: pub/ioccc X X Often, contest rules, guidelines and winners are available from X archive sites. Check comp.sources.unix archives, for example. X You may also request previous winners by Email, using the judges X Email address, though we ask that you do this as a last resort. X X Xchongo <Landon Curt Noll> /\cc/\ hoptoad!chongo XLarry Bassel {uunet,ucbvax,cbosgd}|sun!lab SHAR_EOF $TOUCH -am 0908154692 1992/guidelines && chmod 0444 1992/guidelines || echo "restore of 1992/guidelines failed" set `wc -c 1992/guidelines`;Wc_c=$1 if test "$Wc_c" != "22215"; then echo original size 22215, current size $Wc_c fi # ============= 1992/Makefile ============== echo "x - extracting 1992/Makefile (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/Makefile && X# %W% %G% %U% X# X# 1992 makefile X XSHELL=/bin/sh XCHMOD=chmod XCP=cp XRM=rm XSED=sed XLN=ln XUNIQ=uniq XCB=cb XGREP=grep X# set this to where your C Processor resides X# X# On some systems: X# CPP=/lib/cpp X# XCPP=/usr/ccs/lib/acpp X X# flags for ansi compiles X# X# NOTE: Some ANSI compilers make use of -Xa to turn on ANSI mode, X# others such as gcc may want -ansi, others may want nothing X# at all. Adjust the CFLAGS line as needed. X# X# NOTE: Some compilers cannot optimize, or optimize some entries X# entries incorrectly. You might want need to turn on -O X# to see if your compiler can handle them. X# X#CFLAGS=-O -Xa XCFLAGS=-Xa XCC=cc X X# misc shell babble X# XNOINCLUDE=$(SED) -e 's/^.$[ ]*$include/%include/' XSPACECLEAN=$(SED) -e 's/$[^ ]$$[ ]$[ ][ ]*/\1\2/g' XCPPCLEAN=$(GREP) -v '^. [0-9][0-9]*' X X# winners that compile under ANSI C X# XWINNERS= adrian albert ant buzzard.1 buzzard.2 gson kivinen imc \ X lush marangon nathan vern westley XALT_NAMES= adgrep am babble first ag whereami X Xall: $(WINNERS) $(ALT_NAMES) X Xadrian: adrian.c X $(CC) $(CFLAGS) adrian.c -o adrian X $(RM) -f ad.temp adwc.c adbasename.c adecho.c adhead.c adsleep.c X $(SED) '1s/\..*\./. wc ./' adrian.c > ad.temp X -./adrian ad.temp <ad.temp >adwc.c X $(CC) -o adwc adwc.c X $(SED) '1s/\..*\./. basename ./' adrian.c > ad.temp X -./adrian ad.temp <ad.temp >adbasename.c X $(CC) -o adbasename adbasename.c X $(SED) '1s/\..*\./. echo| ./' adrian.c > ad.temp X -./adrian ad.temp <ad.temp >adecho.c X $(CC) -o adecho adecho.c X $(SED) '1s/\..*\./. head; ./' adrian.c > ad.temp X -./adrian ad.temp <ad.temp >adhead.c X $(CC) -o adhead adhead.c X $(SED) '1s/\..*\./. sleep ./' adrian.c > ad.temp X -./adrian ad.temp <ad.temp >adsleep.c X $(CC) -o adsleep adsleep.c X $(RM) -f ad.temp X X# NOTE: this is the original source that won X# Xadrian.orig: adrian.orig.c X $(CC) $(CFLAGS) adrian.orig.c -o adrian.orig X Xalbert: albert.c X $(CC) $(CFLAGS) albert.c -o albert X X# NOTE: this is the original source that won X# Xalbert.orig: albert.orig.c X $(CC) $(CFLAGS) albert.orig.c -o albert.orig X Xant: ant.c X $(CC) $(CFLAGS) ant.c -o ant X Xbuzzard.1: buzzard.1.c X $(CC) $(CFLAGS) buzzard.1.c -o buzzard.1 X Xbabble.cppcb: buzzard.1.c X $(NOINCLUDE) buzzard.1.c | \ X $(CPP) $(CPPFLAGS) | \ X $(CPPCLEAN) | \ X $(CB) $(CBFLAGS) | \ X $(UNIQ) | \ X $(SPACECLEAN) > babble.cppcb 2>&1 X Xbuzzard.2: buzzard.2.c X $(CC) $(CFLAGS) buzzard.2.c -o buzzard.2 X X# NOTE: this is the original source that won X# Xbuzzard.2.orig: buzzard.2.orig.c X $(CC) $(CFLAGS) buzzard.2.orig.c -o buzzard.2.orig X Xgson: gson.c X $(CC) $(CFLAGS) gson.c -o gson X X# NOTE: some systems may only need: X# X# $(CC) $(CFLAGS) kivinen.c -o kivinen -lX11 X# Xkivinen: kivinen.c X $(CC) $(CFLAGS) kivinen.c -o kivinen -lX11 -lsocket -lresolv -lnsl X X# NOTE: this is the original program that won X# X# NOTE: some systems may only need: X# X# $(CC) $(CFLAGS) kivinen.c -o kivinen -lX11 X# Xkivinen.orig: kivinen.orig.c X $(CC) $(CFLAGS) kivinen.orig.c -o kivinen.orig -lX11 \ X -lsocket -lresolv -lnsl X Ximc: imc.c X $(CC) $(CFLAGS) imc.c -o imc X X# NOTE: this is the original program that won X# Ximc.orig: imc.orig.c X $(CC) $(CFLAGS) imc.orig.c -o imc.orig X Xlush: lush.c X $(CC) $(CFLAGS) lush.c -o lush X Xlush.again: lush.c X $(CC) $(CFLAGS) lush.c -o lush.again X $(RM) -f lush.again X X# NOTE: this is the original program that won X# Xlush.orig: lush.orig.c X $(CC) $(CFLAGS) lush.orig.c -o lush.orig X X# NOTE: some systems may need: X# X# $(CC) $(CFLAGS) marangon.c -o marangon -lcurses -ltermcap X# Xmarangon: marangon.c X $(CC) $(CFLAGS) marangon.c -o marangon -lcurses X X# NOTE: this is the original program that won X# X# NOTE: some systems may need: X# X# $(CC) $(CFLAGS) marangon.orig.c -o marangon.orig -lcurses -ltermcap X# Xmarangon.orig: marangon.orig.c X $(CC) $(CFLAGS) marangon.orig.c -o marangon.orig -lcurses X Xnathan: nathan.c X $(CC) $(CFLAGS) nathan.c -o nathan X X# NOTE: this is the original program that won X# Xnathan.orig: nathan.orig.c X $(CC) $(CFLAGS) nathan.orig.c -o nathan.orig X Xvern: vern.tmp.c X $(CC) $(CFLAGS) vern.tmp.c -o vern X Xvern.tmp.c: vern.c X $(RM) -f vern.tmp.c X $(SED) <vern.c 's/{ /(/g;s/} /)/g;s/; /#define /' | \ X $(SED) 's/} /=/g;s/{ /i/g' >vern.tmp.c X X# NOTE: this is the original program that won X# Xvern.orig: vern.orig.tmp.c X $(CC) $(CFLAGS) vern.orig.tmp.c -o vern.orig X Xvern.orig.tmp.c: vern.orig.c X $(RM) -f vern.orig.tmp.c X $(SED) <vern.orig.c 's/{ /(/g;s/} /)/g;s/; /#define /' | \ X $(SED) 's/} /=/g;s/{ /i/g' >vern.orig.tmp.c X Xwestley: westley.c X $(CC) $(CFLAGS) westley.c -o westley X X# alternate names for selected entries X# Xadgrep: adrian X $(RM) -f adgrep X $(LN) adrian adgrep Xam: ant X $(RM) -f am X $(LN) ant am Xbabble: buzzard.1 X $(RM) -f babble X $(LN) buzzard.1 babble Xfirst: buzzard.2 X $(RM) -f first X $(LN) buzzard.2 first Xag: gson X $(RM) -f ag X $(LN) gson ag Xwhereami: westley X $(RM) -f whereami X $(LN) westley whereami X Xclean: X $(RM) -f *.o a.out core X $(RM) -f vern.tmp.c lush.again babble.cppcb vern.orig.tmp.c X $(RM) -f ad.temp adwc.c adbasename.c adecho.c adhead.c adsleep.c X Xclobber: clean X $(RM) -f $(WINNERS) a.out X $(RM) -f $(ALT_NAMES) X $(RM) -f adwc adbasename adecho adhead adsleep X $(RM) -f adrian.orig lush.orig nathan.orig buzzard.2.orig X $(RM) -f kivinen.orig imc.orig albert.orig marangon.orig vern.orig X Xam_clobber: clean am X $(RM) -f am.safe X $(CP) am am.safe X $(RM) -f $(WINNERS) a.out X $(RM) -f $(ALT_NAMES) X $(RM) -f adwc adbasename adecho adhead adsleep X $(RM) -f adrian.orig lush.orig nathan.orig buzzard.2.orig X $(RM) -f kivinen.orig imc.orig albert.orig marangon.orig vern.orig X $(CP) am.safe am X $(RM) -f am.safe X Xnuke: clobber X @true X Xinstall: all X cat $(WINNERS) > /dev/null SHAR_EOF $TOUCH -am 0908160192 1992/Makefile && chmod 0444 1992/Makefile || echo "restore of 1992/Makefile failed" set `wc -c 1992/Makefile`;Wc_c=$1 if test "$Wc_c" != "5632"; then echo original size 5632, current size $Wc_c fi # ============= 1992/adrian.c ============== echo "x - extracting 1992/adrian.c (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/adrian.c && X/* . wc . */ X#include<stdio.h>/* Wht majr flwchrt? */ X#include<string.h>/* That mjr flwchrt! */ X#define P 257 X#define G 17 X#define z 8 X#define v(jr) jr Xint W ,head; X#define S(W,b,f) strncpy(W,b,f),W[f]=0\ X X Xchar *wcs=" \t\n"; Xstruct{ char X[z+1]; X char f ; X int e ; X struct{ char g[z+1]; X int b ; X } w[ G]; X } o[ P]; Xint L=0,j= -28; X X Xvoid E(int i, int m,char*c) X{ X for(; i<43; i+=3) X putc("}|uutsrq`_^bji`[Zkediml[PO]a_M__]ISOYIRGTNR"[i]+i-9,stderr); X fprintf(stderr,"(%d): %s\n" ,m,c); X exit(1); X} X X X Xint N(int m, char *t) X{ X int i ; X if (strlen ( X t)>z) t[z ]=0; X for(i= 0; i< L ; i++) if( X !strcmp (o[ i] . X X , t))return i; X if( L== P) X E(0, m, t); X S (o[ L] . X , t X ,z); X head; W = .1* head; X o[L ].f = !( strchr( t,']' )== 0 ); X o[L ++ ] . e = 0; X return L -1 ; } X X#define v(x ) X Xint A(char *R) X{ X int c=0, i; X while(* R) { X i = -1; X while(j){ X if( ++ i==o[ c].e ) return 0; X if(o[ X c] .w[i ] .g[0 ] X =='.' ||strchr (o[ c].w[i] .g ,* R)){ X c= X o[ c ] .w[i].b; break;/* Xmain(int sl,char *j[]){ X sleep (~~~~~~~~atoi(j[1])) ;/* . sl X sl s l . sl X l l ] X sl */ } X } X R++; X } X return o[ c].f; X} X X X main(int wc,char *V[]){char Y[999],*s;FILE*W;int m=0,echo,jr,q,wcl=0,wcw=0,wcc=0; X v(s = V[1]; if (*V=strrchr(s,'/'))s=*V+1; if(( !strncmp( s + (jr=strlen(s)) - X (q=strlen(V[2]) ),V[2],q))&&jr!=q) s[jr-q] = 0; puts(s); ) X int e,p,C=0,Q ,basename; X W= fopen(wc>= 2 ? V[1] : "adgrep.c","rt"); Xecho| m^ e| 5| (int) .8| echo| Xwc |C ==o[o[C] .e] . Xe| e==+p,p; s[o[C] .e ] X; Xwhile( fgets(Y,998,W)) { wcc += strlen(Y); m++; X if( s = strtok(Y,wcs)) wcw++; X else continue ; X C= X basename= j +j+*"* . basename" X +j+*"* r ] " + N(m,s) ; Xwhile( s = strtok(0,wcs)) { X if( o[ C ] . e == X G) E(1 ,m,o[C] .X) ; X S(o[C X ] .w[o[C ] .e].g,s, z); X Q= C ; X if(! ( s =strtok ( 0 ,wcs )))wcw -- X ,E( 2 , m, o[C] X . w[ o[ Q ] .e] . g ); X e X = o[C ] .w[o[C ] .e++ ] .b= N(m,s) X ; wcw += 2; } X 0&& X W && wcl++ X < 10 && printf((W,Y)); } X if(j+28) { { X ; } printf("%7u%7u%7u\n", wcl , wcw , wcc); } X while( gets(Y) ) if(A(Y)) puts(Y); X W, jr; } X XO(int wc,char**V) { X--wc && (printf("%s ",*++V), main(wc,V), 1) || printf("\n"); } X SHAR_EOF $TOUCH -am 0817110092 1992/adrian.c && chmod 0444 1992/adrian.c || echo "restore of 1992/adrian.c failed" set `wc -c 1992/adrian.c`;Wc_c=$1 if test "$Wc_c" != "2583"; then echo original size 2583, current size $Wc_c fi # ============= 1992/adrian.grep.1 ============== echo "x - extracting 1992/adrian.grep.1 (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/adrian.grep.1 && X <q0> a <q1> The first state to appear is the start state X <q1> b <q2> X <q2> c [q3] X [q3] SHAR_EOF $TOUCH -am 0817110092 1992/adrian.grep.1 && chmod 0444 1992/adrian.grep.1 || echo "restore of 1992/adrian.grep.1 failed" set `wc -c 1992/adrian.grep.1`;Wc_c=$1 if test "$Wc_c" != "131"; then echo original size 131, current size $Wc_c fi # ============= 1992/adrian.grep.2 ============== echo "x - extracting 1992/adrian.grep.2 (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/adrian.grep.2 && X <q0> a <q1> X <q1> b <q2> X <q2> c [q3] X [q3] . [q3] SHAR_EOF $TOUCH -am 0817110092 1992/adrian.grep.2 && chmod 0444 1992/adrian.grep.2 || echo "restore of 1992/adrian.grep.2 failed" set `wc -c 1992/adrian.grep.2`;Wc_c=$1 if test "$Wc_c" != "64"; then echo original size 64, current size $Wc_c fi # ============= 1992/adrian.grep.3 ============== echo "x - extracting 1992/adrian.grep.3 (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/adrian.grep.3 && X <q0> a <q1> . <q0> X <q1> b <q2> a <q1> . <q0> X <q2> c [q3] a <q1> . <q0> X [q3] . <q1> SHAR_EOF $TOUCH -am 0817110092 1992/adrian.grep.3 && chmod 0444 1992/adrian.grep.3 || echo "restore of 1992/adrian.grep.3 failed" set `wc -c 1992/adrian.grep.3`;Wc_c=$1 if test "$Wc_c" != "99"; then echo original size 99, current size $Wc_c fi # ============= 1992/adrian.grep.4 ============== echo "x - extracting 1992/adrian.grep.4 (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/adrian.grep.4 && X [q0] a <q1> X <q1> b <q2> X <q2> c [q0] SHAR_EOF $TOUCH -am 0817110092 1992/adrian.grep.4 && chmod 0444 1992/adrian.grep.4 || echo "restore of 1992/adrian.grep.4 failed" set `wc -c 1992/adrian.grep.4`;Wc_c=$1 if test "$Wc_c" != "48"; then echo original size 48, current size $Wc_c fi # ============= 1992/adrian.grep.5 ============== echo "x - extracting 1992/adrian.grep.5 (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/adrian.grep.5 && X <q0> ab <q1> X <q1> cd <q2> X <q2> ef [q3] X [q3] SHAR_EOF $TOUCH -am 0817110092 1992/adrian.grep.5 && chmod 0444 1992/adrian.grep.5 || echo "restore of 1992/adrian.grep.5 failed" set `wc -c 1992/adrian.grep.5`;Wc_c=$1 if test "$Wc_c" != "60"; then echo original size 60, current size $Wc_c fi # ============= 1992/adrian.grep.from ============== echo "x - extracting 1992/adrian.grep.from (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/adrian.grep.from && X<q0> F <q1> X<q1> r <q2> X<q2> o <q3> X<q3> m <q4> X<q4> : <q5> . [q6] X<q5> . <q5> X[q6] . [q6] X SHAR_EOF $TOUCH -am 0817110092 1992/adrian.grep.from && chmod 0444 1992/adrian.grep.from || echo "restore of 1992/adrian.grep.from failed" set `wc -c 1992/adrian.grep.from`;Wc_c=$1 if test "$Wc_c" != "92"; then echo original size 92, current size $Wc_c fi # ============= 1992/adrian.grep.try ============== echo "x - extracting 1992/adrian.grep.try (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/adrian.grep.try && X <q0> t <q1> . <q0> X <q1> hc <q2> t <q1> . <q0> X <q2> eh [q3] t <q1> . <q0> X [q3] . <q1> SHAR_EOF $TOUCH -am 0817110092 1992/adrian.grep.try && chmod 0444 1992/adrian.grep.try || echo "restore of 1992/adrian.grep.try failed" set `wc -c 1992/adrian.grep.try`;Wc_c=$1 if test "$Wc_c" != "101"; then echo original size 101, current size $Wc_c fi # ============= 1992/adrian.hint ============== echo "x - extracting 1992/adrian.hint (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/adrian.hint && XMost Educational: <adrian@u.washington.edu> Adrian Mariano X X Adrian Mariano X University of Washington X 2729 72nd Ave SE X Mercer Island, WA 98040 X USA X X XJudges' comments: X X To build: X make adrian X X Try: X adrian adrian.grep.try < adrian.hint X X For the slow minded, try: X adsleep 32767 X X Once you get past the obfuscation, you have an opportunity to learn X about regular expressions and state machines. X X NOTE: Some compilers have had trouble optimizing this entry. X X XSelected notes from the author: X X ADrian's GREP (adgrep) X X For those confused by the complexity of full-blown egrep style regular X expressions, this program offers an alternative. It implements an X equivalent search, using a deterministic finite automaton. X X A deterministic finite automaton consists of a finite set of states, X along with transition rules to move from one state to another, an initial X state, and a set of accepting states. The automaton takes a string as X input and begins in the start state. It reads a character of the string X and consults the rules for the current state, moving to the new state X indicated by the appropriate rule. This process is repeated until the X string is consumed. If the current state at this point is one of the X accepting states, then the string is accepted. X X The deterministic finite automaton is specified as a series of rules for X each state: X X <state> chars1 <dest1> chars2 <dest2> ... X X chars1 is a list of characters (only the first 8 are significant) which X should trigger a transition to <dest1>. <dest1> is another state which X should have a similar specification somewhere. A state is accepting if X it is specified in square brackets: [final], and state strings are X significant to only eight characters. X X Example 1: matches ^abc$ X X <q0> a <q1> The first state to appear is the start state X <q1> b <q2> X <q2> c [q3] X [q3] X X Technically, a deterministic finite automaton should have a rule for each X possible input character at each state. To simplify descriptions of the X automata, if no rule is present, the string will not be accepted. Also, X the '.' character matches any character if it occurs first in the X character list. X X X Example 2: ^abc X X <q0> a <q1> X <q1> b <q2> X <q2> c [q3] X [q3] . [q3] X X X Example 3: abc$ X X <q0> a <q1> . <q0> X <q1> b <q2> a <q1> . <q0> X <q2> c [q3] a <q1> . <q0> X [q3] . <q1> X X X Example 4: ^(abc)*$ X X [q0] a <q1> X <q1> b <q2> X <q2> c [q0] X X X Example 5: ^[ab][cd][ef]$ X X <q0> ab <q1> X <q1> cd <q2> X <q2> ef [q3] X [q3] X X X Example 6: ^(abc|efg)$ X X <q0> a <q1> e <q3> X <q1> b <q2> X <q2> c [q5] X <q3> f <q4> X <q4> g [q5] X [q5] X X X With the automaton specification in 'filename', invoke the program by X typing X X adgrep 'filename' X X It will read stdin and print out all the lines which the automaton X accepts. If the file cannot be opened, a system error message will X be printed. If the input contains errors, then an error message along X with the number of the offending line will be printed to stderr. The X number of rules for each state is limited to 17. If more than 17 rules X are present, you get the error to_many_rules, and the state that was X being processed is printed. Error no_destination occurs if you specify a X set of characters, but no destination state, and error too_many_states X occurs if your automaton has more than 257 states. X X Running X adgrep from < your_mailbox X X will perform a function similar to that of the unix from command. X X If no filename is specified on the command line, then "adgrep.c" is used X as the specification for the automaton. (This file has been renamed X to adrian.c by the judges.) In this case, the program will search for X matches to the regular expression: X X ^.[^|C][^w[Q]*(Q|[w[]c).*|^.[C|]$ X X I suggest using adgrep.c as input, and storing the output in adwc.c: X X adgrep < adgrep.c > adwc.c X X Compiling the new file, mywc.c, yields a clone of the unix wc command. It X runs on one file (defaulting to "adgrep.c" if no file is given) and X displays the number of lines, words, and bytes in the input file. X X X Another possibly interesting automaton can be created by slightly X adjusting the adgrep.c file. Change the first line to read X X /* . echo| . */ X X and repeat the process above X X adgrep <adgrep.c > adecho.c X X The new file now contains all lines which match X X ^.[^5|m^]*[m^]([e=p,;]|[^e=+p,;].*)$ X X Compile and run. This is an echo clone. Note the efficient algorithm X employed. X X X Two other adjustments to the first line also yield useful results. By X changing it to X /* . head; . */ X X you can search for matches to X X ^.[^W]*W..*$ X X By some freak happenstance, lines of adgrep.c which match this regular X expression form a unix head command. It prints the first ten lines of X the file specified on the command line (or adgrep.c if no file is X specified). X X By setting the first line to X X /* . basename . */ X X a clone of the unix basename command can be unearthed. The automaton will X search for X ^.[^j]*jr.*$ X X on standard input. And the program which results by running adgrep.c X through this filter requires two parameters. The first is meant to be a X filename, and the second, an extension. All leading pathname components X are removed from the filename, and the extension is removed if present. X The resulting base name is printed to stdout. X X Lastly, by setting the first line to X X /* . sleep . */ X X you can search for X X ^.[^(~][^s]*sl.*$ X X Filtering adgrep.c through this search yields a clone of the sleep X command. Invoke with a single integer parameter, and it will pause X for that many seconds. X X If either adbasename or adsleep is invoked with too few parameters, X the program will print the error message: X Segmentation fault (core dumped) X X (The exact text of the above error messages varies from machine to X machine.) The four programs which read from stdin require lines X shorter than 999 characters. X X The other info files are adrian.grep.[1-6] which contain the six X examples that appear above, and from, which is used to emulate the X unix from command. For reasons of clarity, the name "from" should X probably not be changed if possible. I wouldn't want to be accused of X confusing people by giving the input files weird names. X X If you want to change the default input filename (line 80) you must be X careful to choose a name that doesn't match the wrong search patterns, X introducing extra lines into one of the programs. X X The program will produce at least one warning and possible several X when compiled depending on the compiler. SHAR_EOF $TOUCH -am 0908160292 1992/adrian.hint && chmod 0444 1992/adrian.hint || echo "restore of 1992/adrian.hint failed" set `wc -c 1992/adrian.hint`;Wc_c=$1 if test "$Wc_c" != "7292"; then echo original size 7292, current size $Wc_c fi # ============= 1992/adrian.orig.c ============== echo "x - extracting 1992/adrian.orig.c (Text)" sed 's/^X//' << 'SHAR_EOF' > 1992/adrian.orig.c && X/* . wc . */ X#include<stdio.h>/* Wht majr flwchrt? */ X#include<string.h>/* That mjr flwchrt! */ X#define P 257 X#define G 17 X#define z 8 X#define v(jr) jr Xint W ,head; X#define S(W,b,f) strncpy(W,b,f),W[f]=0\ X X Xchar *wcs=" \t\n"; Xstruct{ char X[z+1]; X char f ; X int e ; X struct{ char g[z+1]; X int b ; X } w[ G]; X } o[ P]; Xint L=0,j= -28; X X Xvoid E(int i, int m,char*c) X{ X for(; i<43; i+=3) X putc(i["}|uutsrq`_^bji`[Zkediml[PO]a_M__]ISOYIRGTNR"]+i-9,stderr); X fprintf(stderr,"(%d): %s\n" ,m,c); X exit(1); X} X X X Xint N(int m, char *t) X{ X int i ; X if (strlen ( X t)>z) t[z ]=0; X for(i= 0; i< L ; i++) if( X !strcmp (o[ i] . X X , t))return i; X if( L== P) X E(0, m, t); X S (o[ L] . X , t X ,z); X head; W = .1* head; X o[L ].f = !( strchr( t,']' )== 0 ); X o[L ++ ] . e = 0; X return L -1 ; } X X#define v(x ) X Xint A(char *R) X{ X int c=0, i; X while(* R) { X i = -1; X while(j){ X if( ++ i==o[ c].e ) return 0; X if(o[ X c] .w[i ] .g[0 ] X =='.' ||strchr (o[ c].w[i] .g ,* R)){ X c= X o[ c ] .w[i].b; break;/* Xmain(int sl,char *j[]){ X sleep (~~~~~~~~atoi(j[1])) ;/* . sl X sl s l . sl X l l ] X sl */ } X } X R++; X } X return o[ c].f; X} X X X main(int wc,char *V[]){char Y[999],*s;FILE*W;int m=0,echo,jr,q,wcl=0,wcw=0,wcc=0; X v(s = V[1]; if (*V=strrchr(s,'/'))s=*V+1; if(( !strncmp( s + (jr=strlen(s)) - X (q=strlen(V[2]) ),V[2],q))&&jr!=q) s[jr-q] = 0; puts(s); ) X int e,p,C,Q ,basename; X W= fopen(wc>= 2 ? V[1] : "adgrep.c","rt"); Xecho| m^ e| 5| (int) .8| echo| Xwc |C ==o[o[C] .e] . Xe| e==+p,p; s[o[C] .e ] X; Xwhile( fgets(Y,998,W)) { wcc += strlen(Y); m++; X if( s = strtok(Y,wcs)) wcw++; X else continue ; X C= X basename= j +j+*"* . basename" X +j+*"* r ] " + N(m,s) ; Xwhile( s = strtok(0,wcs)) { X if( o[ C ] . e == X G) E(1 ,m,o[C] .X) ; X S(o[C X ] .w[o[C ] .e].g,s, z); X Q= C ; X if(! ( s =strtok ( 0 ,wcs )))wcw -- X ,E( 2 , m, o[C] X . w[ o[ Q ] .e] . g ); X e X = o[C ] .w[o[C ] .e++ ] .b= N(m,s) X ; wcw += 2; } X 0&& X W && wcl++ X < 10 && printf((W,Y)); } X if(j+28) { { X ; } printf("%7u%7u%7u\n", wcl , wcw , wcc); } X while( gets(Y) ) if(A(Y)) puts(Y); X W, jr; } X XO(int wc,char**V) { X--wc && (printf("%s ",*++V), main(wc,V), 1) || printf("\n"); } X SHAR_EOF $TOUCH -am 0817110092 1992/adrian.orig.c && chmod 0444 1992/adrian.orig.c || echo "restore of 1992/adrian.orig.c failed" set `wc -c 1992/adrian.orig.c`;Wc_c=$1 if test "$Wc_c" != "2581"; then echo original size 2581, current size $Wc_c fi echo "End of part 1, continue with part 2" exit 0 -- For a good prime, call: 391581 * 2^216193 - 1