Add preview of 1984-2019
The 2020 winners are hinted it, but the source code is not there,
nor are the hints. Someone could look into the HTML and
see what was commented out, but that is not a problem because
WHO won is known and the name of their AWARD is known already.
Moreover a number of the winners have talked about what their
entirs do, so the commented out spoiler text is not a bit problem.
One will find HTML commented out with:
<!-- XXX remove when 2020 is ready
2020 links here
XXX remove when 2020 is ready -->
The "XXX remove when 2020 is ready" string is found at the
start and end comment blocks. Again, soneone could read
what was commented out, but that is OK since most of that
information is known or can be known. The following files
have such HTML comment blocks in them.
./winners.html
./years-spoiler.html
./years.html
In addition, ./all/summary.txt was modified to not
include the 2020 entries for the momemt.
The 2020 winner code AND write-ups are NOT part of this set.
p.s. The all/all.tar.bz2 does not contain the 2020 source code (yet?).
This commit is contained in:
Landon Curt Noll committed
1 parent
28efc67f5d
commit
c0663537cb
1683 files changed
+220064
No files matched your search
Binary file not shown.
+158
@@ -0,0 +1,158 @@
|
||||
# %W% %G% %U%
|
||||
#
|
||||
# 1994 makefile
|
||||
#
|
||||
# Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
# All Rights Reserved. Permission for personal, educational or non-profit
|
||||
# use is granted provided this this copyright and notice are included in its
|
||||
# entirety and remains unaltered. All other uses must receive prior permission
|
||||
# from Landon Curt Noll and Larry Bassel.
|
||||
|
||||
|
||||
SHELL=/bin/sh
|
||||
CAT=cat
|
||||
CHMOD=chmod
|
||||
CP=cp
|
||||
ECHO=echo
|
||||
GUNZIP=gunzip
|
||||
UUDECODE=uudecode
|
||||
LN=ln
|
||||
RM=rm
|
||||
SED=sed
|
||||
TRUE=true
|
||||
|
||||
# flags for ANSI compiles
|
||||
#
|
||||
# NOTE: Some ANSI compilers make use of -Xa to turn on ANSI mode,
|
||||
# others such as gcc may want -ansi, others may want nothing
|
||||
# at all. Adjust the CFLAGS line as needed.
|
||||
#
|
||||
# NOTE: Some compilers cannot optimize, or optimize some entries
|
||||
# entries incorrectly. You might want need to turn on -O
|
||||
# to see if your compiler can handle them.
|
||||
#
|
||||
#CFLAGS=-O -Xa
|
||||
#CFLAGS=-Xa
|
||||
#CFLAGS= -ansi
|
||||
CFLAGS= -ansi -O
|
||||
#CFLAGS=
|
||||
|
||||
# ANSI compiler
|
||||
#
|
||||
# Set CC to the name of your ANSI compiler.
|
||||
#CC=cc
|
||||
CC=gcc
|
||||
|
||||
# winners that compile under ANSI C
|
||||
#
|
||||
WINNERS= dodsond1 dodsond2 horton imc ldb schnitzi shapiro smr tvr weisberg \
|
||||
westley
|
||||
ALT_NAMES= dodsond2.orig shapiro.alt horton.alt gtface weisberg.alt tvr.alt
|
||||
|
||||
all: $(WINNERS) $(ALT_NAMES)
|
||||
|
||||
westley: westley.c
|
||||
${CC} ${CFLAGS} westley.c -DO -o westley
|
||||
|
||||
weisberg: weisberg.c
|
||||
${CC} ${CFLAGS} -Dc='n*n>x?p:((m=*(b+1)),N))' \
|
||||
-De='(2<<6*sizeof(int))' \
|
||||
-Do='(8<<5*sizeof(int))' \
|
||||
-DN='((b=t+1),x+=2,x>e?exit():o' \
|
||||
-Dp='(a-t<o?*(a++)=x:47),printf("%d ",x),N)' \
|
||||
weisberg.c -o weisberg
|
||||
|
||||
# If you want weisberg to generate all values up to MAXINT
|
||||
# and have the memory to malloc a 512M table, use the following.
|
||||
#
|
||||
weisberg.alt: weisberg.c
|
||||
${CC} ${CFLAGS} -Dc='n*n>x?p:((m=*(b+1)),N))' \
|
||||
-De='~(1<<8*sizeof(int)-1)' \
|
||||
-Do='(2<<7*sizeof(int))' \
|
||||
-DN='((b=t+1),x+=2,x>e?exit():o' \
|
||||
-Dp='(a-t<o?*(a++)=x:47),printf("%d ",x),N)' \
|
||||
weisberg.c -o weisberg.alt
|
||||
|
||||
tvr: tvr.c
|
||||
${CC} ${CFLAGS} tvr.c -o tvr -lX11
|
||||
|
||||
# The following is an alternate version of tvr. Modes 0-3 have been
|
||||
# renumbered 1-4. Mode 0 is Mandelbrot / julian calculated correctly.
|
||||
#
|
||||
tvr.alt: tvr.alt.c
|
||||
${CC} ${CFLAGS} tvr.alt.c -o tvr.alt -lX11
|
||||
|
||||
smr: smr.c
|
||||
@${RM} -rf smr
|
||||
${CP} smr.c smr
|
||||
${CHMOD} +x smr
|
||||
|
||||
shapiro: shapiro_t2.c
|
||||
${CC} ${CFLAGS} shapiro_t2.c -o shapiro
|
||||
|
||||
shapiro_t2.c: shapiro_t1
|
||||
@${RM} -f shapiro_t2.c
|
||||
./shapiro_t1 > shapiro_t2.c
|
||||
|
||||
shapiro_t1: shapiro.c
|
||||
${CC} ${CFLAGS} shapiro.c -o shapiro_t1
|
||||
|
||||
shapiro.alt: shapiro.alt.c
|
||||
${CC} ${CFLAGS} shapiro.alt.c -o shapiro.alt
|
||||
|
||||
schnitzi: schnitzi.c
|
||||
${CC} ${CFLAGS} schnitzi.c -o schnitzi
|
||||
|
||||
horton: horton.c
|
||||
${CC} ${CFLAGS} horton.c -o horton
|
||||
|
||||
# Here are some programs related to the horton entry. See horton.hint
|
||||
# for details.
|
||||
#
|
||||
horton.alt: horton.alt.c
|
||||
${CC} ${CFLAGS} horton.alt.c -o horton.alt
|
||||
gtface: gtface.c
|
||||
${CC} ${CFLAGS} gtface.c -o gtface
|
||||
|
||||
ldb: ldb.c
|
||||
${CC} ${CFLAGS} ldb.c -o ldb
|
||||
|
||||
imc: imc.c
|
||||
${CC} ${CFLAGS} imc.c -o imc
|
||||
|
||||
dodsond2: dodsond2.c
|
||||
${CC} ${CFLAGS} dodsond2.c -o dodsond2
|
||||
|
||||
# NOTE: this is the original (gziped) file that won
|
||||
#
|
||||
dodsond2.orig: dodsond2.gz
|
||||
@${RM} -f dodsond2.orig.c
|
||||
-${GUNZIP} < dodsond2.gz > dodsond2.orig.c
|
||||
-@if [ -s dodsond2.orig.c ]; then \
|
||||
${ECHO} "${CC} ${CFLAGS} dodsond2.orig.c -o dodsond2.orig"; \
|
||||
${CC} ${CFLAGS} dodsond2.orig.c -o dodsond2.orig; \
|
||||
else \
|
||||
${RM} -f dodsond2.orig.c; \
|
||||
${ECHO} "sorry, we could not gunzip dodsond2.gz"; \
|
||||
fi
|
||||
|
||||
dodsond2.gz: dodsond2.gz.uu
|
||||
@${RM} -f dodsond2.gz
|
||||
${UUDECODE} dodsond2.gz.uu
|
||||
|
||||
dodsond1: dodsond1.c
|
||||
${CC} ${CFLAGS} dodsond1.c -o dodsond1
|
||||
|
||||
clean:
|
||||
$(RM) -f *.o a.out core
|
||||
|
||||
clobber: clean
|
||||
$(RM) -f $(WINNERS)
|
||||
$(RM) -f $(ALT_NAMES)
|
||||
${RM} -f dodsond2.orig.c dodsond2.gz shapiro_t2.c shapiro_t1
|
||||
|
||||
nuke: clobber
|
||||
@${TRUE}
|
||||
|
||||
install: all
|
||||
${CAT} $(WINNERS) $(ALT_NAMES) > /dev/null
|
||||
+138
@@ -0,0 +1,138 @@
|
||||
1994 marked the "The Eleventh International Obfuscated C Code Contest"
|
||||
|
||||
Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
All Rights Reserved. Permission for personal, educational or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in writing
|
||||
from both Landon Curt Noll and Larry Bassel.
|
||||
|
||||
|
||||
Use make to compile entries. It is possible that on BSD or non-unix
|
||||
systems the makefile needs to be changed. See the Makefile for details.
|
||||
|
||||
Look at the source and try to figure out what the programs do, and run
|
||||
them with various inputs. If you want to, look at the hints files for
|
||||
spoilers - this year we included most of the information included
|
||||
by the submitters.
|
||||
|
||||
Read over the makefile for compile/build issues. Your system may
|
||||
require certain changes (add or remove a library, add or remove a
|
||||
#define).
|
||||
|
||||
Name and address information are separated from the actual program
|
||||
prior to judging. This eliminates any chance that we would bias our
|
||||
judging for/against any person or group.
|
||||
|
||||
This year we retracted the guideline that discouraged the use of C
|
||||
constructs such as 3["curds"]. At one time, certain ANSI compilers did
|
||||
not consider such expressions to be valid ANSI C. Alert readers noted
|
||||
that the current ANSI standard considered them to be valid. We were
|
||||
unable to find an ANSI C compiler that flagged such expressions as
|
||||
errors.
|
||||
|
||||
Rule abuse was encouraged this year - two of this year's winners found
|
||||
new and interesting abuses of the rules. Next year's rules will change
|
||||
due to these (smr and dodsond2) entries' forms of abuse.
|
||||
|
||||
|
||||
Want to be an IOCCC Judge?
|
||||
--------------------------
|
||||
|
||||
We are thinking about adding a 3rd judge to our team. A 3rd judge
|
||||
would help distribute the work load as well as to allowing us to
|
||||
possibly expand or reshape the contest.
|
||||
|
||||
The ideal 3rd judge would have all of the following:
|
||||
|
||||
* thorough knowledge of the C language (ANSI and K&R)
|
||||
* thorough knowledge of common C libs (libc, libm, libcurses, ...)
|
||||
* reasonable written communication skills (able to write *.hint files)
|
||||
* appreciation for well-written non-obfuscated code
|
||||
* willing to devote ~4 weekend days in January (starting Jan 96) for judging
|
||||
* located in the San Francisco (California, USA) Bay Area, or
|
||||
able to travel (paying your own way) to the SF Bay Area during judging, or
|
||||
able to link to the other IOCCC judges some form of a a video link
|
||||
|
||||
Any of the following, though not required, would be a plus:
|
||||
|
||||
* familiar with portability issues
|
||||
* some /bin/sh experience
|
||||
* some Perl experience
|
||||
* some C++ experience
|
||||
* some experience with low-level X11 programming
|
||||
* attends Usenix conferences on a regular basis
|
||||
* good sense of humor
|
||||
* loves chocolate and other fine foods :-)
|
||||
|
||||
If you think this may be you, send EMail before 31 Dec 1995, to:
|
||||
|
||||
judges@toad.com (use the Subject: 3rd judge)
|
||||
|
||||
Include in your message:
|
||||
|
||||
* Your name, address, EMail address and phone number
|
||||
* Why would you want to be an IOCCC judge?
|
||||
* How well do you match each of the above qualifications?
|
||||
* What special skills would you bring to the team?
|
||||
|
||||
If you have any questions about the above, feel free to ask us via
|
||||
EMail at the above address.
|
||||
|
||||
|
||||
Looking for an IOCCC WWW site
|
||||
-----------------------------
|
||||
|
||||
We would like to setup an IOCCC home page somewhere out in WWW land.
|
||||
If you have a well known stable site that would be willing to give us
|
||||
access to put up some IOCCC html pages, please send EMail (say prior
|
||||
to 31 Dec 1995) to:
|
||||
|
||||
judges@toad.com (use the Subject: www site)
|
||||
|
||||
describing your site and any other appropriate comments. Thanks!
|
||||
|
||||
|
||||
A few notes regarding future contests
|
||||
-------------------------------------
|
||||
|
||||
Due to changes in the Usenix conference calendar, the 1995 contest will
|
||||
be delayed. Because there will be no Summer 1995 Usenix conference,
|
||||
the 1995 IOCCC winners will be announced at the Jan 1996 Usenix conference.
|
||||
|
||||
The 1995 contest will not open until late October 1995, and will close
|
||||
sometime around the end of December 1995. The rules for the 1995
|
||||
contest have not been formed at this time and are not expected to be
|
||||
ready for distribution until late October 1995.
|
||||
|
||||
Be sure to wait until the 1995 rules are posted before submitting entries.
|
||||
Rules differ from year to year, sometimes in significant ways.
|
||||
|
||||
Please send us comments and suggestions what we have expressed above.
|
||||
Also include anything else that you would like to see in future contests.
|
||||
Send such email to:
|
||||
|
||||
...!{sun,pacbell,uunet,pyramid}!hoptoad!judges
|
||||
judges@toad.com
|
||||
|
||||
If you use, distribute or publish these entries in some way, please drop
|
||||
us a line. We enjoy seeing who, where and how the contest is used.
|
||||
|
||||
If you have problems with any of the entries, AND YOU HAVE A FIX, please
|
||||
EMail the fix (patch file or the entire changed file) to the above address.
|
||||
|
||||
|
||||
Credits
|
||||
-------
|
||||
|
||||
We would like to thank Barbara Frezza for her role as official chef
|
||||
of the contest. Landon Noll and Larry Bassel appreciated the opportunity
|
||||
to serve as official taste testers. And as usual, the food was excellent.
|
||||
The official menu of the 1994 Obfuscated C Contest dinner:
|
||||
|
||||
Antipasto: meats, cheeses, olives, peppers, pickles, artichokes
|
||||
Soup: Cream of tomato
|
||||
Salad: spring mix
|
||||
Pasta: Linguine with wild mushrooms and Reggiano Parmesan
|
||||
Seafood: Salmon in cream sauce or lobster claws
|
||||
Vegetable: Zucchini
|
||||
Dessert: Homemade chocolate/pecan brownies, fruit
|
||||
@@ -0,0 +1,72 @@
|
||||
#define X N(a,O(h,W(f,M(c,g))),O(i,W(f,M(d,g))))
|
||||
#define A(x) r(D(x,1); O(x,-9); D(x,O(x,1)))
|
||||
#define L(x) getchar()-x
|
||||
#define R Z,Z,0,0
|
||||
#define S 0,9,6,6,6,6,6,6,9,0
|
||||
#define q D(h,0); A(f)A(g)
|
||||
#define T 0,6,1,2,2,2,2,1,6,0
|
||||
#define U 0,6,2,3,3,3,3,2,6,0
|
||||
#define C(x) ((x<1)||(x>8))
|
||||
#define F(x,y) printf(x,y);
|
||||
#define N(x,y,z) *O(*O(x,y),z)
|
||||
#define y(a,b,c) a[b][c]
|
||||
#define O(x,y) ((x)+(y))
|
||||
#define u(x) (O(0,-(x)))
|
||||
#define W(x,y) ((x)*(y))
|
||||
#define G(x) printf(x);
|
||||
#define D(x,y) (x=(y))
|
||||
#define P (random()%6)
|
||||
#define Y D(e,O(e,1))
|
||||
#define s D(f,O(f,Q))
|
||||
#define H(x) return x
|
||||
#define B(x) while(x)
|
||||
#define M(x,y) *O(x,y)
|
||||
#define z(a,b) a[b]
|
||||
#define E(x) if(x)
|
||||
#define I main(){
|
||||
#define Z 0,0,0,0
|
||||
#define t G("\n")
|
||||
#define V(x) (!x)
|
||||
#define v h,i,j,k
|
||||
#define w e,f,g
|
||||
#define J int
|
||||
#define Q u(1)
|
||||
#define p "%c"
|
||||
#define o 'A'
|
||||
#define r for
|
||||
#define n 60
|
||||
#define K do
|
||||
|
||||
J y(a,10,10)={R,R,R,R,Z,1,Q,Z,Z,Q,1,R,R,R,R,Z},y(b,10,10)={R,S,T,
|
||||
U , U , U , U , T
|
||||
, S , R } , z ( c
|
||||
, 9 ) = { Q , Q ,
|
||||
Q,0,0,1,1,1,0},z(d,9)={Q,0,1,Q,1,Q,0,1,0};I J w,v;l();r(D(e,0);O(
|
||||
e , - n ) ; Y ) {
|
||||
q D ( h , O ( h ,
|
||||
m ( f , g , 1 , 1
|
||||
)));E(h){K{G("\n?")K{D(f,L(O('A',Q)));}B(C(f));K{D(g,L('0'));}B(C
|
||||
( g ) ) ; } B ( V
|
||||
( m ( f , g , 1 ,
|
||||
Q ) ) ) ; l ( ) ;
|
||||
}q E((D(k,O(m(f,g,Q,1),P)))>h){D(h,k);D(i,f);D(j,g);}E(h&&m(i,j,Q
|
||||
, Q ) ) /***/ l /***/ ( ) ; }
|
||||
} J m (/* */v/*****/) J v ;
|
||||
{ J w ; /***/ E /***/ ( N ( a
|
||||
,h,i))H(0);E(O(k,Q))D(N(a,h,i),j);D(e,N(b,h,i));r(D(g,1);O(g,-9);
|
||||
D ( g , /***/ O /***/ ( g , 1
|
||||
) ) ) {/*****/D/* */( g , O
|
||||
( g , Q /***/ ) /***/ ) ; E (
|
||||
V(O(N(a,O(h,M(c,g)),O(i,M(d,g))),j))){r(D(f,1);V(O(X,j));D(f,O(f,
|
||||
1 ) ) ) ; E ( V (
|
||||
O ( N ( a , O ( h
|
||||
, W ( f , M ( c ,
|
||||
g))),O(i,W(f,M(d,g)))),u(j))))r(s;f;s){X=X*k;D(e,O(e,N(b,O(h,W(f,
|
||||
M ( c , g ) ) ) ,
|
||||
O ( i , W ( f , M
|
||||
( d , g ) ) ) ) )
|
||||
);}}D(g,O(g,1));}E(V(O(e,u(N(b,h,i))))){D(N(a,h,i),0);H(0);}H(e);
|
||||
} l ( ) { J f , g
|
||||
; t A ( g ) { F (
|
||||
p , O ( O ( o , g
|
||||
),Q))A(f)F("%c:",M("X O<",O(N(a,g,f),1)))t}G(" ")A(f)F("%d ",f)t}
|
||||
@@ -0,0 +1,36 @@
|
||||
Best Game:
|
||||
|
||||
Don Dodson
|
||||
AG Communication Systems
|
||||
17239 N. 19th Ave. #1003
|
||||
Phoenix, AZ 85023
|
||||
USA
|
||||
|
||||
|
||||
Judges' comments:
|
||||
|
||||
To use:
|
||||
make dodsond1
|
||||
dodsond1
|
||||
|
||||
At the prompt, try entering E3.
|
||||
|
||||
The program plays the game that the layout of the source implies.
|
||||
The source, on the other hand, implies a language along the
|
||||
lines of Lisp. :-)
|
||||
|
||||
|
||||
Selected notes from the author:
|
||||
|
||||
For each turn, the board is displayed and the player is prompted for
|
||||
a move. Enter your move as an upper-case character followed by a number.
|
||||
|
||||
The program uses a single function for 4 different purposes -- to
|
||||
determine if a valid move exists, to verify that a move is valid, to
|
||||
make a move, and to determine the value of a move.
|
||||
|
||||
Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
All Rights Reserved. Permission for personal, educational or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in writing
|
||||
from both Landon Curt Noll and Larry Bassel.
|
||||
@@ -0,0 +1,55 @@
|
||||
#include <ctype.h>
|
||||
#include <stdio.h>
|
||||
#define A { E"Your score is %d\n",j);exit(0);}
|
||||
#define B(x,y) K(x<y){p=x;x=y;y=p;}
|
||||
#define C do{p=random()%N;}F(c[p]||d[p]);
|
||||
#define D random()%N
|
||||
#define E printf(
|
||||
#define F while
|
||||
#define G int
|
||||
#define H return
|
||||
#define I for
|
||||
#define J(r,j) a[r][j]
|
||||
#define K if
|
||||
#define L else
|
||||
#define M isdigit
|
||||
#define N 30
|
||||
#define P getchar()
|
||||
G a[N][3],b[N],c[N],d[N],e[N],f[N],g[N],i,j=0,k,l=0;
|
||||
main(){m();n();A;}m(){G o;srandom(getpid());do{I(o=0;
|
||||
o<N;e[o++]=3){J(o,0)=J(o,1)=J(o,2)=-1;c[o]=d[o]=g[o]=0;
|
||||
b[o]=N*2;}r(0);s();}F(s());t();}s(){G o,p;I(o=0;o<N;o++){
|
||||
B(J(o,2),J(o,1))B(J(o,1),J(o,0))B(J(o,2),J(o,1))K(J(o,0)==-1)H(1);
|
||||
}H(0);}t(){G o,p;I(o=0;o<N;o+=8){C c[p]=1;C d[p]=1;}w(D,0);I(o=0;
|
||||
o<3;o++){do{p=D;}F(c[p]||d[p]||f[p]||!b[p]);f[p]=1;}do{k=D;}
|
||||
F((c[k])||(d[k])||(b[k]==0));}w(o,d)G o,d;{G x;b[o]=d;I(x=0;
|
||||
x<3;x++)K(b[J(o,x)]>d)w(J(o,x),d+1);}G r(x)G x;{G y,t=0,u;
|
||||
F(e[x]){u=3;(e[x])--;do{y=D;K(t++>1000)H(0);K(t%100==0)u--;}
|
||||
F((y==x)||(e[y]<=0)||(y==J(x,2))||(y==J(x,1))||(e[y]<u));(e[y])--;
|
||||
J(x,e[x])=y;J(y,e[y])=x;K(!r(y)){J(x,e[x])=J(y,e[y])=-1;(e[y])++;
|
||||
(e[x])++;}L t=0;}H(1);}n(){G r,n;char v;do{r=D;}
|
||||
F(c[r]||d[r]||(b[r]<3)||d[J(r,0)]||d[J(r,1)]||d[J(r,2)]||
|
||||
c[J(r,0)]||c[J(r,1)]||c[J(r,2)]);F(1){E"You are in room %d\n",r);
|
||||
K(f[r]){i++;E"You found an arrow\n");j+=20;f[r]=0;}K(b[r]==0){
|
||||
E"Wumpus meat\n");j-=100;A;}K(d[r]){E"You fell in a pit\n");j-=50;
|
||||
A;}K(r==k){K(i){i--;l++;j-=20;E"You are missing an arrow!\n");
|
||||
}K(l==3){E"You catch the robber and recover all 3 arrows!\n");
|
||||
i=3;j+=200;k=-1;}L{E"The robber scurries away\n");do{k=D;}
|
||||
F((c[k])||(d[k])||(b[k]==0)||(k==r));}}K(c[r]){c[r]=0;c[D]=1;r=D;
|
||||
E"The bats pick you up and drop you in room %d\n",r);j-=10;}L{
|
||||
K(b[r]<3)E"You smell a wumpus\n");
|
||||
K(d[J(r,0)]||d[J(r,1)]||d[J(r,2)])E"You feel a breeze\n");
|
||||
K(c[J(r,0)]||c[J(r,1)]||c[J(r,2)])E"You hear a rustling sound\n");
|
||||
E"Passageways to room %d, %d, and %d\n",J(r,0),J(r,1),J(r,2));
|
||||
K(!g[r]){j+=10;g[r]=1;}do{v=P;K(v=='s')q(r);K(v=='l')break;
|
||||
K(v=='i')E"You have %d arrow%c\n",i,i-1?'s':' ');K(v=='q')A;}
|
||||
F(!M(v));K(M(v)){n=v-'0';v=P;K(M(v))n=n*10+v-'0';
|
||||
K((J(r,0)==n)||(J(r,1)==n)||(J(r,2)==n))r=n;}}}}q(r)G r;{G z,n;
|
||||
char v;K(i==0){E"You have no arrows\n");H;}i--;
|
||||
E"Shoot into which rooms? ");I(z=0;z<4;z++){j-=20*z;do{v=P;
|
||||
K((v=='\n')&&(i>0)){j-=50;E"You have %d arrows\n",i);H;}}F(!M(v));
|
||||
n=v-'0';v=P;K(M(v))n=10*n+v-'0';K((J(r,0)==n)||(J(r,1)==n)||(J(r,2)
|
||||
==n)){r=n;K(b[r]==0){E"You have killed the Wumpus!\n");j+=500+i*100;
|
||||
A;}}L K(random()%3==1){E"The arrow bounces back and kills you\n");
|
||||
j-=100;A;}L{I(n=0;n<N;n++)b[n]=2*N;w(D,0);j-=100;}K(v=='\n'){j-=50;
|
||||
E"You have %d arrows\n",i);H;}}}
|
||||
@@ -0,0 +1,33 @@
|
||||
begin 755 dodsond2.gz
|
||||
M'XL( !]98BX" XU66V_;-A1^UZ]@4J0F8V60[148QC!%VMP:IT& #1@&5P^R
|
||||
M1#N,;<JE)%N*HO^^<TA9SK!@[8-)'O)<OW.1WRD=+XM$DM,XK];RE\<S[UUW
|
||||
ME>6)2NU5(F=*2W).:G)Y^'=:&)+%J9%$9>0H^:8/_2?&9:ER&C#>=.R?:.E7
|
||||
MC(QI>5JQ>BU*7HJ*5V+]BN<S25)X,I%.TA5E1_>\N:+Q9!V^O"2P,MYQ7I ]
|
||||
M4W=Y2=9&Z7Q&NYLKLGU42]G1UP3>.^J&&)D71G<77\@L-1UU2PV$0J*)"2=/
|
||||
M87<])FK6$7=$+K.]_J\ 0J+F:F_CGHR"CG@@<YG'CY&AS+L&Q??A9!3Z4]C]
|
||||
M&)<$%XG+#)<Y+LI_$H&_\)<BX-XJ4IJR&L+FL/-SWL"QOB8ISUH\P,!:)90Q
|
||||
M#E!^H2E*I:?W7$[2?C\4(U;?TM0/F,!MX+8A$R<#'D_24"2XS'$!N2GN]\=#
|
||||
MWAC,9086(1\9*L_QG#G;_IH[0V@'K+#:^T2=7M]988X>.#K8T?OW,6V] D?8
|
||||
M#1U IIL;6S_YFS;$;ZS^3+ RQ(!#U;A#LZ47H(1W88^<.[:H+OY=2R\O,[L>
|
||||
M3&UAS5H-P+I 5N^* O,B9"\O-&GW*>Q"@/=H*/43AGXE'-PKN84J <LE6B[!
|
||||
M<@F6QR"#@94L/$O8EKJSG_0AP.::&%HR% 8-E9]#E@L.=N6D#%E=B!%WQY,3
|
||||
M3&4%7HUIWN^?#8(@8!8<H(^ 0I\*X+).5T*4Z*R<5.$I/, 1KFZA^8;L%3%@
|
||||
M'5,! =D36O+PT9J%YKREE6\?H%G'],#0BF'Y[!CVSU ]3D._SSWG-9R:.P)!
|
||||
M\<;FL]$VD<;7'!N ;# HTT(=0XMA6G %R$QX.F)(8P<&+-P=!_OC$(]>O.>(
|
||||
M]QSQCH/Q*S!=VR%%(IQ0FI@T7;5CRD"5C>D,S+%:@;^.;Y86.B&1!@&3;H&/
|
||||
M\:>^& 8<&3&<L?400:^]R\._BM6ZR,A*1KGC/1&0$NS,,4VLZE:M7"[1?D36
|
||||
MJN/\ +5B.8T0"U:/J0)/( M+\ :>P>C>]Y7*,J7GG6<'5HD'PDN!;>TXXPCF
|
||||
M"\D?)00ZG4H#[ E,N3C=X!E<&#GIK!574&8VO( O,(W-'2CZ<R^>Q84Q2F8D
|
||||
MVD:5%?F9#H'C0@B#G0+^Q1:&V,$73RZPT3#SGK,TC?(,0(D7I(( BK5U.3'I
|
||||
MVM+_29D%&/WTQKM2<:%G*X0X(EN;$1<>YN!_BXCMLB-1=&JD?)8[T1]5EQ-]
|
||||
ME%#-$3%%EB\Q/QG6CU-Q>?@095DTEX!=1O)T%XEO?QBFB\J9\9T)WZFW'AS,
|
||||
M+720( @9S^V(VH@':,B-$+VLQ[Y3PUIJV6,00K1 6:15;^=DM)%@S.7^*$:C
|
||||
MRE<G@X^@X/<>Z>T4?.^Q<YO:@Z]TP_#6[K46FY->T./.L+W30A\/@KZ[!WO4
|
||||
M12&$QO2[6%X10TLP(S341-.@TS -</0]PTCPVID '6 ;ZY77.FTKUF)ZPQML
|
||||
M$(#VC\<TS?%SGN(W'HH>P<T^$G*('X!G*+7GTU_Y,\Y_VTK'S[Q%#IW%8+_I
|
||||
M'GO_GJHS&.FUZ\8WT,HL6-9RT^'BO0G((#C6+2 _@8=G :D1D5<CY94'"[5<
|
||||
MRL0VLYLR![MI]"$(^NH8YPR.#YBS,$%V?X=&0MB9AZUE R!3J,@86G@:08]A
|
||||
MU:'B#+O+E>E^9-W!/P8-R&GXR&I ;CK1H1@>W_/VP]IR-N,.OQ8W[P? -=X_
|
||||
( U4WUUP* !^
|
||||
|
||||
end
|
||||
@@ -0,0 +1,58 @@
|
||||
Most Obfuscated Packaging:
|
||||
|
||||
Don Dodson
|
||||
AG Communication Systems
|
||||
17239 N. 19th Ave. #1003
|
||||
Phoenix, AZ 85023
|
||||
USA
|
||||
|
||||
|
||||
Judges' comments:
|
||||
|
||||
To use:
|
||||
make dodsond2
|
||||
dodsond2
|
||||
|
||||
The original source file may be found in dodsond2.gz. For people
|
||||
who don't have gunzip, an un-zipped version is provided as dodsond2.c.
|
||||
|
||||
Each year people find new ways to squeeze more and more out of the
|
||||
contest rules. Next year, entries that use compression utilities
|
||||
to get around the size limit will find themselves squeezed out of
|
||||
the contest!
|
||||
|
||||
|
||||
Selected notes from the author:
|
||||
|
||||
Go searching for the Wumpus in the Caverns of Doom! But be careful...
|
||||
There are pits and bats waiting to seal your fate, as well as a
|
||||
stealthy robber lurking in the shadows. Move through the rooms by
|
||||
typing the number of the adjacent room you wish to visit. You can
|
||||
feel a breeze if there is a pit in an adjacent room. A rustling sound
|
||||
will tell you that bats are nearby. The scent of the evil Wumpus can
|
||||
be detected from 2 rooms away.
|
||||
|
||||
To win, you must find one or more arrows, determine where the Wumpus
|
||||
is, and shoot him, all without falling into a pit or becoming the
|
||||
next meal for the Wumpus. To shoot an arrow, type "s". Then give a
|
||||
list of the rooms you want to shoot into. The rooms must be
|
||||
connected in the order you list them, or else the arrow may bounce
|
||||
back and hit you. An arrow can go through as many as four rooms.
|
||||
But beware, because shooting an arrow and missing the Wumpus may
|
||||
awaken him.
|
||||
|
||||
There is a robber who waits in an unknown room. If you enter
|
||||
that room carrying an arrow, he will steal that arrow from you
|
||||
and move to a new room. If he steals all the arrows in the
|
||||
Caverns, you may catch him and recover all of them. Doing this
|
||||
gives you a bonus on your score.
|
||||
|
||||
You can quit at any time by typing 'q'. Typing 'i' will tell
|
||||
you how many arrows you are carrying. 'l' prints the description
|
||||
of the current room again.
|
||||
|
||||
Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
All Rights Reserved. Permission for personal, educational or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in writing
|
||||
from both Landon Curt Noll and Larry Bassel.
|
||||
+119
@@ -0,0 +1,119 @@
|
||||
#include <stdio.h>
|
||||
#include <curses.h>
|
||||
|
||||
char graphtab[16][16] = {
|
||||
' ', '.', '.', ',', '.', ';', ':', 'j', '\'',':', ':', ';', '\'',';', '!', '|',
|
||||
'.', '_', ':', ',', ';', ';', ';', 'j', '/', ';', ';', ';', 'j', 'j', 'j', 'j',
|
||||
'.', ',', '-', ',', 'r', '<', 'j', 'q', '/', ';', 'I', ';', '/', '|', 'I', '|',
|
||||
',', ',', 'r', 'x', '/', '/', '/', 'd', '/', '/', '/', 'd', '/', '/', '/', 'd',
|
||||
'.', ':', '\\',';', '-', '=', 'v', 'q', '\'',':', '<', '|', '\'',':', '+', '+',
|
||||
';', ';', '>', ';', '=', '=', 'g', 'g', '\'',':', 'S', 'S', '/', '/', '/', '+',
|
||||
':', '\\','\\','\\','r', '<', 'w', 'q', '/', '<', '6', '4', '/', '/', 'd', '+',
|
||||
'l', 'L', '+', 'b', 'y', '[', 'p', 'g', '/', '<', '/', '6', '/', '/', '/', '+',
|
||||
'`', ':', ':', ';', '`', '\\','\\','\\','"', ':', ':', ';', '`', '\\','Y', 'T',
|
||||
';', ';', ';', ';', '`', '2', '>', '\\',':', '=', ';', ';', '?', '?', ']', ']',
|
||||
':', ';', ';', ';', '>', '2', '>', '\\','F', ';', 'O', ';', '7', '?', ']', '7',
|
||||
';', ';', ';', ';', '?', '2', '>', 'b', ';', ';', ';', ';', '?', '?', ']', '#',
|
||||
'\'','\\','\\','\\','`', '\\','\\','\\','\'','\'','<', '5', '"', '"', 'V', 'q',
|
||||
';', '\\','\\','\\','`', '=', '\\','\\','\'','\'','5', '5', '"', '?', 'g', 'g',
|
||||
'I', 'L', 'L', 'L', 'D', '\\','b', 'f', 'F', '[', '[', '[', 'P', '?', '#', 'M',
|
||||
'|', '|', '|', '|', '|', '#', '+', '#', 'T', '[', 'F', 'F', 'P', '?', 'P', 'M'
|
||||
};
|
||||
|
||||
#define BITROWS 96
|
||||
#define BITCOLS 160
|
||||
#define SCREENROWS 23 /* one less so doesn't scroll off screen */
|
||||
#define SCREENCOLS 79 /* one less so doesn't scroll off screen */
|
||||
char framebuffer[BITROWS][BITCOLS];
|
||||
|
||||
#define BITSET(r, c) framebuffer[r][c] = 1;
|
||||
#define BITCLR(r, c) framebuffer[r][c] = 0;
|
||||
|
||||
double f();
|
||||
double atof();
|
||||
|
||||
FILE *d;
|
||||
|
||||
main(argc, argv)
|
||||
char **argv;
|
||||
{
|
||||
int i, a, b, c, r;
|
||||
char labbuf[100];
|
||||
|
||||
for (i=0; i<48; i++) {
|
||||
r = scanf("%x %x %x", &a, &b, &c);
|
||||
bs(i, 0, a);
|
||||
bs(i, 16, b);
|
||||
bs(i, 32, c);
|
||||
}
|
||||
|
||||
bitshow();
|
||||
}
|
||||
|
||||
bs(r, c, v)
|
||||
int r, c, v;
|
||||
{
|
||||
int j, q;
|
||||
|
||||
for (j=16; j>0; j--) {
|
||||
q = v&0x8000;
|
||||
v <<= 1;
|
||||
if (q) /* !q for white on black */
|
||||
BITSET(r, c);
|
||||
c++;
|
||||
}
|
||||
}
|
||||
|
||||
bitshow()
|
||||
{
|
||||
bitshow2(); /* or bitshow1() for bigger version */
|
||||
}
|
||||
|
||||
/* Show bits with 1x2 resolution, 48x80 on screen */
|
||||
bitshow1()
|
||||
{
|
||||
int r, c;
|
||||
int basei, basej;
|
||||
int i, j;
|
||||
char ch;
|
||||
|
||||
for (r=0; r<SCREENROWS; r++) {
|
||||
for (c=0; c<SCREENCOLS; c++) {
|
||||
basei = 2*r;
|
||||
basej = 1*c;
|
||||
i = (framebuffer[basei+0][basej+0] << 1)
|
||||
+ (framebuffer[basei+1][basej+0] << 0);
|
||||
ch = " ,\"M"[i];
|
||||
/* mvaddch(r, c, ch); */
|
||||
putchar (ch);
|
||||
}
|
||||
putchar('\n');
|
||||
}
|
||||
}
|
||||
|
||||
/* Show bits with 2x4 resolution, 96x160 on screen */
|
||||
bitshow2()
|
||||
{
|
||||
int r, c;
|
||||
int basei, basej;
|
||||
int i, j;
|
||||
char ch;
|
||||
|
||||
for (r=0; r<SCREENROWS; r++) {
|
||||
for (c=0; c<SCREENCOLS; c++) {
|
||||
basei = 4*r;
|
||||
basej = 2*c;
|
||||
i = (framebuffer[basei+0][basej+0] << 3)
|
||||
+ (framebuffer[basei+1][basej+0] << 2)
|
||||
+ (framebuffer[basei+2][basej+0] << 1)
|
||||
+ (framebuffer[basei+3][basej+0] << 0);
|
||||
j = (framebuffer[basei+0][basej+1] << 3)
|
||||
+ (framebuffer[basei+1][basej+1] << 2)
|
||||
+ (framebuffer[basei+2][basej+1] << 1)
|
||||
+ (framebuffer[basei+3][basej+1] << 0);
|
||||
ch = graphtab[i][j];
|
||||
putchar(ch);
|
||||
}
|
||||
putchar ('\n');
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,48 @@
|
||||
0001 EBE0 0000
|
||||
0001 FF7C 0000
|
||||
0003 FFFE 0000
|
||||
000F FE01 0000
|
||||
000F F000 8000
|
||||
001F 8000 4000
|
||||
001E 0000 2000
|
||||
003C 0000 0000
|
||||
0038 0000 1000
|
||||
0038 0000 1000
|
||||
0030 0000 0000
|
||||
0030 0000 0000
|
||||
003A 0000 0800
|
||||
0030 0000 0800
|
||||
0014 0000 0C00
|
||||
0011 7C1F FC00
|
||||
001F DF7A F800
|
||||
000F 7F7A BC00
|
||||
001F FFFF FC00
|
||||
0037 B727 9400
|
||||
0006 AB38 B400
|
||||
0016 BA16 9000
|
||||
0012 8218 2400
|
||||
0017 060D D400
|
||||
0008 FCA7 0000
|
||||
000A BBF8 5000
|
||||
0012 2FFA 0800
|
||||
000C 87F8 2000
|
||||
0004 77FA 8000
|
||||
000D 1FFE 3000
|
||||
0006 7FFE 9000
|
||||
000F 7FFF 5800
|
||||
0005 7F7F 5000
|
||||
0007 EA0B D000
|
||||
0007 EBFB E000
|
||||
000F EFEB 2000
|
||||
0017 EBEB E000
|
||||
0017 FA8B D400
|
||||
000F FFE7 D000
|
||||
0005 FFAF D300
|
||||
0037 F5A3 E000
|
||||
0007 FFFF A100
|
||||
0047 FFC3 E000
|
||||
0093 FB7F E8C0
|
||||
008B FFCF A080
|
||||
0093 F65F F080
|
||||
0003 DFFB 5040
|
||||
0103 FEAF E800
|
||||
+677
@@ -0,0 +1,677 @@
|
||||
11th International Obfuscated C Code Contest Guidelines, Hints and Comments
|
||||
|
||||
Copyright (c) Landon Curt Noll & Larry Bassel, 1994.
|
||||
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.
|
||||
|
||||
Changes from the original 1993 rules are denoted by change bars. ---> |
|
||||
|
||||
|
||||
WHAT IS NEW IN 1994: |
|
||||
|
||||
It now appears that most ANSI C compilers allow indexes to be of |
|
||||
non-integral type. Unlike last year, we now allow one to use |
|
||||
constructs such as: |
|
||||
|
||||
int h; |
|
||||
char *i; |
|
||||
... |
|
||||
h[i] = (h+3)["string"]; |
|
||||
|
||||
The ---build--- section may use "gcc" or "cc" commands. However, your |
|
||||
entry should be compilable with any ANSI C compiler. You should not |
|
||||
depend on a gcc specific feature. |
|
||||
|
||||
The order of your entry's sections must be the same as the order of |
|
||||
the rule template or the example below. |
|
||||
|
||||
We have added a new rule regarding rule abuse. The guidelines expand |
|
||||
on the rule abuse aspect of the contest. |
|
||||
|
||||
A suggestion regarding VTxxx/ANSI escape sequences has been given. |
|
||||
|
||||
|
||||
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
|
||||
* convert ANSI 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.
|
||||
|
||||
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.
|
||||
|
||||
People who are considering to just use some complex mathematical |
|
||||
function or state machine to spell out something such as "hello, |
|
||||
world!" may want to try and be more creative. |
|
||||
|
||||
Ultra-obfuscated programs are in some cases some cases easier to |
|
||||
deobfuscate than subtly-obfuscated programs. Consider using |
|
||||
misleading or subtitle tricks layered on top of or under an |
|
||||
appropriate level of obfuscation. |
|
||||
|
||||
Programs that use VTxxx/ANSI sequences that are NOT limited to a |
|
||||
specific terminal brand and that can also work in a standard xterm |
|
||||
are considered portable. |
|
||||
|
||||
|
||||
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
|
||||
|
||||
When declaring local or global variables, you should declare the type: |
|
||||
|
||||
int this_is_ok; |
|
||||
this_is_not; <-- don't use such implicit type declaration |
|
||||
|
||||
We suggest that you compile your entry with an ANSI C compiler. If you
|
||||
must use non-ANSI C, such as K&R C, you must avoid areas that result in
|
||||
compile/link errors for ANSI C compilers.
|
||||
|
||||
If your entry uses functions that have a variable number of
|
||||
arguments, be careful. Systems implement va_list as a wide variety
|
||||
of ways. Because of this, a number of operations using va_list are
|
||||
not portable and must not be used:
|
||||
|
||||
* assigning a non-va_list variable to/from a va_list variable
|
||||
* casting a non-va_list variable into/from a va_list variable
|
||||
* passing a va_list variable to a function expecting a non-va_list arg
|
||||
* passing a non-va_list variable to a function expecting a va_list arg
|
||||
* performing arithmetic on va_list variables
|
||||
* using va_list as a structure or union
|
||||
|
||||
In particular, do not treat va_list variables as if they were a char **'s.
|
||||
|
||||
Avoid using <varargs.h>. Use <stdarg.h> instead.
|
||||
|
||||
If you use C preprocessor directives (#define, #if, #ifdef, ...),
|
||||
the leading '#' must be the first character on a line. While some
|
||||
C preprocessors allow whitespace the leading '#', many do not.
|
||||
|
||||
Because the exit() function returns void on some systems, entries
|
||||
must not assume that it returns an int.
|
||||
|
||||
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 in our opinion.
|
||||
|
||||
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 like Un*x systems |
|
||||
* 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 want to get away from source that is simply a compact blob of |
|
||||
characters. To help, we give a break to source that contains |
|
||||
whitespace, and in certain cases ; { or } characters. While the |
|
||||
number of characters excluding whitespace (tab, space, newline), |
|
||||
and excluding any ; { or } followed by either whitespace or end of |
|
||||
file, must be <= 1536, the total size may be less than 3217 |
|
||||
bytes. This means that one may use "free of charge" up to 1681 |
|
||||
bytes of whitespace, or ; { or } followed by either whitespace |
|
||||
or end of file. |
|
||||
|
||||
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!
|
||||
|
||||
We tend to dislike writable strings. That is, we want to avoid: |
|
||||
|
||||
char *T = "So many primes, so little time!"; |
|
||||
... |
|
||||
T[14] = ';'; |
|
||||
|
||||
You may use writable strings if you really must. If you do depend |
|
||||
on them, you must say do in the ---remark--- section. |
|
||||
|
||||
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 X11r4 (or
|
||||
earlier), so try to target X11r5 without requiring X11r5. 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.
|
||||
|
||||
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!
|
||||
|
||||
|
||||
ABUSING THE RULES: |
|
||||
|
||||
Legal abuse of the rules is somewhat encouraged. Legal rule abuse may |
|
||||
involve, but is not limited to, doing things that are technically |
|
||||
allowed by the rules and yet do not fit the spirit of what we |
|
||||
intended to be submitted. |
|
||||
|
||||
Legal rule abuse is encouraged to help promote creativity. Rule |
|
||||
abuse entries, regardless of if they receive an award, result in |
|
||||
changes to the next year's rules and guidelines. |
|
||||
|
||||
Legal abuse of the rules is NOT an invitation to violate the |
|
||||
rules. An entry that violates the rules in the opinion of the |
|
||||
judges, WILL be disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL |
|
||||
OF RISK! If you have an entry that might otherwise be interesting, |
|
||||
you might want to submit two versions; one that does not abuse the |
|
||||
rules and one that does. |
|
||||
|
||||
If you intend to abuse the rules, indicate so in the ---remark--- |
|
||||
section. You must try to justify why you consider your rule abuse |
|
||||
to be allowed under the rules. That is, you must plead your case |
|
||||
as to why your entry is valid. Humor and/or creativity help plead |
|
||||
a case. |
|
||||
|
||||
Abusing the entry format tends to annoy us more than amuse us. |
|
||||
|
||||
We are often asked why the contest rules and guidelines seem to |
|
||||
strange or contain mistakes, flaws or grammatical errors. |
|
||||
One reason is that we sometimes make genuine mistakes. But in many |
|
||||
cases such problems, flaws or areas of confusion are deliberate. |
|
||||
Changes to rules and guidelines in response to a rule abuses, are |
|
||||
done in a minimal fashion. Often the we will deliberately leave |
|
||||
behind holes (or introduce new ones) so that future rule abuse may |
|
||||
continue.
|
||||
|
||||
At the risk of stating the obvious, this contest is a parity the |
|
||||
software development process. The rules and guidelines are |
|
||||
only a small part of the overall contest. Even so, one may think |
|
||||
the contest rule and guideline process as a parody of the sometimes |
|
||||
tragic mismatch between what a customer (or marketing) wants and |
|
||||
what engineering delivers. |
|
||||
|
||||
|
||||
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: 1994
|
||||
fix: n
|
||||
title: chonglab
|
||||
entry: 0
|
||||
date: Thu Mar 3 13:23:14 1994
|
||||
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!
|
||||
---author---
|
||||
name: Landon Curt Noll
|
||||
org: IOCCC Judging Group
|
||||
addr: Toad Hall
|
||||
PO Box 170608
|
||||
San Francisco, California
|
||||
94117-0608
|
||||
USA
|
||||
email: {chongo,noll}@{toad,sgi}.com
|
||||
anon: n
|
||||
---author---
|
||||
name: Larry Bassel
|
||||
org: IOCCC Judging Group
|
||||
addr: Toad Hall
|
||||
PO Box 170608
|
||||
San Francisco, California
|
||||
94117-0608
|
||||
USA
|
||||
email: hoptoad!sun!lab
|
||||
lab@sun.com
|
||||
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*"DEN(#$Y.3(L(&]N92!P97)S;VX@=&]L9"!U<R!T:&%T('1H97D@
|
||||
M86-T=6%L;'D@9&5C;V1E9"!T:&ES(&9I;&4N("!);@HQ.3DS(&$@9F5W(&UO
|
||||
M<F4@9&ED('1H92!S86UE+B`@22!W;VYD97(@:&]W(&UA;GD@=VEL;"!D;R!I
|
||||
-="!T:&ES('EE87(_"@``
|
||||
`
|
||||
end
|
||||
---build---
|
||||
begin 444 build
|
||||
99V-C("UA;G-I('!R;V<N8R`M;R!P<F]G"@``
|
||||
`
|
||||
end
|
||||
---program---
|
||||
begin 444 prog.c
|
||||
M;6%I;B@I"GL*(VEF("%D969I;F5D*$Y/5%]!7U)%1TE35$52141?5D]415)?
|
||||
M24Y?4U5.3EE604Q%7T-!3$E&3U).24%?55-!*0H@("`@<')I;G1F*"),86YD
|
||||
M;VX@3F]L;"!W87,@96QE8W1E9"!T;R!A(#0@>65A<B!T97)M(&]N('1H92!3
|
||||
M=6YN>79A;&5<;B(I.PH@("`@<')I;G1F*")#:71Y($-O=6YC:6PN("!4:&%N
|
||||
M:R!Y;W4A7&Y<;B(I.PHC96YD:68*("`@('!R:6YT9B@B4W5N;GEV86QE(')E
|
||||
M;&%T960@14UA:6P@;6%Y(&)E('-E;G0@=&\Z(&YO;&Q`;F-D+F-O;2Y<;EQN
|
||||
M(BD["@H@("`@<')I;G1F*")!="!T:&4@=&EM92!T:&ES('=A<R!W<FET=&5N
|
||||
M+"!3=6YN>79A;&4@:&%D(&YO="!Y970@;V)T86EN961<;B(I.PH@("`@<')I
|
||||
M;G1F*")A(&1O;6%I;BP@8G5T('!L86YN960@=&\@9&\@<V\@:6X@9G5T=7)E
|
||||
@+EQN(BD["B`@("!E>&ET*#(Q-S`Q("4@,3(W*3L*?0H`
|
||||
`
|
||||
end
|
||||
---end---
|
||||
|
||||
Your entry's sections must be the same order as in the above example. |
|
||||
|
||||
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 |
|
||||
|
||||
or rm -f special_src.c |
|
||||
cp prog.c special_src.c
|
||||
cc special_src.c -o special_name
|
||||
|
||||
or rm -f 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 ---info--- 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.
|
||||
|
||||
Typically the ---build--- command will contain a "cc" command. |
|
||||
It is also ok to use a "gcc" command (and gcc args). However keep |
|
||||
in mind that your entry should be compilable by any standard ANSI C |
|
||||
compiler and thus should not depend on a special gcc feature. |
|
||||
|
||||
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 us to see it. (Our decoding tools are |
|
||||
not AI progs!) If you need tell the the something, put it in |
|
||||
the ---remark--- section, or send a EMail to the us at: |
|
||||
|
||||
...!{apple,pyramid,sun,uunet}!hoptoad!judges (not the address for
|
||||
judges@toad.com 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:
|
||||
|
||||
Fri Apr 01 00:47:00 1994 |
|
||||
|
||||
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
|
||||
judges@toad.com submitting entries)
|
||||
|
||||
Questions and comments about the contest are welcome. Comments about |
|
||||
confusing rules and guidelines are also 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.
|
||||
|
||||
|
||||
chongo <Landon Curt Noll> /\cc/\ {chongo,noll}@{toad,sgi}.com
|
||||
Larry Bassel lab@sun.com
|
||||
@@ -0,0 +1,197 @@
|
||||
#include <stdio.h>
|
||||
/*
|
||||
* Obfuscated version is simpler but can't display labels.
|
||||
*/
|
||||
|
||||
char graphtab[] =
|
||||
" ..,.;:j'::;';!|._:,;;;j/;;;jjjj.,-,r<jq/;I;/|I|,,rx///d///d///d.:\\;-=vq':<|':++;;>;==gg':SS///+:\\\\\\r<wq/<64//d+lL+by[pg/</6///+`::;`\\\\\\\"::;`\\YT;;;;`2>\\:=;;??]]:;;;>2>\\F;O;7?]7;;;;?2>b;;;;??]#'\\\\\\`\\\\\\''<5\"\"Vq;\\\\\\`=\\\\''55\"?ggILLLD\\bfF[[[P?#M|||||#+#T[FFP?PM'"
|
||||
;
|
||||
|
||||
#define BITROWS 96
|
||||
#define BITCOLS 160
|
||||
#define SCREENROWS 23 /* one less so doesn't scroll off screen */
|
||||
#define SCREENCOLS 79 /* one less so doesn't scroll off screen */
|
||||
char framebuffer[BITROWS][BITCOLS];
|
||||
char screen[SCREENROWS][SCREENCOLS];
|
||||
|
||||
#define BITSET(r, c) framebuffer[r][c] = 1;
|
||||
#define BITCLR(r, c) framebuffer[r][c] = 0;
|
||||
|
||||
double f();
|
||||
double atof();
|
||||
|
||||
/* row and column boundaries in frame buffer */
|
||||
int minr= 10;
|
||||
int maxr= 80;
|
||||
int minc= 20;
|
||||
int maxc=150;
|
||||
|
||||
/* x and y boundaries in formula */
|
||||
double maxy= 500;
|
||||
double miny=-500;
|
||||
double maxx= 10;
|
||||
double minx= -20;
|
||||
|
||||
double three, two, one, zero; /* coefficients */
|
||||
|
||||
double xbase, ybase;
|
||||
|
||||
main(argc, argv)
|
||||
char **argv;
|
||||
{
|
||||
double x, y;
|
||||
char labbuf[100];
|
||||
|
||||
if (argc < 5) {
|
||||
printf("Usage: %s cube square linear constant\n", argv[0]);
|
||||
exit(1);
|
||||
}
|
||||
|
||||
/* Arguments are four coefficients to polynomial */
|
||||
three = atof(argv[1]);
|
||||
two = atof(argv[2]);
|
||||
one = atof(argv[3]);
|
||||
zero = atof(argv[4]);
|
||||
|
||||
gbox(minr,maxr,minc-2,maxc+2);
|
||||
|
||||
plotinit();
|
||||
for (x=minx; x<=maxx; x += .05) {
|
||||
fplot(x, f(x));
|
||||
}
|
||||
|
||||
bitshow();
|
||||
|
||||
hlabel(minr-4, (maxc+minc)/2 - 10, "A Cubic Function");
|
||||
sprintf(labbuf, "y=%gx^3+%gx^2+%gx+%g", three, two, one, zero);
|
||||
vlabel(12, 5, labbuf);
|
||||
hlabel(maxr+4, (maxc+minc)/2, "x");
|
||||
|
||||
sprintf(labbuf, "%g", minx);
|
||||
hlabel(maxr+4, minc, labbuf);
|
||||
sprintf(labbuf, "%g", maxx);
|
||||
hlabel(maxr+4, maxc-strlen(labbuf)*2, labbuf);
|
||||
|
||||
sprintf(labbuf, "%g", miny);
|
||||
vlabel(minr+4, minc-4, labbuf);
|
||||
sprintf(labbuf, "%g", maxy);
|
||||
vlabel(maxr-strlen(labbuf)*4, minc-4, labbuf);
|
||||
|
||||
/* bigshow(20, 55, 0, 70); */
|
||||
srefresh();
|
||||
}
|
||||
|
||||
double f(x)
|
||||
double x;
|
||||
{
|
||||
double y;
|
||||
|
||||
y = three*x*x*x + two*x*x + one*x + zero;
|
||||
return y;
|
||||
}
|
||||
|
||||
fplot(x, y)
|
||||
double x, y;
|
||||
{
|
||||
int r, c;
|
||||
|
||||
r = (maxy - y) * ybase + minr;
|
||||
c = (x - minx) * xbase + minc;
|
||||
if (r >= minr && r <= maxr && c >= minc && c <= maxc)
|
||||
BITSET(r, c);
|
||||
}
|
||||
|
||||
hlabel(r, c, lab)
|
||||
int r, c;
|
||||
char *lab;
|
||||
{
|
||||
r = r/4;
|
||||
c = c/2;
|
||||
while (*lab)
|
||||
screen[r][c++] = *lab++;
|
||||
}
|
||||
|
||||
vlabel(r, c, lab)
|
||||
int r, c;
|
||||
char *lab;
|
||||
{
|
||||
r = r/4;
|
||||
c = c/2;
|
||||
while (*lab && r<maxr)
|
||||
screen[r++][c] = *lab++;
|
||||
}
|
||||
|
||||
plotinit()
|
||||
{
|
||||
ybase = (maxr-minr)/(maxy-miny);
|
||||
xbase = (maxc-minc)/(maxx-minx);
|
||||
}
|
||||
|
||||
/* Draw the frame buffer onto the screen, 96x180 mode, 4x2 per character */
|
||||
bitshow()
|
||||
{
|
||||
int r, c;
|
||||
int basei, basej;
|
||||
int i, j;
|
||||
char ch;
|
||||
|
||||
for (r=0; r<SCREENROWS; r++)
|
||||
for (c=0; c<SCREENCOLS; c++) {
|
||||
basei = 4*r;
|
||||
basej = 2*c;
|
||||
i = (framebuffer[basei+0][basej+0] << 3)
|
||||
+ (framebuffer[basei+1][basej+0] << 2)
|
||||
+ (framebuffer[basei+2][basej+0] << 1)
|
||||
+ (framebuffer[basei+3][basej+0] << 0);
|
||||
j = (framebuffer[basei+0][basej+1] << 3)
|
||||
+ (framebuffer[basei+1][basej+1] << 2)
|
||||
+ (framebuffer[basei+2][basej+1] << 1)
|
||||
+ (framebuffer[basei+3][basej+1] << 0);
|
||||
ch = graphtab[i*16+j];
|
||||
screen[r][c] = ch;
|
||||
}
|
||||
}
|
||||
|
||||
/* Show all the bits separately */
|
||||
bigshow(rbase, rmax, cbase, cmax)
|
||||
{
|
||||
int i, j;
|
||||
char ch;
|
||||
|
||||
for (i=rbase; i<=rmax; i++) {
|
||||
for (j=cbase; j<=cmax; j++) {
|
||||
if (framebuffer[i-rbase][j-cbase])
|
||||
ch = 'X';
|
||||
else
|
||||
ch = ' ';
|
||||
putchar(ch);
|
||||
}
|
||||
putchar('\n');
|
||||
}
|
||||
}
|
||||
|
||||
/* Draw the box around the graph */
|
||||
gbox(rmin, rmax, cmin, cmax)
|
||||
{
|
||||
int i;
|
||||
for (i=rmin; i<=rmax; i++) {
|
||||
BITSET(i, cmin);
|
||||
BITSET(i, cmax);
|
||||
}
|
||||
|
||||
for (i=cmin; i<=cmax; i++) {
|
||||
BITSET(rmin, i);
|
||||
BITSET(rmax, i);
|
||||
}
|
||||
}
|
||||
|
||||
srefresh()
|
||||
{
|
||||
int r, c;
|
||||
|
||||
for (r=0; r<SCREENROWS; r++) {
|
||||
for (c=0; c<SCREENCOLS; c++)
|
||||
putchar(screen[r][c]);
|
||||
putchar('\n');
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,35 @@
|
||||
#define S(r, c) f[r][c] = 1;
|
||||
|
||||
char f[96][160]; main(argc, argv) char **argv; { double x, y, atof(); int
|
||||
r ,
|
||||
c ,
|
||||
bi ,
|
||||
bj ,
|
||||
i ; for (i=10; i<=80 ;
|
||||
i ++) { S(i, 18); S(i, 152) ;
|
||||
} for (i=18; i<=152; i++) { S(10, i); S(80, i) ;
|
||||
} for (x=-20; x<=10; x += .05) {
|
||||
y =atof(argv[1]) *
|
||||
x * x * x + atof(argv [
|
||||
2 ])*x*x+atof(argv[3]) *
|
||||
x + atof(argv[4]) ;
|
||||
r = (500 - y)*.07+10 ;
|
||||
c =(x+20)*4.33333 +
|
||||
20 ; if(r>=10 && r<=80 && c
|
||||
>= 20 && c<=150) S
|
||||
( r, c); } for (
|
||||
r =0; r < 24; r ++
|
||||
) for (c=0; c <80; c++) { bi =
|
||||
4 *r;bj=2*c; i=(((f[bi][bj]<< 3
|
||||
) +(f[bi+1][bj]<<2)+(f[bi+2][bj]<<1)+(f[bi +
|
||||
3 ][bj]<<0))*16+ (f[bi][bj+1]<<3)+( f
|
||||
[ bi+1][bj+1]<<2)+(f[bi+2][bj +
|
||||
1 ]<<1)+(f[bi+3][bj+ 1
|
||||
] <<0)+1)*(c<79 )
|
||||
; putchar (
|
||||
|
||||
"\n ..,.;:j'::;';!|._:,;;;j/;;;jjjj.,-,r<jq/;I;/|I|,,rx///d///d///d.:\\;\
|
||||
-=vq':<|':++;;>;==gg':SS///+:\\\\\\r<wq/<64//d+lL+by[pg/</6///+`::;`\\\\\
|
||||
\\\"::;`\\YT;;;;`2>\\:=;;??]]:;;;>2>\\F;O;7?]7;;;;?2>b;;;;??]#'\\\\\\`\\\
|
||||
\\\\''<5\"\"Vq;\\\\\\`=\\\\''55\"?ggILLLD\\bfF[[[P?#M|||||#+#T[FFP?PM'"
|
||||
[i]); } }
|
||||
@@ -0,0 +1,86 @@
|
||||
Best Utility:
|
||||
|
||||
Mark Horton
|
||||
AT&T Bell Labs
|
||||
Rm 1H-117
|
||||
6200 E Broad St.
|
||||
Columbus OH 43213
|
||||
USA
|
||||
|
||||
|
||||
Judges' comments:
|
||||
|
||||
To use:
|
||||
make horton
|
||||
./horton A B C D
|
||||
|
||||
A, B, C, D are numeric arguments (try 3 2 1 0).
|
||||
|
||||
Try to figure out how this program prints, for a given slope, the
|
||||
right character. And for extra credit, try to figure out which
|
||||
character is at the bottom on this hint file. :-)
|
||||
|
||||
This confuses cb greatly. See gtplot.c for an unobfuscated/enhanced
|
||||
version. To compile it:
|
||||
|
||||
make horton.alt
|
||||
./horton.alt A B C D
|
||||
|
||||
A, B, C, D are numeric arguments (try 3 2 1 0).
|
||||
|
||||
|
||||
Selected notes from the author:
|
||||
|
||||
Run it with any 4 numeric arguments, e.g. prog 3 2 1 0. Play with the
|
||||
numbers to get a pleasing result, or use it for your high school algebra
|
||||
class.
|
||||
|
||||
SPOILER:
|
||||
|
||||
As should be obvious from 20 feet away, the program is a cubic plotter.
|
||||
It plots against certain artists, splattering their cubes with graphs
|
||||
of their cubic equations. Those dastardly arguments are mere coefficients,
|
||||
cogs in the wheels of the grand plot to overthrow the cubics!
|
||||
|
||||
Oh, by the way, it uses a self-contained graphtab and frame buffer.
|
||||
It's easily modified to graph *any* 96x160 bitmap on a dumb terminal.
|
||||
|
||||
See the gtface program for another example. Try:
|
||||
|
||||
make gtface
|
||||
./gtface < gtface.data
|
||||
|
||||
For more information, see
|
||||
Using GraphTab; USENIX ;login:
|
||||
Sept/Oct 1992; Pages 28-31
|
||||
|
||||
MMMM,M,MM"MM,,,
|
||||
,,MMMMMMMMM"""""""",
|
||||
,MMMMM""" ",
|
||||
,MMM" "
|
||||
MMM M
|
||||
MM
|
||||
MM" " M
|
||||
M " , ,,,,, ,,,,,,,,,MM
|
||||
"MMMM"M,MMMMM MMMM M M"MMM,
|
||||
,M"MMMM"MM"MMM""M""MMMM""M"M
|
||||
, MM M M,M M" "M",, M "M "
|
||||
M ,M," ,M "M, ,,,", M
|
||||
M , M"MMM",,M,M,,""" , ,
|
||||
",," , " "MMMMMMMM " , "
|
||||
,M , ""M,MMMMMMMM,M " ,,
|
||||
,MM, MMMMMMMMMMMMMM,", M,
|
||||
M,M,MM"M"M" """M"MM,M M
|
||||
,MMMMMM M,MMMMM"M MM""M
|
||||
M MMMMMM,M M"M"" M MMMM", ,
|
||||
"M"MMMMMMMMMM"M ,MMMMM M ,,
|
||||
"" MMMMMMM,M,MM,M,,,MMM"M ,
|
||||
," , "MMMMMMM"MM"M,,,,MMMMM , ,,
|
||||
M ," MMMMMM"MM""M ,MMMMM,M, M
|
||||
, MMMM,MMMM"M"M"M,MM,M,", "
|
||||
|
||||
Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
All Rights Reserved. Permission for personal, educational or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in writing
|
||||
from both Landon Curt Noll and Larry Bassel.
|
||||
+85
@@ -0,0 +1,85 @@
|
||||
#include<stdio.h>
|
||||
#include<stdlib.h>
|
||||
#define f (sizeof(int))
|
||||
|
||||
int i,j,k,l,m,*t,*u,*v;
|
||||
int r(x)int x;{return (rand()/256)%x;}
|
||||
void p(x,y)int *x,y;{for(i=y;--i;k=x[i],x[i]=x[j],x[j]=k)j=r(i+1);}
|
||||
|
||||
void o(n,a,q,d)int n,d,*a,*q;
|
||||
{
|
||||
for(m=r(2)?n:1,t=q,l=n/2,i=n;
|
||||
i--&&(i!=l||i--);
|
||||
*(t++)=i);
|
||||
for(p(q,n-1),q[n-1]=l,u=a,i=j=0;
|
||||
i<n*n;
|
||||
u[i] =q[j]*m,j++,++i%n||(++j,u+=d),j>=n&&(j-=n));
|
||||
for(p(q,n-1),u=a,m=n+1-m,i=0,j=n-1;
|
||||
i<n*n;
|
||||
u[i]+=q[j]*m,j++,++i%n||(--j,u+=d),j>=n&&(j-=n));
|
||||
}
|
||||
|
||||
void s(n,a,q,d)int n,d,*a,*q;
|
||||
{
|
||||
for(q[1]=3-(*q=r(n)),q[3]=3-(q[2]=1^q[r(2)]),t=a,i=n,m=3*r(2);
|
||||
i--;
|
||||
t+=d)
|
||||
for(j=n;
|
||||
j--;
|
||||
t++[0]=q[j^(i&m)^(i/2)]);
|
||||
for(q[1]=3-(*q=r(n)),q[3]=3-(q[2]=1^q[r(2)]),t=a,i=n,m=3-m;
|
||||
i--;
|
||||
t+=d)
|
||||
for(j=n;
|
||||
j--;
|
||||
t++[0]+=q[j^(i&m)^(i/2)]*4);
|
||||
}
|
||||
|
||||
void e(n,a,q,d)int n,d,*a,*q;
|
||||
{
|
||||
int h,i,k,l,z,g=n/2;
|
||||
void (*m)();
|
||||
for((m=g!=4?g%2?o:e:s)(g,a,q,g+d),m(g,a+g,q,g+d),l=(n+d)*g,u=a,i=g;
|
||||
i--;
|
||||
u+=d)
|
||||
for(j=n;
|
||||
j--;
|
||||
j<g&&(*u+=g*2*g),l[u]=*u+(j<g?-1:3)*g*g,u++);
|
||||
for(i=g; i--; q[i]=i<g/2);
|
||||
for(h=k=(g+1)/2,v=a; v<a+n; v+=g){
|
||||
for(u=v,i=g; i--; u+=g+d){
|
||||
if(p(q,g),q[z=g-i-1])
|
||||
if(k)k--;
|
||||
else
|
||||
for(j=g;q[--j]||(q[j]=1,q[z]=0););
|
||||
else
|
||||
if(k>i)
|
||||
for(j=g;!q[--j]||(k--,q[z]=1,q[j]=0););
|
||||
if(q[i])
|
||||
if(h)h--;
|
||||
else
|
||||
for(j=g;q[--j]||j==z||(q[j]=1,q[i]=0););
|
||||
else
|
||||
if(h>i||(g==3&&h&&(k==2||i==z)))
|
||||
for(j=g;!q[--j]||j==z||(h--,i==z&&k--,q[i]=1,q[j]=0););
|
||||
for(t=q,j=g;j--;u++)
|
||||
if(0[t++])z=*u,*u=u[l],u[l]=z;
|
||||
}
|
||||
for(h=k=g/2-g%2,i=g;i--;q[i]=i<h);
|
||||
}
|
||||
}
|
||||
|
||||
int main(c,v)
|
||||
int c;
|
||||
char **v;
|
||||
{
|
||||
int n,*a,*b;
|
||||
srand(getpid());
|
||||
if(c<2 || sscanf(1[v],"%d",&n)!=1 || n<3) n=5;
|
||||
if(!((a=(int*)malloc(n*n*f))&&(b=(int*)malloc(n*f))))
|
||||
return perror("malloc"),1;
|
||||
(n!=4?n%2?o:e:s)(n,a,b,0);
|
||||
for(i=0;i<n*n;i++)
|
||||
printf("%4d%c",a[i]+1,(i+1)%n?' ':'\n');
|
||||
return 0;
|
||||
}
|
||||
@@ -0,0 +1,80 @@
|
||||
Most Obfuscated Algorithm:
|
||||
|
||||
Ian Collier
|
||||
Oxford University
|
||||
57 Wyndham Avenue (home address)
|
||||
BOLTON
|
||||
BL3 4LG
|
||||
England
|
||||
|
||||
|
||||
Judges' comments:
|
||||
|
||||
To use:
|
||||
make imc
|
||||
./imc INTEGER
|
||||
|
||||
Try:
|
||||
./imc 3
|
||||
./imc 3
|
||||
./imc 4
|
||||
./imc 4
|
||||
./imc 6
|
||||
|
||||
This entry's algorithm is as magic as its output!
|
||||
|
||||
|
||||
Selected notes from the author:
|
||||
|
||||
This program may be compiled with an ANSI or K&R compiler. A few
|
||||
harmless warnings are displayed only if "gcc -Wall" is used.
|
||||
|
||||
This entry is really a set of library functions, but an example
|
||||
main function has been added so that the library can be tested. If
|
||||
the program appears too large, consider that functions o and s can
|
||||
each be separated from the rest of the program (except for the short
|
||||
functions p and r, which they require) and used alone. However, the
|
||||
main part of the program is the function e, which does require all the
|
||||
other functions (apart from main).
|
||||
|
||||
The program should be supplied with an integer parameter. If no
|
||||
parameter or an invalid parameter is given, then 5 is assumed. The
|
||||
maximum parameter is determined only by the amount of cpu time, virtual
|
||||
memory and display (or file) space available.
|
||||
|
||||
SPOILER:
|
||||
|
||||
OK, so you have probably seen magic square printers before. But what
|
||||
about one that deals with even sizes as well as odd ones, or one that
|
||||
prints out a different one each time (or attempts to, at any rate)?
|
||||
|
||||
I have formatted the important functions o, s and e to show how useful
|
||||
the word "for" is, and (in function e) how useful the words "if" and
|
||||
"else" are. In fact, hardly anything happens that isn't in one of these
|
||||
instructions. I did this in order to simplify the code - the algorithms
|
||||
used to make the random squares are quite complex without being shrouded
|
||||
in obfuscated code! :-) Incidentally, I was surprised to find out how
|
||||
useful the exclusive-or operator was while writing function s.
|
||||
|
||||
Here are the descriptions of the functions in the library:
|
||||
|
||||
o(n,a,q,d): makes a magic square of order n when n is odd and at least 3.
|
||||
s(n,a,q,d): makes a magic square of order n when n equals 4.
|
||||
e(n,a,q,d): makes a magic square of order n when n is even and at least 6.
|
||||
|
||||
In the above, a (of type int*) points to an area of memory in which
|
||||
the magic square will be stored and q (also of type int*) points to
|
||||
an area of memory of length at least n*sizeof(int) bytes which can be
|
||||
used as a work space. Both a and q must be allocated by the caller.
|
||||
The integer parameter d, usually zero, indicates the length of a gap
|
||||
which will be left between adjacent rows of the magic square.
|
||||
|
||||
The square which is returned will (or should) be a permutation of the
|
||||
numbers 1 to n*n in which all rows and columns and the two diagonals
|
||||
add up to n*(n*n+1)/2.
|
||||
|
||||
Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
All Rights Reserved. Permission for personal, educational or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in writing
|
||||
from both Landon Curt Noll and Larry Bassel.
|
||||
@@ -0,0 +1 @@
|
||||
int _,O,__??('}'??);main(){while(O?gets((rand()%O++?':':_)+__)||puts(&__??(_??))&_:srand(time((O+++_)))||O);}
|
||||
@@ -0,0 +1,34 @@
|
||||
Best One-liner:
|
||||
|
||||
Laurion Burchall
|
||||
Brown University
|
||||
Unit 4641
|
||||
Providence RI 02912-4641
|
||||
USA
|
||||
|
||||
|
||||
Judges' comments:
|
||||
|
||||
To use:
|
||||
make ldb
|
||||
./ldb < file
|
||||
|
||||
Try:
|
||||
./ldb < /etc/passwd
|
||||
|
||||
Tri-graphs are natural obfuscators. Most C-beautifiers become
|
||||
C-uglifiers because they don't handle them correctly.
|
||||
|
||||
Can you figure out how it prints a given random line from stdin?
|
||||
|
||||
|
||||
Selected notes from the author:
|
||||
|
||||
All input lines must be under 232 characters long. The compiling
|
||||
platform should be ASCII based.
|
||||
|
||||
Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
All Rights Reserved. Permission for personal, educational or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in writing
|
||||
from both Landon Curt Noll and Larry Bassel.
|
||||
+1212
File diff suppressed because it is too large.
Load diff
+214
@@ -0,0 +1,214 @@
|
||||
11th International Obfuscated C Code Contest Rules
|
||||
|
||||
Copyright (c) Landon Curt Noll & Larry Bassel, 1994.
|
||||
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.
|
||||
|
||||
Obfuscate: tr.v. -cated, -cating, -cates. 1. a. To render obscure.
|
||||
b. To darken. 2. To confuse: his emotions obfuscated his
|
||||
judgment. [LLat. obfuscare, to darken : ob(intensive) +
|
||||
Lat. fuscare, to darken < fuscus, dark.] -obfuscation n.
|
||||
obfuscatory adj.
|
||||
|
||||
|
||||
GOALS OF THE CONTEST:
|
||||
|
||||
* To write the most Obscure/Obfuscated C program under the rules below.
|
||||
* To show the importance of programming style, in an ironic way.
|
||||
* To stress C compilers with unusual code.
|
||||
* To illustrate some of the subtleties of the C language.
|
||||
* To provide a safe forum for poor C code. :-)
|
||||
|
||||
|
||||
NOTE: Changes from the original 1993 rules are denoted by change bars. ---> |
|
||||
|
||||
|
||||
RULES:
|
||||
|
||||
To help us with the volume of entries, we ask that you follow these rules:
|
||||
|
||||
1) Your entry must be a complete program.
|
||||
|
||||
2) Your entry must be <= 3217 bytes in length. The number of characters
|
||||
excluding whitespace (tab, space, newline), and excluding any ; { or }
|
||||
followed by either whitespace or end of file, must be <= 1536.
|
||||
|
||||
3) Your entry must be submitted in the following format:
|
||||
|
||||
---entry---
|
||||
rule: 1994
|
||||
fix: y or n (n => this is a new entry, y => this replaces an older entry)
|
||||
title: title of entry (see comments below)
|
||||
entry: Entry number from 0 to 7 inclusive (your 1st entry should by 0)
|
||||
date: Date/time of submission in UTC (see comments below)
|
||||
host: Machine(s) and OS(s) under which your entry was tested
|
||||
Use tab indented lines if needed
|
||||
---remark---
|
||||
Place remarks about this entry in this section. It would be helpful if
|
||||
you were to indent your remarks with 4 spaces, though it is not a
|
||||
requirement. Also, if possible, try to avoid going beyond the 79th
|
||||
column. Blank lines are permitted.
|
||||
---author---
|
||||
name: your name
|
||||
org: School/Company/Organization
|
||||
addr: postal address
|
||||
use tab indented lines to continue
|
||||
don't forget to include the country
|
||||
email: EMail address from a well known site or registered domain.
|
||||
If you give several forms, list them on separate tab indented lines.
|
||||
anon: y or n (y => remain anonymous, n => ok to publish this info)
|
||||
---info---
|
||||
If your program needs an info file, place a uuencoded copy of it in
|
||||
this section. In the case of multiple info files, use multiple info
|
||||
sections. If your entry does not need a info file, skip this section.
|
||||
---build---
|
||||
Place a uuencoded copy of the command(s) used to compile/build your program
|
||||
in this section. It must uudecode into a file named 'build'. The resulting
|
||||
file must be 255 bytes or less.
|
||||
---program---
|
||||
Place a uuencoded copy of your program in this section. It must uudecode
|
||||
into a file named is 'prog.c'. The resulting file must follow rule #2.
|
||||
---end---
|
||||
|
||||
Regarding the above format:
|
||||
|
||||
* The title must match the expression: [a-zA-Z0-9_=][a-zA-Z0-9_=+-]*
|
||||
and must be 1 to 12 characters in length.
|
||||
|
||||
It is suggested, but not required, that the title should
|
||||
incorporate your username; in the case of multiple authors,
|
||||
consider using parts of the usernames of the authors.
|
||||
|
||||
* The date in the ---entry--- section should be given with respect
|
||||
to UTC. The format of the date should be as returned by asctime()
|
||||
using the C locale. (see guidelines for more info)
|
||||
|
||||
* You may correct/revise a previously submitted entry by sending
|
||||
it to the contest email address. Be sure to set 'fix' in the
|
||||
---entry--- section to 'y'. The corrected entry must use the same |
|
||||
title and entry number as submittion that is being corrected. Be
|
||||
sure that you note the resubmittion in the ---remark--- as well.
|
||||
|
||||
* With the exception of the header, all text outside of the above
|
||||
format may be ignored by the judges. If you need tell the judges
|
||||
something, put it in the ---remark--- section, or send a separate
|
||||
EMail message to the judges.
|
||||
|
||||
* Information from the ---author--- section will be published unless
|
||||
'y' was given to the respective author's 'anon' line.
|
||||
|
||||
* To credit multiple authors, include an ---author--- section for
|
||||
each author. Each should start with ---author--- line, and
|
||||
should be found between the ---entry--- and ---build--- sections.
|
||||
|
||||
* The entry's remarks should include:
|
||||
- note if this entry is a re-submission of a previous entry.
|
||||
- what this program does
|
||||
- how to run the program (sample args or input)
|
||||
- special compile or execution instructions, if any
|
||||
- special filename requirements (see rule 4 and 5)
|
||||
- information about any ---info--- files |
|
||||
- why you think the program is obfuscated
|
||||
- any other remarks (humorous or otherwise)
|
||||
|
||||
* Do not rot13 your entry's remarks. You may suggest that certain
|
||||
portions of your remarks be rot13ed if your entry wins an award.
|
||||
|
||||
* Info files should be used only to supplement your entry. They
|
||||
should not be required to exist.
|
||||
|
||||
* If your entry does not need an info file, skip the ---info--- |
|
||||
section. If your entry needs multiple info files, use multiple
|
||||
---info--- sections, one per info file. You should describe
|
||||
each info file in the ---remark--- section.
|
||||
|
||||
* Your sections must in the same order as in the above template. |
|
||||
|
||||
4) If your entry is selected as a winner, it will be modified as follows:
|
||||
|
||||
'build' is incorporated into a makefile, and 'build' is removed
|
||||
'prog.c' is renamed to your entry's title, followed by an optional
|
||||
digit, followed by '.c'
|
||||
your entry is compiled into a file with the name of your entry's
|
||||
title, possibly followed by a digit
|
||||
|
||||
If your entry requires that a build file exist, state so in your
|
||||
entry's remark section. The makefile will be arranged to execute a
|
||||
build shell script containing the 'build' information. The name of
|
||||
this build shell script will be your entry's title, possibly followed
|
||||
by a digit, followed by '.sh'.
|
||||
|
||||
If needed, your entry's remarks should indicate how your entry must
|
||||
be changed in order to deal with the new filenames.
|
||||
|
||||
5) The build file, the source and the resulting executable should be
|
||||
treated as read-only files. If your entry needs to modify these files,
|
||||
it should make and modify a copy of the appropriate file. If this
|
||||
occurs, state so in your entry's remarks.
|
||||
|
||||
6) Entries that cannot be compiled by an ANSI C compiler will be rejected.
|
||||
Use of common C (K&R + extensions) is permitted, as long as it does not
|
||||
cause compile errors for ANSI C compilers.
|
||||
|
||||
7) The program must be of original work. All programs must be in the
|
||||
public domain. All copyrighted programs will be rejected.
|
||||
|
||||
8) Entries must be received prior to 8-May-94 23:59 UTC. (UTC is |
|
||||
essentially equivalent to Greenwich Mean Time) EMail your entries to:
|
||||
|
||||
...!{apple,pyramid,sun,uunet}!hoptoad!obfuscate
|
||||
obfuscate@toad.com
|
||||
|
||||
We request that your message use the subject 'ioccc entry'.
|
||||
|
||||
If possible, we request that you hold off on EMailing your entries
|
||||
until 4-Mar-94 12:00 UTC. Early entries will be accepted, however. |
|
||||
We will attempt to email a confirmation to the sender of any entry |
|
||||
received after 4-Mar-94 12:00 UTC and before the close of the contest. |
|
||||
|
||||
9) Each person may submit up to 8 entries per contest year. Each entry
|
||||
must be sent in a separate EMail letter.
|
||||
|
||||
10) Entries requiring human interaction to be built are not allowed.
|
||||
Making an entry must produce a file (or files) which may be executed. |
|
||||
|
||||
11) Programs that require special privileges (setuid, setgid, super-user,
|
||||
special owner or group) are not allowed.
|
||||
|
||||
12) Legal abuse of the rules is somewhat encouraged. An entry that, in |
|
||||
the opinion of the judges, violates the rules will be disqualified. |
|
||||
Entries that attempt to abuse the rules must try to justify why |
|
||||
their rule abuse is legal in the ---remark--- section. |
|
||||
|
||||
|
||||
FOR MORE INFORMATION:
|
||||
|
||||
The Judging will be done by Landon Noll and Larry Bassel. Please send
|
||||
questions or comments about the contest, to:
|
||||
|
||||
...!{apple,pyramid,sun,uunet}!hoptoad!judges (not the address for |
|
||||
judges@toad.com submitting entries) |
|
||||
|
||||
Comments about confusing rules and guidelines are also 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/\ {chongo,noll}@{toad,sgi}.com
|
||||
Larry Bassel lab@sun.com
|
||||
@@ -0,0 +1,52 @@
|
||||
#include <stdio.h>
|
||||
int r=0,x,y=0, /*
|
||||
nt /
|
||||
c
|
||||
lx /\ / \ /|\ /|\
|
||||
u, \/ \\/ \-/ \ /
|
||||
dn ]
|
||||
e= ||| /|\ /\ /\ = p p
|
||||
0 \/ \ / ||| \/ f f f r r
|
||||
<, tw t s s i i
|
||||
sy || /|\ /\ i eh e e c n n
|
||||
t= /- \ / ||| n li l e a t t
|
||||
d0 ||| t ll l {< k n f f
|
||||
i, || /|\ /|\ (e s ( fr ( f ( (
|
||||
o _ ||\ \ / \-/ tu s( t usw o; i s ( " "
|
||||
. || - / c [[ tg rv [th rx=f t " % \
|
||||
h mh111 de{l) +di (+'( d+% c n+
|
||||
> aa000 itte; > +il x+ n inc " "+
|
||||
/ ir000[ns[nytyrrne<=)'<xn," , );
|
||||
*/ n = 0 ;
|
||||
main ( ) {
|
||||
char v [
|
||||
100 ] , s;
|
||||
int t[100 ] ,
|
||||
u[100 ] ; u
|
||||
[ 0
|
||||
]=ftell(stdin ) ;
|
||||
while(gets (v ) )
|
||||
{t [ r ]=
|
||||
strlen (
|
||||
v);y=
|
||||
t[ r ]
|
||||
>y ? t [
|
||||
r ] : y;
|
||||
u[++r ] =
|
||||
ftell(stdin ) ; }
|
||||
while ( n
|
||||
< y )
|
||||
{for(x=0 ; x
|
||||
<r;x++) { s
|
||||
=' ' ;
|
||||
if(n< t [
|
||||
x ] ) {
|
||||
fseek(stdin ,u [ x ]
|
||||
+n , 0 ) ;
|
||||
scanf("%c", &
|
||||
s )
|
||||
; }
|
||||
printf("%c", s )
|
||||
; }
|
||||
printf("\n"); n
|
||||
++ ; } }
|
||||
@@ -0,0 +1,76 @@
|
||||
Best Layout:
|
||||
|
||||
Mark Schnitzius
|
||||
ISX Corporation
|
||||
1165 Northchase Pkwy, Suite 120
|
||||
Marietta, GA 30067
|
||||
USA
|
||||
|
||||
|
||||
Judges' comments:
|
||||
|
||||
To use:
|
||||
make schnitzi
|
||||
./schnitzi < textfile
|
||||
|
||||
Try:
|
||||
./schnitzi < /etc/motd
|
||||
./schnitzi < schnitzi.c
|
||||
|
||||
Compare the output of the program with its source. Sure the output
|
||||
is different, but there is more than meets the diff's eye. Can you
|
||||
find out why?
|
||||
|
||||
|
||||
Selected notes from the author:
|
||||
|
||||
SPOILER:
|
||||
|
||||
This is a program which takes any text file as input and 'flips'
|
||||
the input file along a diagonal running from the top left corner
|
||||
down to the bottom right. In other words, the first row in the
|
||||
file ends up written down the first column of the result, the
|
||||
second row is written down the second column, etc. The program
|
||||
is run by redirecting a file into the executable on the command
|
||||
line; for instance, for the included 'info' file, the program
|
||||
would be run as follows:
|
||||
|
||||
schnitzi < info
|
||||
|
||||
The program generates interesting results when its source file is
|
||||
used as input:
|
||||
|
||||
schnitzi < schnitzi.c
|
||||
|
||||
The result of this command is a program which does the exact same
|
||||
thing -- in other words, both the program and the "flipped"
|
||||
version of itself work identically (you'll need to redirect the
|
||||
output of the above command into a separate file and compile it).
|
||||
You might notice some differences in the flipped version, though.
|
||||
First off, a secret message becomes visible that was not visible
|
||||
in the original program. Also, much of the code shows up in
|
||||
different places in the flipped program than it appeared in the
|
||||
first program. My first version of this program was perfectly
|
||||
symmetrical along the diagonal, but later found out there were
|
||||
interesting ways to break the symmetry. The best way to see this
|
||||
is to load both the original and flipped versions of the program
|
||||
into an editor and switch back and forth between them rapidly.
|
||||
|
||||
C tokens longer than a character (such as "main") proved difficult
|
||||
to use in both the original and flipped versions (after flipping,
|
||||
they show up as a string of single letters on successive lines).
|
||||
However, I found that it was possible to get around this through
|
||||
a few well-placed comments. An earlier version of this program
|
||||
used nearly every single-character token in the "shared" area;
|
||||
however, it proved to be too large for contest guidelines (although
|
||||
the code itself is only about 300 characters, the extra whitespace
|
||||
needed to pad it put it over the limit -- it nearly filled a 79 by
|
||||
79 area, adding up to over 4000 total characters). I will provide
|
||||
this other version to anyone interested -- contact me by email
|
||||
at schnitzi@east.isx.com.
|
||||
|
||||
Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
All Rights Reserved. Permission for personal, educational or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in writing
|
||||
from both Landon Curt Noll and Larry Bassel.
|
||||
@@ -0,0 +1,60 @@
|
||||
#include <stdio.h>
|
||||
/*MLSPXPMPVPOQN
|
||||
POPJLVMMQNQNPSPYPXLRP
|
||||
XMTJMLSPXPMPVPOQNPOPJLVMN
|
||||
QSPWPOPXLRPXMTJMLNPOPPPSPXPOP
|
||||
JLYPRLTPVLUPVLWPVLXPVLVPSLJLUQP
|
||||
PJQLQSPXPNQPPRLTPVL*/main(){int K/*
|
||||
PUOUPWOV*/,L/*WPVLXPVLKPUOVPWOSLU*/,M
|
||||
/*PPPPVPOQMQRPR*/=0;FILE/*TPSLUMWQT*/ *
|
||||
J/*MPRPKPLQ*/; J= fopen(__FILE__
|
||||
/*T*/,"r");for (;( L/*KPUOWOWMUQ
|
||||
LLOLMPULWLWL WLW LWLWLWLWLWLW
|
||||
LWLWLULVOXP LLV LLLOLMPULOL
|
||||
MMNP*/=getc (J) )!= -1;L/*
|
||||
OLWLRMMQUL VOX PLLVLLLMQO
|
||||
PMPYPXPNP MQL LVLLLWPSP
|
||||
XPOQNQOPMQ LLV LTj*/>='J'
|
||||
&&L/*LRPYP OQL QMQLLVLLL
|
||||
OLMQVOXPL LVL LLVOe*/<=
|
||||
'J'+15&&( (M= !M/*MMMQMV
|
||||
OJMMMMMU OOL NPU MPMOM
|
||||
UMRNOLMQV OJM MMMMRMLLW
|
||||
QUMTJSPX PNQ JLLPUOWO
|
||||
WMUQJMVL JMV L*/)?K/*
|
||||
MQMV*/=L: putchar (K/*deMN
|
||||
MaVbcLKM KMV Le*/-'J'
|
||||
/*MWQUMTJ WPK PSPXPR*/
|
||||
|(L/*PQV LMPSLSPXPNQ*/- 'J'<<4))
|
||||
));exit( 0);}/*LPQUMMPR PKPLQJLT
|
||||
LTLJLMPU MTJUQMPRPKPLQ JLNPUONM
|
||||
JMWOVLTL OPVLPPWM
|
||||
PMUMTJNQ SPWPOPYO
|
||||
NQJLQPUM TJPNSNVN
|
||||
ONJLTLRP VLTLSPUM
|
||||
TJQQRPSP VPOPJLRL
|
||||
WLWLPPJLP LPLJLKLJQ
|
||||
SPJQOPRL NPSLJLPL
|
||||
PLJLKLPPY PLQUPRLSL
|
||||
SLUMTJRPW MPPNPYPJQ
|
||||
OPXPRLPMW LPPVMVMKM
|
||||
VLLLKPLLSL UMSPWMPPNP
|
||||
YPJQOPXPR LRLPMWLPP
|
||||
VMVMKMSLUL KMVLLLLQLL
|
||||
SLUMTJPPYP LQRLUMUMSL
|
||||
UQSPPPRLPPS LUQPPQPOPNQ
|
||||
MQRLNPVLNMJM VLSPSLUMNPUO
|
||||
MQNQLQVPOPXPR LNPSLWLKMWOWM
|
||||
QLVOJMQLUMTJSP PPRLTLNPWMWMQL
|
||||
JMQLULPPSLUQMQJQLQSPXPNQPPRLTLMPVLLLOLM
|
||||
QVOXPLLVLNPULKMSLUMYPRLMQNQNPYPOQNQVL
|
||||
PMVLPMWLPPVLNPULKMVLJMSLWQTJSPPPRLT
|
||||
LNPXMQLJMQLULPPSLYPRLRPVLOMVLNP
|
||||
VLJMVLJMSLWQOPVPMQOPUQNQSPWPO
|
||||
PRLPLQPSLUMOPWMKPMQMPNQSP
|
||||
WPOPRLVPYPMPKPVPNQSPW
|
||||
POPRLPLQPSLSLUM
|
||||
|
||||
TJPPYPLQRLPQWMKMUMPQVMPMUMPQULULSLYPRLRPVLPQKLWMKMPLPLPQKLWMPMWLKMVLPQ
|
||||
ULQLJMQLVLKPNQYPSPRLOPULLPUOPQWOSLVLPQSLMQVPOPOPJQRLKMSLUMWQWQWQTJTJ*/
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
Most Well Rounded Obfuscation:
|
||||
|
||||
Andrew T. Shapiro
|
||||
CSES/CIRES University of Colorado
|
||||
Campus Box 216
|
||||
Boulder, CO 80309-0216
|
||||
USA
|
||||
|
||||
|
||||
Judges' comments:
|
||||
|
||||
To use:
|
||||
make shapiro
|
||||
./shapiro &
|
||||
|
||||
This entry has many different levels of obfuscation, and yet the
|
||||
source file is self documenting. :-)
|
||||
|
||||
From time to time, run ps and look at the new processes.
|
||||
|
||||
See shapiro.info for more information in the internals of this program.
|
||||
The file shapiro.alt contains a non-obfuscated version of this program.
|
||||
|
||||
|
||||
Selected notes from the author:
|
||||
|
||||
The basic theme (pun) of this program is:
|
||||
|
||||
"This time (everything) is not where it should be."
|
||||
~~~~
|
||||
My entry (shapiro.c) is mostly comment, formatted in the shape of a
|
||||
clock. If you strip out the comments and look at the code you will
|
||||
quickly realize that the comments were the important part and that
|
||||
the code does very little (see pun above). It writes (to stdout)
|
||||
another C program (shapiro_t2.c). This is the first level of
|
||||
obfuscation.
|
||||
|
||||
The second program (shapiro_t2.c if you use the build/make file)
|
||||
prints a clock in the upper right hand corner of your VTxxx/ANSI
|
||||
display.
|
||||
|
||||
Most of the surface obfuscation in the second program (shapiro_t2.c)
|
||||
was an attempt to make it as small as possible. You should be able to
|
||||
see around this with cb(1) and some more intelligent variable names.
|
||||
Once you get past this you will realize that the third level of
|
||||
obfuscation is a six member client/server hierarchy.
|
||||
(See the second info file for a detailed description of the algorithm.)
|
||||
|
||||
Lint complains about: precedence confusion, K may be used before set,
|
||||
main() returns random value to invocation environment, value type used
|
||||
inconsistently, value type declared inconsistently, function argument
|
||||
( number ) used inconsistently, function returns value which is always
|
||||
ignored, function returns value which is sometimes ignored
|
||||
All of which are harmless (famous last words).
|
||||
|
||||
This may or may not work on non ASCII systems (I could not find one to
|
||||
test it on.)
|
||||
|
||||
Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
All Rights Reserved. Permission for personal, educational or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in writing
|
||||
from both Landon Curt Noll and Larry Bassel.
|
||||
|
||||
@@ -0,0 +1,109 @@
|
||||
HINTS
|
||||
~~~~~
|
||||
For the first program (prog.c):
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
This is a very simple program:
|
||||
|
||||
1. #include <stdio.h>
|
||||
2. main()
|
||||
3. {
|
||||
4. int K,L,M=0;
|
||||
5. FILE *J;
|
||||
6. J=fopen(__FILE__,"r");
|
||||
7. for(;
|
||||
8. (L=getc(J))!=-1;
|
||||
9. L>='J'&&L<='J'+15 &&
|
||||
10. ((M=!M)?K=L:putchar(K-'J'|(L-'J'<<4)))
|
||||
11. );
|
||||
12. exit(0)}
|
||||
|
||||
Lines 1-5 are basic stuff. Line 6 opens the source code for input. Line 7
|
||||
is the loop. Line 8 is read in each character in the file (placed in L)
|
||||
while not EOF(-1). Line 9 is an if expression which filters out all
|
||||
characters not between J and J + 15. Line 10 uses M to execute two different
|
||||
paths the first just stores the character in K. The second path combines
|
||||
the last two characters read in as high and low nibbles of a byte and
|
||||
outputs them. In effect this is a very poor ASCII to binary decoder.
|
||||
The last line is necessary so that make will not stop when it executes
|
||||
this program.
|
||||
|
||||
The second program is encoded into this format and then included (mostly)
|
||||
as a comment.
|
||||
|
||||
Notice that it is impossible to write this program while leaving 16
|
||||
contiguous ASCII characters free for the encoding. Because of this the
|
||||
second program is mostly included as a comment. However, some of the
|
||||
characters of the encoded program are also source code for the decoder.
|
||||
|
||||
For the second program (time.c):
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
1 #include <stdio.h>
|
||||
2 #include <time.h>
|
||||
3 #define o(j,k,m,n,l) {fprintf(j,a[k],m,n,a[l]);fflush(j);}
|
||||
4 char *a[]={"%c+------------+\n","%c+%3d %-8s+\n","seconds","minutes",
|
||||
5 "hours","%s\n","\0337\033[%d;65;H%s\0338"};
|
||||
6 int b[]={0,0,17,14,11,0};
|
||||
7 main(v,c)
|
||||
8 int v;
|
||||
9 char ** c;
|
||||
10 {
|
||||
11 char d[40],*e,f=6;
|
||||
12 time_t g;
|
||||
13 FILE *h,*i;
|
||||
14 while (--f && !pipe(d) && !fork());
|
||||
15 h=fdopen(6-f<<1,"a");
|
||||
16 i=fdopen((6-f<<1)+1,"r");
|
||||
17 for(;;){
|
||||
18 if(f){
|
||||
19 fgets(d,40,i);
|
||||
20 d[strlen(d)-1]='\0';
|
||||
21 if(*d=='0'+f){ sprintf(*c,"%s\n",d+1); o(stdout,6,6-f,d+1,0) }
|
||||
22 if(*d>'0'+f) o(h,5,d,0,0)
|
||||
23 }else{
|
||||
24 time(&g);
|
||||
25 e=asctime(localtime(&g));
|
||||
26 for(v=1;v<6;v++) o(h,v!=1&&v!=6-1,v+'0',atoi(e+b[v]),v)
|
||||
27 sleep(1);
|
||||
28 }}}
|
||||
|
||||
Lines 1 and 2 have to be. Think of 'o' in line 3 as send message with
|
||||
j,k and m as where, format and what. Lines 4 and 5 are all the text
|
||||
strings. Line 6 is the offsets into the time string for the hours,
|
||||
minutes and seconds. Lines 7-13 are basic stuff. Line 14 is the crux of
|
||||
the biscuit. 14 forks off 'f'(6) processes each of which is connected to
|
||||
the ones above and below it with a Unix pipe. It was too difficult to
|
||||
recover the actual fd numbers for the pipe ends in line 14 so I regenerate
|
||||
them and fdopen them (for use with the standard C library functions) on lines
|
||||
15 and 16. Now we have six almost identical processes. Each of which has
|
||||
two files open h and i (up and down). The only difference in each process
|
||||
is the value of f (0 <= f < 6). The five processes where f !=0 are the
|
||||
slave processes and f == 0 is the master. Line 17 says we are going to do
|
||||
this forever. Lines 18 and 23 differentiate between the master and the
|
||||
slaves.
|
||||
|
||||
Lines 19 to 22 are the slave code. Here we read in a line of text from
|
||||
i (down)(line 19) and remove the end of line char (line 20). On line
|
||||
21 if this message is for us (if the first character is our number, f,
|
||||
in ASCII) we do two things:
|
||||
1. We copy the text of the message to *c which is really argv[0].
|
||||
If you are on the correct flavor of Unix this will change the output of
|
||||
the ps(1) command to the string we just put there.
|
||||
2. We send the message (not including the number) to stdout with
|
||||
format number 6 ("\0337\033[%d;65;H%s\0338") If you can read VTxxx
|
||||
(and I read books printed as ANSI/VTxxx codes for fun :-) you know this
|
||||
is the sequence for: remember where we are,
|
||||
go somewhere else,
|
||||
print the message,
|
||||
and return to where we started.
|
||||
Line 22 says if this message is not for us (the number is bigger than ours)
|
||||
send it to h (up).
|
||||
|
||||
Lines 24 to 27 are the master code. Here we get the time and convert it
|
||||
to an ASCII format (lines 24 and 25). Then on line 26 we build and send
|
||||
each of the messages for the slaves. The message uses a different control
|
||||
string for the different slaves. For the first and last slave the message
|
||||
text is just "%c+------------+\n" (slave number, text, newline.) For the
|
||||
other slaves it is "%c+%3d %-8s+\n" (slave number, number, units, newline).
|
||||
The slave number is v+'0'. The number (if used) is atoi(e+b[v]) and the
|
||||
units are just the string in the slave number position.
|
||||
|
||||
Whitespace-only changes.
@@ -0,0 +1,43 @@
|
||||
Worst Abuse of the Rules:
|
||||
|
||||
Szymon Rusinkiewicz
|
||||
Massachusetts Institute of Technology
|
||||
305 Memorial Dr., Room 005B
|
||||
Cambridge, Ma 02139
|
||||
USA
|
||||
|
||||
|
||||
Judges' comments:
|
||||
|
||||
To use:
|
||||
make smr
|
||||
./smr
|
||||
|
||||
Nearly every year, one or more people would submit what they claimed
|
||||
was the world's smallest self reproducing program. While the sizes
|
||||
of these submissions varied, a quick glance would reveal that they
|
||||
were too big, until this entry came along.
|
||||
|
||||
While strictly speaking, smr.c is not a valid C program, it is
|
||||
not an invalid C program either! Some C compilers will compile
|
||||
an empty file into a program that does nothing. But even if your
|
||||
compiler can't, the build instructions supplied with this entry
|
||||
will produce an executable file. On most systems, the stdout
|
||||
from the executable will exactly match original source.
|
||||
|
||||
In the future, the contest rules will specify a minimum size
|
||||
that is one character larger than this entry, forever eliminating
|
||||
this sort of program from contest. After all, how many variations
|
||||
can one make on this entry? :-)
|
||||
|
||||
|
||||
Selected notes from the author:
|
||||
|
||||
The world's smallest self-replicating program. Guaranteed.
|
||||
Produces a listing of itself on stdout.
|
||||
|
||||
Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
All Rights Reserved. Permission for personal, educational or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in writing
|
||||
from both Landon Curt Noll and Larry Bassel.
|
||||
+175
@@ -0,0 +1,175 @@
|
||||
#include <X11/Xlib.h>
|
||||
#define M typedef
|
||||
#define N( a)=r=(a)+j
|
||||
#define S f(; G; )D[B[H=i[--G]]=F+=F<p]++
|
||||
#define f for
|
||||
#define g [H]
|
||||
#define Z f(H=0; H<j; H++)
|
||||
#define X H < j && h g<j*4
|
||||
#define E h g + j*(T+a g>V)*2
|
||||
#define o b F; b G = 0; c H = 0; c R
|
||||
|
||||
M int b;
|
||||
M unsigned c;
|
||||
M unsigned char *d;
|
||||
M XPoint *e;
|
||||
M void _;
|
||||
short *a;
|
||||
b *h, *i, j, k, l, m, n, p, V;
|
||||
c T;
|
||||
b O;
|
||||
d A, B, C;
|
||||
_ *q, *r, *calloc ();
|
||||
e s, t;
|
||||
Window u, v;
|
||||
GC x[256];
|
||||
b D[256];
|
||||
b w, y, z;
|
||||
_
|
||||
Q (b F)
|
||||
{
|
||||
XMapWindow (q, v = XCreateSimpleWindow (q, XRootWindow (q, z = XDefaultScreen (q)), !v * n, 0, n, n, 0, 0, 0));
|
||||
XSelectInput (q, v, F);
|
||||
}
|
||||
_
|
||||
P ()
|
||||
{
|
||||
C N (h N (i N (a N (s N (t N (A N (B = calloc (C - B + 256, 1))))))));
|
||||
}
|
||||
_
|
||||
J ()
|
||||
{
|
||||
o;
|
||||
R = w % 5;
|
||||
F = G = m;
|
||||
V = n * !R - 1;
|
||||
Z
|
||||
{
|
||||
h g = l + (R - 4 ? R - 2 ? R - 3 ? (a g = 2 * (F * F - G * G) / m) + 4 * F * G / m * n + (F * F > j / 4 - G * G) * j * !R * 8 : G + F * n : (G * G - F * F) / m * n + 2 * F * G / m : (G - F * F / n) + F * n);
|
||||
(s g.x = m - F--, s + H)->y = m - G;
|
||||
F = F + m ? F : (G--, m);
|
||||
}
|
||||
}
|
||||
_
|
||||
K ()
|
||||
{
|
||||
b H;
|
||||
c R;
|
||||
Z D[B g = X ? (R = E) < j ? (A[R] < p) + A[R] : 1 : 0]++;
|
||||
}
|
||||
_
|
||||
I (d F)
|
||||
{
|
||||
F || gets (F = B);
|
||||
y = atoi (F);
|
||||
}
|
||||
_
|
||||
Y ()
|
||||
{
|
||||
o;
|
||||
K ();
|
||||
f (H = k + l;
|
||||
X && (F = B g) < p;
|
||||
H = E)
|
||||
{
|
||||
D[F]--;
|
||||
B[i[G++] = H] = p;
|
||||
}
|
||||
if (H >= j)
|
||||
F = 1;
|
||||
S;
|
||||
}
|
||||
_
|
||||
L ()
|
||||
{
|
||||
o;
|
||||
Z B g = 0;
|
||||
O = -1;
|
||||
Z
|
||||
{
|
||||
f (;
|
||||
X && !(F = B g);
|
||||
H = E) B[i[G++] = H] = p;
|
||||
S;
|
||||
}
|
||||
}
|
||||
_
|
||||
U ()
|
||||
{
|
||||
o;
|
||||
e L[256], W = t;
|
||||
f (H = 0;
|
||||
H < y;
|
||||
H++)
|
||||
{
|
||||
L g = W;
|
||||
W += D g;
|
||||
}
|
||||
Z if (A g - B g)
|
||||
*L[B g]++ = s g;
|
||||
{
|
||||
XMotionEvent *R = r = t;
|
||||
W = t;
|
||||
f (H = 0;
|
||||
H < y;
|
||||
H++)
|
||||
{
|
||||
XDrawPoints (q, v, x g, W, L g - W, CoordModeOrigin);
|
||||
W += D g;
|
||||
D g = 0;
|
||||
}
|
||||
f (F = k;
|
||||
XPending (q) + !++O;
|
||||
R->type - ButtonPress ? (k = (T = R->x) + R->y * n - l) : (O = -42)) XNextEvent (q, r = R);
|
||||
Z h g += k - F;
|
||||
}
|
||||
}
|
||||
_
|
||||
main (b i, d * W)
|
||||
{
|
||||
o;
|
||||
if (i > 2)
|
||||
{
|
||||
P ();
|
||||
I (*++W);
|
||||
w = y;
|
||||
I (*++W);
|
||||
n = y * 2;
|
||||
j = n * n;
|
||||
P ();
|
||||
m = y;
|
||||
l = j / 2 + m;
|
||||
q = XOpenDisplay (0);
|
||||
Q (0);
|
||||
u = v;
|
||||
Q (PointerMotionMask | ButtonPressMask);
|
||||
I (0);
|
||||
p = y;
|
||||
{
|
||||
XColor F;
|
||||
Colormap G;
|
||||
f (H = 0;
|
||||
H < p;
|
||||
H++)
|
||||
{
|
||||
I (0);
|
||||
XParseColor (q, G = XDefaultColormap (q, z), r = B, &F);
|
||||
XAllocColor (q, G, &F);
|
||||
XSetForeground (q, x g = XCreateGC (q, u, 0, 0), F.pixel);
|
||||
}
|
||||
}
|
||||
y = p--;
|
||||
P ();
|
||||
J ();
|
||||
f (F = R = H = 0;
|
||||
R < j;
|
||||
)++ F < p && X ? (T = R % n, H = G + E) : (D[B[R] = F]++, H = l, G = ++R - H, F = 0);
|
||||
T = m;
|
||||
G = j;
|
||||
U ();
|
||||
v = u;
|
||||
f (F = w / 5; ;
|
||||
A += G -= G + G, B -= G) (O < 0 ? L : *("tvr@cs.hut.fi." + 7 * F) ? F ^ 1 ? Y : K : L) (), (U) ();
|
||||
}
|
||||
puts ("tvr: mode size < cmap");
|
||||
}
|
||||
+122
@@ -0,0 +1,122 @@
|
||||
121
|
||||
black
|
||||
white
|
||||
black
|
||||
white
|
||||
black
|
||||
white
|
||||
black
|
||||
white
|
||||
black
|
||||
black
|
||||
white
|
||||
white
|
||||
black
|
||||
black
|
||||
white
|
||||
white
|
||||
black
|
||||
black
|
||||
white
|
||||
white
|
||||
black
|
||||
black
|
||||
white
|
||||
white
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
black
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
white
|
||||
black
|
||||
+115
@@ -0,0 +1,115 @@
|
||||
#include <X11/Xlib.h>
|
||||
#define M typedef
|
||||
#define N( a)=r=(a)+j
|
||||
#define S f(; G; )D[B[R=i[--G]]=F+=F<p]++
|
||||
#define f for
|
||||
#define g [H]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
M short a; M int b; M
|
||||
unsigned c ; M unsigned
|
||||
char*d; M XPoint *e; M void
|
||||
_; b*h,*i,j,k,l,m,n,o,p ; b O; d A
|
||||
,B,C; _*q,*r,*calloc(); e s ,t; Window
|
||||
u,v; GC x[256]; b D[256]; b w,y, z;_ Q(b E)
|
||||
{ XMapWindow(q,v=XCreateSimpleWindow(q, XRootWindow
|
||||
(q,z=XDefaultScreen(q)),!v*n,0,n,n,0,0,0)); XSelectInput
|
||||
( q,v,E); } _ P(){ C N(h N(i N(s N(t N(A N(B=calloc(C-B+256,1)
|
||||
) )) ))); } _ J(){ b F,G,H; c R =w %4; F=G=m; f(H=0; H<j
|
||||
; H++){ h g =l+(R-2?R?R-1?(G-F*F/n)+F*n:(G*G-F*F)
|
||||
/m*n+2*F*G/ m: 2*(F*F- G*G)/m+4*F*G/m*n:G+
|
||||
F*n);( s g. x= m-F--,s +H) ->y=m-G;F=
|
||||
F+m?F:(G--, m);}} _ K(){ b H,R;
|
||||
f(H=0;H<j;H ++)D[ B g=(c)(R
|
||||
=h g+k)< j? (A[ R]<p)+A
|
||||
|
||||
|
||||
[R
|
||||
]:
|
||||
1]
|
||||
++
|
||||
; } _ I ( d F)
|
||||
{ F?(_)0:(_
|
||||
) (F=B,
|
||||
gets(
|
||||
B))
|
||||
;
|
||||
|
||||
y=atoi(F);} _ Y(){ b F,
|
||||
G; c R ; F = G = 0; K( );
|
||||
f( R = k + l ; R < j && ( F =
|
||||
B[ R ] ) < p; R = h [R ] + k) { D
|
||||
[ F ] -- ; B [ i [ G ++ ] =R ] =p; } if
|
||||
( R >= j) F = 1; S; } _ L() { b H, F,G; c R ;
|
||||
f( H =0; H < j; H ++) B g =0; O =-1; f( G = R = 0;
|
||||
R < j; R++ ){ f(; R < j && !( F = B[ R ]); R = h[ R ]
|
||||
+ k) B [i[ G ++] = R ] = p; S; } } _ U() { e X [ 256 ]
|
||||
,W; b H; W = t; f ( H = 0; H < o; H ++ ) { X g =
|
||||
W; W +=D g ;} f( H =0; H < j; H ++) if(
|
||||
A g - B g) * X[ B g ] ++ = s g; {
|
||||
XMotionEvent * V = r = t ; W
|
||||
= t; f ( H = 0; H < o
|
||||
; H ++ ) { XDrawPoints
|
||||
|
||||
|
||||
(q ,
|
||||
v ,x g,
|
||||
W,X g -W,
|
||||
CoordModeOrigin
|
||||
) ; W += D
|
||||
g ; D g
|
||||
|
||||
= 0 ;
|
||||
} f(;
|
||||
XPending(q)+!
|
||||
++O; V->type-
|
||||
ButtonPress?(
|
||||
k =V
|
||||
->x+
|
||||
|
||||
|
||||
V -> y * n - l) : (
|
||||
O = - 42 ) ) XNextEvent ( q , r
|
||||
= V ) ; } } _ main ( b X , d * W ) { b H, F
|
||||
,G; c R; if ( X < 3 ) { puts( "tvr: mode size < cmap"
|
||||
); exit(0);} P(); I(*++ W); w = y %12; I(*++ W); n = y *2; j
|
||||
= n * n ; P ( ) ; m = y ; l = j / 2 + m
|
||||
; q=XOpenDisplay ( 0 ) ; Q ( 0 )
|
||||
; u = v ; Q ( PointerMotionMask
|
||||
|ButtonPressMask ) ; I ( 0 ) ; o
|
||||
=y ; p = o -1 ; { XColor F ;
|
||||
Colormap G; f ( H = 0 ; H < o
|
||||
; H++){ I(0); XParseColor(q,G
|
||||
=XDefaultColormap ( q , z ) , r =
|
||||
B , & F ) ; XAllocColor
|
||||
(q , G , & F ) ;
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
XSetForeground
|
||||
(q,x g = XCreateGC
|
||||
( q, u ,0 , 0 ) , F
|
||||
.pixel ) ; } } P ( ); J (); f
|
||||
( F =R = G =H = 0; H < j; )
|
||||
if(++F >= p || ( R = h [ R ]
|
||||
+G)>=j ) { D [ B g = F ] ++; R
|
||||
= l + k; G= ++H -R;
|
||||
F =0; } H=j; U(); v=
|
||||
u; f(F=w/4; ; A+=H-=H+H,B-=H
|
||||
)(O<0?L:*("tvr@cs.hut.fi."
|
||||
+7*F)?F^1?Y:K:L)()
|
||||
,(U)(); }
|
||||
+125
@@ -0,0 +1,125 @@
|
||||
124
|
||||
#005050
|
||||
#006464
|
||||
#007878
|
||||
#008c8c
|
||||
#00a0a0
|
||||
#1ca8a8
|
||||
#3cb4b4
|
||||
#5cc0c0
|
||||
#7ccccc
|
||||
#9cd8d8
|
||||
#bce4e4
|
||||
#dcf0f0
|
||||
#fcfcfc
|
||||
#e0f4f4
|
||||
#c0e8e8
|
||||
#a0dcdc
|
||||
#80d0d0
|
||||
#60c4c4
|
||||
#40b8b8
|
||||
#20acac
|
||||
#00a0a0
|
||||
#008c8c
|
||||
#007878
|
||||
#006464
|
||||
#005050
|
||||
#003c3c
|
||||
#002828
|
||||
#001414
|
||||
#000000
|
||||
#140000
|
||||
#280000
|
||||
#3c0000
|
||||
#500000
|
||||
#640000
|
||||
#780000
|
||||
#8c0000
|
||||
#a00000
|
||||
#ac2020
|
||||
#b84040
|
||||
#c46464
|
||||
#d08484
|
||||
#dca8a8
|
||||
#e8c8c8
|
||||
#f4e8e8
|
||||
#f8f0f0
|
||||
#ecd0d0
|
||||
#e0b0b0
|
||||
#d49090
|
||||
#cc7070
|
||||
#c05050
|
||||
#b43030
|
||||
#a81010
|
||||
#980000
|
||||
#840000
|
||||
#700000
|
||||
#5c0000
|
||||
#480000
|
||||
#340000
|
||||
#200000
|
||||
#0c0000
|
||||
#000800
|
||||
#001c00
|
||||
#003000
|
||||
#004400
|
||||
#005800
|
||||
#006c00
|
||||
#008000
|
||||
#009400
|
||||
#0ca40c
|
||||
#2cb02c
|
||||
#4cbc4c
|
||||
#6cc86c
|
||||
#8cd08c
|
||||
#acdcac
|
||||
#cce8cc
|
||||
#ecf4ec
|
||||
#f0f8f0
|
||||
#d0ecd0
|
||||
#b0e0b0
|
||||
#90d490
|
||||
#70cc70
|
||||
#50c050
|
||||
#30b430
|
||||
#10a810
|
||||
#009800
|
||||
#008400
|
||||
#007000
|
||||
#005c00
|
||||
#004800
|
||||
#003400
|
||||
#002000
|
||||
#000c00
|
||||
#000008
|
||||
#00001c
|
||||
#000030
|
||||
#000044
|
||||
#000058
|
||||
#00006c
|
||||
#000080
|
||||
#000094
|
||||
#0c0ca4
|
||||
#2c2cb0
|
||||
#4c4cbc
|
||||
#6c6cc8
|
||||
#8c8cd0
|
||||
#acacdc
|
||||
#cccce8
|
||||
#ececf4
|
||||
#f0f0f8
|
||||
#d0d0ec
|
||||
#b0b0e0
|
||||
#9090d4
|
||||
#7070cc
|
||||
#5050c0
|
||||
#3030b4
|
||||
#1010a8
|
||||
#000098
|
||||
#000084
|
||||
#000070
|
||||
#00005c
|
||||
#000048
|
||||
#000034
|
||||
#000020
|
||||
#00000c
|
||||
+219
@@ -0,0 +1,219 @@
|
||||
Best X11 Program:
|
||||
|
||||
Teemu Rantanen
|
||||
Helsinki University of Technology
|
||||
Melkonkatu 5 A 8
|
||||
00210 Helsinki
|
||||
Finland
|
||||
|
||||
|
||||
Judges' comments:
|
||||
|
||||
To use:
|
||||
make tvr
|
||||
./tvr mode screensize/2 < colormapfile
|
||||
|
||||
Try:
|
||||
./tvr 0 128 < tvr.color (for color displays)
|
||||
./tvr 0 128 < tvr.bw (for Black & White displays)
|
||||
|
||||
Mode may be a value from 0 to 12.
|
||||
|
||||
This entry requires the use of X11. It will form two windows
|
||||
(hopefully your window mangler will ask you to place these
|
||||
your display) which you should place side by side. Move the
|
||||
cursor around in one of the two windows and watch what happens.
|
||||
|
||||
The fractally minded may be able to detect that mode 0 does not
|
||||
calculate Mandelbrot/Julian sets correctly. Can you find the bug?
|
||||
Better still, can you fix it without breaking something else?
|
||||
|
||||
The author has provided us a spoiler version:
|
||||
|
||||
make tvr.alt
|
||||
./tvr.alt altmode screensize/2 < colormapfile
|
||||
|
||||
where altmode 1-4 correspond to mode 0-3 in the original entry
|
||||
and altmode 0 calculates Mandelbrot/Julian sets correctly.
|
||||
|
||||
|
||||
Selected notes from the author:
|
||||
|
||||
|
||||
Interactive Fractals for X Window System
|
||||
|
||||
|
||||
This program contains 4 pairs of fractals/effects and 3 methods of
|
||||
animating them. There are two windows for a pair of fractals, one
|
||||
of which contains static fractal (eg. Mandelbrot set) and the
|
||||
other an animating one (eg. Julian set) which is derived from the
|
||||
same formula as the static one. Only one pair of fractals can be
|
||||
displayed on one process.
|
||||
|
||||
|
||||
To animate the fractal, you must move your mouse on the static
|
||||
fractal -window and the animated fractal will be calculated based
|
||||
on mouse coordinates. If you are on one of the two non-stable
|
||||
modes (more about them later) you can stabilize the picture by
|
||||
pressing a mouse button. Pressing it does nothing on stable mode.
|
||||
|
||||
|
||||
|
||||
The three modes are:
|
||||
- non-stable mode with simple 'attractor searcher'
|
||||
- non-stable mode
|
||||
- stable mode
|
||||
|
||||
On Mandelbrot/Julian mode the stable mode calculates normal Julian
|
||||
set according to the Mandelbrot coordinates (mouse position). On
|
||||
non-stable modes the picture slowly transforms to the same picture
|
||||
as on the stable mode but transformation can take some
|
||||
time. Usually, and especially if changes are relatively small
|
||||
between mouse movements or frame rate is high, the non-stable mode
|
||||
makes much more interesting effects IMHO. The difference between
|
||||
2 non-stable modes is that the first tries to stabilize
|
||||
picture. It doesn't stabilize much, but it helps on some cases
|
||||
quite a lot. One notable case where help can be seen is when you
|
||||
first move your mouse to non-black areas of Mandelbrot set, then
|
||||
back to near the center. On some cases 'attractor searcher' can be
|
||||
seen as noise.
|
||||
|
||||
|
||||
First of the fractal pairs is Mandelbrot/Julianset as mentioned
|
||||
before. Second is a variation of that. Third makes nice
|
||||
3d-look-a-like effects and fourth is variation of that with more
|
||||
nice effects.
|
||||
|
||||
|
||||
|
||||
Usage:
|
||||
tvr mode screensize/2 < colormapfile
|
||||
|
||||
The first parameter is the operating-mode of the program. There
|
||||
are 4 fractal pairs, 3 display modes, making total of 12
|
||||
modes. Screensize is half of the actual screenlength/width. ie. If
|
||||
you use 128 as a second parameter, you will get two 256x256
|
||||
windows.
|
||||
|
||||
Program needs reasonable values for both of these parameters to
|
||||
operate. Good first try could be "0 128" or "8 128". Colormap has
|
||||
to be piped into the programs standard input.
|
||||
|
||||
Note that you will need approximately (secondparameter^2)*64 bytes
|
||||
of free main memory or machine will swap heavily (memory
|
||||
references are quite random and may confuse paging algorithms
|
||||
easily). This means that for 512x512 windows you will need 4M of
|
||||
memory.
|
||||
|
||||
|
||||
Colormapfile:
|
||||
|
||||
This is the file from which program reads colors for screen
|
||||
colormap. First line of the file must be a number between
|
||||
3..254. This informs the program how many colors there are to be
|
||||
expected. This is also the maximum number of iterations used on
|
||||
picture calculations. Lines after that are X11 color
|
||||
names. Program expects to find, and uses, the number of colors
|
||||
reported on first line.
|
||||
|
||||
There are 2 colormapfiles to start with. One with colors and
|
||||
another with only black and white. If you have enough colors on
|
||||
your display you can use the one with colors (even on
|
||||
grayscale). The other is meant mainly for 1 bitplane display
|
||||
(on which the picture looks terrible compared to 8 bitplane
|
||||
display).
|
||||
|
||||
|
||||
Compilation:
|
||||
|
||||
You should compile this entry with optimizing compiler with the
|
||||
highest level of optimization possible. You will also need an ansi
|
||||
compatible compiler (gcc -ansi -pedantic will do fine).
|
||||
|
||||
|
||||
|
||||
This entry has been tested on wide variety of machines including:
|
||||
|
||||
Machine OS
|
||||
------- --
|
||||
Decstation 5000/240 Ultrix 4.3A
|
||||
DECAlpha 3000/300 OSF/1 v1.3 and v2.0
|
||||
IBM RS6000 AIX v3
|
||||
SPARCStation IPX SunOS 4.1.3
|
||||
i486 Linux v1.1.8 (binarysize 3576 bytes
|
||||
using gcc -O6 -s -N ;)
|
||||
HP 9000/730 HP-UX
|
||||
|
||||
Also, many of X-server and Xlibrary version have been tested and
|
||||
the program should be highly portable. Program may slow down
|
||||
considerably on machines where table references are slow as the
|
||||
program makes extensive use of them. Also, due to the huge amount
|
||||
of data sent to the X-server, considerable slowdown can be noticed
|
||||
if the Xserver is slow or especially if the connection between the
|
||||
Xserver and the client is slow. (Don't try this on 9600 bps modem
|
||||
line. I did ;)
|
||||
|
||||
|
||||
Obfuscation is done on different levels. Almost none of it is made
|
||||
at the macro level, so cpp:ing the code won't give you
|
||||
much. Perhaps most notable is the algorithmic obfuscation. Simple
|
||||
formula has been turned into something completely different. Also
|
||||
it may be a surprise to find out which piece of the code
|
||||
calculates non-stable fractals and how it does that. Many
|
||||
obfuscations were left out of the program because speed of
|
||||
animation was one of the key issues. Well, obfuscated or not,
|
||||
some of the effects are very nice ;)
|
||||
|
||||
|
||||
Memory refreshment:
|
||||
|
||||
Mandelbrot set is calculated from formula
|
||||
|
||||
2
|
||||
Z = Z + Z
|
||||
n+1 n 0
|
||||
|
||||
and Julian set is calculated from formula
|
||||
|
||||
2
|
||||
Z = Z + C
|
||||
n+1 n
|
||||
|
||||
where C is the same throughout the picture. Both
|
||||
calculation are finished when |Z| >= 2.0. For the other
|
||||
fractals, the basic methods are the same but formula is
|
||||
different (look from the source ;)
|
||||
|
||||
Note that Mandelbrot and Julian on this program aren't
|
||||
exactly correct. Find out why ;)
|
||||
|
||||
|
||||
Bugs:
|
||||
|
||||
- No error checking. If DISPLAY is not set program dumps core.
|
||||
This may also happen if a request of some of the resources
|
||||
fails. eg. getting colors.
|
||||
|
||||
- No expose event handling
|
||||
|
||||
- It may be possible that the program starts drawing before
|
||||
window is mapped as there is no XSync(). In that case drawn
|
||||
data is lost. Also, some window manager configurations places
|
||||
the second window on top of the first and and again drawn data
|
||||
will be lost. By default, windows are placed next to the other
|
||||
in the topleft corner of the screen.
|
||||
|
||||
- Zooming is not possible
|
||||
|
||||
- Eats LOTS of memory on BIG pictures. Also lot's of CPU.
|
||||
|
||||
- Under mode 0, the boundary condition is not checked properly.
|
||||
The condition |Z| >= 2.0 should be checked exactly (by comparing
|
||||
x*x+y*y with 2*2), or else artifacts are introduced. The result
|
||||
of this error is a "bubbly" appearance (at least in mono).
|
||||
|
||||
Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
All Rights Reserved. Permission for personal, educational or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in writing
|
||||
from both Landon Curt Noll and Larry Bassel.
|
||||
@@ -0,0 +1,5 @@
|
||||
|
||||
main(){
|
||||
int x=3,n,m=2,*t,*a,*b=0;
|
||||
while(b?o:((*(t=b=(int*)malloc(o))=2),a=t+1,o))n=*b,n>=m?c:x%n?(int)b++:N);
|
||||
}
|
||||
@@ -0,0 +1,66 @@
|
||||
Best Short Program:
|
||||
|
||||
Jeff Weisberg
|
||||
University of Rochester
|
||||
Dept of Electrical Engineering
|
||||
Computer Studies Bldg
|
||||
Rochester, NY 14627
|
||||
USA
|
||||
|
||||
|
||||
Judges' comments:
|
||||
|
||||
To use:
|
||||
make weisberg
|
||||
./weisberg
|
||||
|
||||
This entry confuses some C-preprocessors and some C-beautifiers.
|
||||
We found one cpp that processed this source differently when
|
||||
it was read on stdin instead of via cc -E.
|
||||
|
||||
If you liked what you saw from the above program, and happen to
|
||||
have some 512 Megabytes of virtual memory laying around with to do,
|
||||
you could try:
|
||||
|
||||
make weisberg.alt
|
||||
./weisberg.alt
|
||||
|
||||
Lesser systems will find this alternative version a good way to create
|
||||
a core file. :-)
|
||||
|
||||
|
||||
Selected notes from the author:
|
||||
|
||||
Description:
|
||||
The following short program implements the "Yet Another" algorithm for
|
||||
generating prime numbers. It will generate all primes up to 33554432,
|
||||
displaying them to the standard output as it churns along. As 33554432
|
||||
is rather large on most machines, this code may take quite some time to
|
||||
run to completion, so as an added feature, it will cease execution upon
|
||||
reception of a signal (any will do equally well), as well as in the
|
||||
event of a system shutdown or reboot.
|
||||
|
||||
Bugs:
|
||||
The alternative version (weisberg.alt) has never actually run
|
||||
to completion. After running for close to a week it had reached
|
||||
somewhere around 250e6, when it became necessary to test the
|
||||
reboot feature (which worked remarkably well) As there are
|
||||
quite a lot of primes to be found before reaching MAXINT, the
|
||||
output produced can be quite overwhelming, it recommended to
|
||||
pipe the output through your favorite pager (more or less), and not
|
||||
output to a paper output device (unless you have *LOTS* of paper).
|
||||
|
||||
Technical:
|
||||
The original "Yet Another Prime Program" algorithm used here was
|
||||
developed as a Computer Architecture course micro-programing exercise,
|
||||
and was designed to take full advantage of the UR300
|
||||
micro-architecture to achieve blindingly fast speed. It was ported to
|
||||
C specifically for the IOCCC. In the conversion/obfuscation step some
|
||||
of (much of) the blazing speed was lost, but as a bonus, the
|
||||
understandability of the code was reduced to zero.
|
||||
|
||||
Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
All Rights Reserved. Permission for personal, educational or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in writing
|
||||
from both Landon Curt Noll and Larry Bassel.
|
||||
@@ -0,0 +1,90 @@
|
||||
#if O
|
||||
main(){}
|
||||
#else
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#if rop&onut&((own&rain)|warf)
|
||||
#include " The orc scrambles to the drain, trying to get the donut; you run out the door and escape! The End "
|
||||
#else
|
||||
#if escribe
|
||||
#if ocument
|
||||
#include " It reads: Depress Dotted Dog "
|
||||
#else
|
||||
#if oor
|
||||
#include " The door is decorated with relief figures of various dog breeds "
|
||||
#else
|
||||
#if rain
|
||||
#include " Through the drain you see a dwarf in another cell "
|
||||
#else
|
||||
#if warf
|
||||
#include " The gnarled dwarf looks thirsty "
|
||||
#else
|
||||
#if ungeon|ebris
|
||||
#include " You notice a desk, a phone, and a phone directory among the clutter "
|
||||
#else
|
||||
#if esk
|
||||
#include " There are some dimes on the desk "
|
||||
#else
|
||||
#if irectory
|
||||
#include " It reads: Pixie's Pub - instant service - Dial DUNgeon0614 "
|
||||
#else
|
||||
#include " You notice nothing unusual "
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#else
|
||||
#if ial&UNgeon0614
|
||||
#include " Pixie takes your order, and magically, the room is filled with banana daiquiris "
|
||||
#endif
|
||||
#if rink&aiquiri
|
||||
#include " As you drink, a voice from below says 'Could you drop one down here?' "
|
||||
#endif
|
||||
#if rop&aiquiri
|
||||
#if warf|own
|
||||
#include " The dwarf eagerly accepts the drink. 'Thanks! Here, I found this, but I can't understand it.' He hands you a document "
|
||||
#else
|
||||
#include " You drop the drink on the floor "
|
||||
#endif
|
||||
#endif
|
||||
#if epress&(almatian|almation)
|
||||
#include " As you press the dalmatian figure, the door opens - only to reveal a menacing orc by a vending machine (with a sign reading 'DEPOSIT MONEY') "
|
||||
#endif
|
||||
#if eposit&(ime|imes)
|
||||
#include " Donuts spill out; you get some, the orc hungrily eats the rest "
|
||||
#endif
|
||||
#if rop&onut
|
||||
#include " The orc quickly eats the donut; he still bars the way "
|
||||
#endif
|
||||
#if rop+epress+ime+eposit+rink+aiquiri+onut==1
|
||||
#include " Be more specific "
|
||||
#endif
|
||||
#include " You are in a debris-filled dungeon; a door bars the way, and sludge trickles into a floor drain "
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
@@ -0,0 +1,101 @@
|
||||
Worst Abuse of the C Preprocessor:
|
||||
|
||||
Brian Westley (Merlyn LeRoy on Usenet)
|
||||
Digi International
|
||||
1906 James Ave.
|
||||
St. Paul, MN 55105
|
||||
USA
|
||||
|
||||
|
||||
Judges' comments:
|
||||
|
||||
To use:
|
||||
make westley
|
||||
./westley
|
||||
|
||||
But for something more interesting try compiling it with
|
||||
different cc arguments. For example:
|
||||
|
||||
cc -Describe -Door westley.c
|
||||
cc -Describe -Drain westley.c
|
||||
|
||||
Not all compiler errors are bad.
|
||||
|
||||
For spoilers see the end of the notes from the author below.
|
||||
|
||||
|
||||
Selected notes from the author:
|
||||
|
||||
This program, in accordance with the rules, compiles into a legal
|
||||
C program without human intervention. However, it simply compiles
|
||||
into "main(){}", which does nothing and exits, so you don't need
|
||||
to actually compile the program.
|
||||
|
||||
This program is a simple adventure game which uses only C preprocessor
|
||||
error messages (for missing #include files) as output. To begin,
|
||||
try to compile the program with no options:
|
||||
|
||||
cc westley.c
|
||||
|
||||
This will fail, producing an error message for a missing #include
|
||||
file as the opening description. Your terminal should be set for
|
||||
80 columns, 8 character tabs, and wraparound, as there is no way
|
||||
to reliably output newlines. You should see something like this
|
||||
(text massaged to change wraparound to separate lines):
|
||||
|
||||
westley.c
|
||||
westley.c(87) : fatal error C1024: cannot open include file '
|
||||
|
||||
You are in a debris-filled
|
||||
dungeon; a door bars the
|
||||
way, and sludge trickles into
|
||||
a floor drain
|
||||
|
||||
'
|
||||
Your compiler error message will vary, but the important part is the
|
||||
missing include file name, which functions as the game text.
|
||||
|
||||
To "do" things, all words must start with "-D". For example, to
|
||||
look at the door, do:
|
||||
|
||||
cc -Describe -Door prog.c
|
||||
|
||||
...and you will get another error message telling you about the door.
|
||||
(note: some compilers will stop after the first missing include file,
|
||||
while others will continue to try compiling; the latter will repeat
|
||||
the opening message each time, as if you are playing an adventure game
|
||||
with "verbose" turned on).
|
||||
|
||||
The goal of the game is to escape the dungeon.
|
||||
|
||||
Here is a walk-through for the game, including a few dead-ends:
|
||||
---SPOILER---
|
||||
|
||||
-Describe -Door
|
||||
-Describe -Drain
|
||||
-Describe -Dwarf
|
||||
-Describe -Debris (or -Dungeon)
|
||||
-Describe -Desk
|
||||
-Describe -Dime
|
||||
-Describe -Directory
|
||||
-Dial -DUNgeon0614
|
||||
-Drink -Daiquiri
|
||||
-Drop -Daiquiri
|
||||
-Drop -Dwarf -Daiquiri (or -Drop -Down -Daiquiri)
|
||||
-Describe -Document
|
||||
-Depress -Dotted -Dog
|
||||
-Depress -Dalmatian (also accepts "Dalmation" [sic])
|
||||
-Deposit -Dime
|
||||
-Drop -Donut
|
||||
-Drop -Donut -Down -Drain (or -Drop -Dwarf -Donut)
|
||||
(at this point, you win!)
|
||||
|
||||
Note that the game has no real state information; you can type these
|
||||
commands in any order, at any time. Also note that word order is
|
||||
unimportant.
|
||||
|
||||
Copyright (c) 1994, Landon Curt Noll & Larry Bassel.
|
||||
All Rights Reserved. Permission for personal, educational or non-profit use is
|
||||
granted provided this this copyright and notice are included in its entirety
|
||||
and remains unaltered. All other uses must receive prior permission in writing
|
||||
from both Landon Curt Noll and Larry Bassel.
|
||||
Reference in new issue
Block a user