chongo@nsc.UUCP (Landon Noll) (06/25/85)
*** OBFUSCATE THIS LINE WITH YOUR MESSAGE ***
The following programs were judged good (bad? wierd?) enough to win
awards. This year, rather than trying to rank the programs in order of
obfuscatedness, we gave a single award in each of 4 categories and a
grand prize.
________________________________________________________________________
1. The most obscure program:
(submitted by Lennart Augustsson <seismo!mcvax!enea!chalmers!augustss> )
#define p struct c
#define q struct b
#define h a->a
#define i a->b
#define e i->c
#define o a=(*b->a)(b->b,b->c)
#define s return a;}q*
#define n (d,b)p*b;{q*a;p*c;
#define z(t)(t*)malloc(sizeof(t))
q{int a;p{q*(*a)();int b;p*c;}*b;};q*u n a=z(q);h=d;i=z(p);i->a=u;i->b=d+1;s
v n c=b;do o,b=i;while(!(h%d));i=c;i->a=v;i->b=d;e=b;s
w n o;c=i;i=b;i->a=w;e=z(p);e->a=v;e->b=h;e->c=c;s
t n for(;;)o,main(-h),b=i;}main(b){p*a;if(b>0)a=z(p),h=w,a->c=z(p),a->c->a=u,a->c->b=2,t(0,a);putchar(b?main(b/2),-b%2+'0':10);}
________________________________________________________________________
2. The worst abuse of the C preprocessor:
(submitted by Col. G. L. Sicherman <decvax!sunybcs!colonel> )
#define C_C_(_)~' '&_
#define _C_C(_)('\b'b'\b'>=C_C>'\t'b'\n')
#define C_C _|_
#define b *
#define C /b/
#define V _C_C(
main(C,V)
char **V;
/* C program. (If you don't
* understand it look it
*/ up.) (In the C Manual)
{
char _,__;
while (read(0,&__,1) & write((_=(_=C_C_(__),C)),
_C_,1)) _=C-V+subr(&V);
}
subr(C)
char *C;
{
C="Lint says "argument Manual isn't used." What's that
mean?"; while (write((read(C_C('"'-'/*"'/*"*/))?__:__-_+
'\b'b'\b'|((_-52)%('\b'b'\b'+C_C_('\t'b'\n'))+1),1),&_,1));
}
[ This program confused the C preprocessor so badly that it left some
comments in the preprocessed version. Also, lint DID complain that
"argument Manual isn't used". ]
________________________________________________________________________
3. The strangest appearing program:
(submitted by Ed Lycklama <decvax!cca!ima!ism780!ed> )
#define o define
#o ___o write
#o ooo (unsigned)
#o o_o_ 1
#o _o_ char
#o _oo goto
#o _oo_ read
#o o_o for
#o o_ main
#o o__ if
#o oo_ 0
#o _o(_,__,___)(void)___o(_,__,ooo(___))
#o __o (o_o_<<((o_o_<<(o_o_<<o_o_))+(o_o_<<o_o_)))+(o_o_<<(o_o_<<(o_o_<<o_o_)))
o_(){_o_ _=oo_,__,___,____[__o];_oo ______;_____:___=__o-o_o_; _______:
_o(o_o_,____,__=(_-o_o_<___?_-o_o_:___));o_o(;__;_o(o_o_,"\b",o_o_),__--);
_o(o_o_," ",o_o_);o__(--___)_oo _______;_o(o_o_,"\n",o_o_);______:o__(_=_oo_(
oo_,____,__o))_oo _____;}
[it looks like tty noise]
________________________________________________________________________
4. The best "small" program:
(submitted by Jack Applin [with help from Robert Heckendorn]
<hplabs!hp-dcd!jack> )
main(v,c)char**c;{for(v[c++]="Hello, world!\n)";(!!c)[*c]&&(v--||--c&&execlp(*c,*c,c[!!c]+!!c,!c));**c=!c)write(!!*c,*c,!!**c);}
________________________________________________________________________
5. The grand prize (most well-rounded in confusion):
(submitted by Carl Shapiro <sdcrdcf!otto!carl> )
#define P(X)j=write(1,X,1)
#define C 39
int M[5000]={2},*u=M,N[5000],R=22,a[4],l[]={0,-1,C-1,-1},m[]={1,-C,-1,C},*b=N,
*d=N,c,e,f,g,i,j,k,s;main(){for(M[i=C*R-1]=24;f|d>=b;){c=M[g=i];i=e;for(s=f=0;
s<4;s++)if((k=m[s]+g)>=0&&k<C*R&&l[s]!=k%C&&(!M[k]||!j&&c>=16!=M[k]>=16))
a[f++]=s;if(f){f=M[e=m[s=a[rand()/(1+2147483647/f)]]+g];j=j<f?f:j;f+=c&-16*!j;
M[g]=c|1<<s;M[*d++=e]=f|1<<(s+2)%4;}else e=d>b++?b[-1]:e;}P(" ");for(s=C;--s;
P("_"))P(" ");for(;P("\n"),R--;P("|"))for(e=C;e--;P("_ "+(*u++/8)%2))
P("| "+(*u/4)%2);}
[As submitted, this program was 3 lines (2 of defines and 1 of code).
To make news/mail/etc. happy we split the last line into 7. Join them
back without the newlines to get the original version]
----------------------------------------------------------------------
Congratulations to the winners (and anyone else who wasted their time
creating such wierd programs).
For your own enjoyment, you can figure out what these programs do. Or
if this is too hard, compile and run them! All of these compiled and
ran on the vax. Lint was even happy with most of the entries.
The winning programs may be published in a programming magazine.
The columnist will post further details to the net, if there are any.
Next years contest will be held somewhat earlier in the year so
that the winners will be announced to the summer Usenix's Usenet BOF.
[We will not post or mail the non-winning programs.]
[Although they are more interesting and constructive than most of net.flame]
[It is sad to say that there are programs which are part of UNIX systems
(sh,finger,config,etc.) which are not much easier to understand than
these award winners - and much longer] :-)
From the obfuscated keyboards of:
chongo <char *grepal="pheep";main(){printf("%s? %s\n",grepal,"grepal");}>
/\??/\
Larry Bassel (ihnp4!nsc!lab)
--
no comment is a comment.keesan@bbnccv.UUCP (Morris M. Keesan) (06/25/85)
1. The most obscure program:
(submitted by Lennart Augustsson <seismo!mcvax!enea!chalmers!augustss> )
is not legal C, even though the 4.2BSD compiler (and presumably other PCC-based
compilers) processes it as the author apparently intended.
Specifically, the expression
> putchar(b?main(b/2),-b%2+'0':10)
is illegal. My compiler (BBN C/70 C compiler, based on the Dennis Ritchie
PDP-11 C compiler from V7 UNIX) issues the error message "Illegal conditional".
A little examination reveals that the error reduces to
expr ? expr , expr : expr
which is illegal because the comma operator has lower precedence than the
conditional operator. See the first paragraph of section 7 of the C Reference
Manual (page 185 of K&R), or Page 81 of the System V "Programming Guide", or
Sections C.3 and C.3.17 of the April 30, 1985 draft ANSI spec. To make this
legal, it must be
expr ? (expr , expr) : expr
or
putchar(b?(main(b/2),-b%2+'0'):10)
-------------------------------------------------------------------------
The program further violates K&R C (although it is legal according to all
versions I've seen of the proposed ANSI spec, and also according to the
System V documentation) by using structure member names non-uniquely; i.e.
the structure member a is used both as an int and as a function pointer,
and b is used as an int and as a structure pointer [ K&R p. 197: ". . . the
same member may appear in two different structures if it has the same type in
both . . ." ]. V7 C compilers blow up on this, complaining of redeclaration
of a and b.
For these two reasons, especially the first, I don't think this program
deserves a prize. Also, this is a bug in the 4.2BSD compiler, and even more
so in the 4.2BSD lint, which should issue a warning even if the compiler is
being forgiving.
--
Morris M. Keesan
keesan@bbn-unix.ARPA
{decvax,ihnp4,etc.}!bbncca!keesanthomson@uthub.UUCP (Brian Thomson) (06/26/85)
From Morris Keesan (keesan@bbnccv): >1. The most obscure program: >(submitted by Lennart Augustsson <seismo!mcvax!enea!chalmers!augustss> ) > >is not legal C, even though the 4.2BSD compiler (and presumably other PCC-based >compilers) processes it as the author apparently intended. > >Specifically, the expression >> putchar(b?main(b/2),-b%2+'0':10) >is illegal. My compiler (BBN C/70 C compiler, based on the Dennis Ritchie >PDP-11 C compiler from V7 UNIX) issues the error message "Illegal conditional". >A little examination reveals that the error reduces to > > expr ? expr , expr : expr > >which is illegal because the comma operator has lower precedence than the >conditional operator. No, I think you're wrong. The relative precedence of operators exists only to disambiguate possible parses. In the example you cite there is only one valid parse, so precedence doesn't come into it. The "bug", if you want to call it that, exists in your compiler rather than in PCC. PCC-based compilers use a more powerful technique [LALR(1)] for expression parsing than does the Ritchie compiler [simple precedence, if I remember rightly], and the simpler technique can't quite hack the language. -- Brian Thomson, CSRI Univ. of Toronto {linus,ihnp4,uw-beaver,floyd,utzoo}!utcsrgv!uthub!thomson
augustss@chalmers.UUCP (Lennart Augustsson) (06/29/85)
[I really shouldn't spend more time on these silly programs.] In article <36@bbnccv.UUCP> keesan@bbnccv.UUCP (Morris M. Keesan) writes: >1. The most obscure program: >(submitted by Lennart Augustsson <seismo!mcvax!enea!chalmers!augustss> ) > >is not legal C, even though the 4.2BSD compiler (and presumably other PCC-based >compilers) processes it as the author apparently intended. .... >A little examination reveals that the error reduces to > > expr ? expr , expr : expr > I actually didn't think it would work, but I tested removing the parenthesis around the (expr,expr) and it still worked! So, since the purpose was to produce an obscure program I kept them removed (another reason was that the program was a bit to long at that moment). >The program further violates K&R C (although it is legal according to all >versions I've seen of the proposed ANSI spec, and also according to the >System V documentation) by using structure member names non-uniquely; i.e. >the structure member a is used both as an int and as a function pointer, >and b is used as an int and as a structure pointer [ K&R p. 197: ". . . the >same member may appear in two different structures if it has the same type in >both . . ." ]. V7 C compilers blow up on this, complaining of redeclaration >of a and b. Since this seems to be an accepted extension to C I don't think it requires any defense. BTW, the program contains another non-portable construction: b / 2 where b is negative, this may cause problems on some machines. -- Any resemblance of the opinions above to real opinions, living or dead, is purely coincidential. Lennart Augustsson UUCP: {seismo,philabs,decvax}!mcvax!enea!chalmers!augustss ARPA,CSnet: augustss@chalmers.csnet
chongo@nsc.UUCP (Landon Noll) (06/29/85)
In article <36@bbnccv.UUCP> keesan@bbnccv.UUCP (Morris M. Keesan) writes: >1. The most obscure program: >(submitted by Lennart Augustsson <seismo!mcvax!enea!chalmers!augustss> ) > >is not legal C, even though the 4.2BSD compiler (and presumably other PCC-based >compilers) processes it as the author apparently intended. > >For these two reasons, especially the first, I don't think this program >deserves a prize. Also, this is a bug in the 4.2BSD compiler, and even more >so in the 4.2BSD lint, which should issue a warning even if the compiler is >being forgiving. So it breaks on other compilers eh? Well such is life with a Obfuscated C contest! One has to hand it to someone for finding a "hole" in a compiler, and driving a truck through it. The contest rules stated that it has to be in "Common C". There was nothing to point out that it HAD to be standard C, K&R C, or Deathstar Unix C. The ability to run an entry on other systems was a plus, not a rule. Also, we did not try, nor did we intend to check out each program on every system/compiler. We did not have time, or resources to do so! Thank you for posting a suggested change so that other people might see what the program does. If anyone else finds another porting problem, you might consider posting a bug fix to net.sources.bugs. chongo <in any event, the awards are final> /\../\ -- no comment is a comment.
keesan@bbnccv.UUCP (Morris M. Keesan) (07/01/85)
In article <217@uthub.UUCP> thomson@uthub.UUCP (Brian Thomson) writes: >From Morris Keesan (keesan@bbnccv): . . >>A little examination reveals that the error reduces to >> >> expr ? expr , expr : expr >> >>which is illegal because the comma operator has lower precedence than the >>conditional operator. > >No, I think you're wrong. The relative precedence of operators exists only >to disambiguate possible parses. In the example you cite there is only >one valid parse, so precedence doesn't come into it. The "bug", if you >want to call it that, exists in your compiler rather than in PCC. ----------------------------------------------------------------------------- Well, if we were discussing this from the viewpoint of language philosophy and language design, I would probably agree with you that operator precedence SHOULD only exist to disambiguate possible parses. However, this is not the case in C. I quote from the C Reference Manual, section 7 (p. 185 of K&R) [ I am using the symbol '#' here as a replacement for the 'section' symbol, which is not in the ASCII character set]: The precedence of expression operators is the same as the order of the major subsections of this section, highest precedence first. Thus, for example, the expressions referred to as the operands of + (#7.4) are those expressions defined in ##7.1-7.3. The conditional operator (?:) is defined in section 7.13, and thus the expressions which may be its operands are those defined in subsections 7.1 through 7.12. By the above paragraph, the expressions defined in subsections 7.14 (assignment expressions) and 7.15 (comma expressions) are explicitly NOT allowed as operands of the conditional operator, and so the expressions a ? b , c : d a ? b = c : d a ? b : d = c although perfectly plausible and unambiguous, are not valid expressions in any formally-defined version of C (K&R, V7 UNIX, System V, 4.2BSD, Ultrix, and the various ANSI Draft Proposed Standards all agree on this in their documents defining C -- the ANSI draft is clearest). Just because there is only one possible or plausible parse that doesn't make it a valid parse. >PCC-based compilers use a more powerful technique [LALR(1)] for >expression parsing than does the Ritchie compiler [simple precedence, if >I remember rightly], and the simpler technique can't quite hack >the language. The simpler technique "hacks the language" exactly, and is probably the rationale for the language being defined the way it was. The "more powerful technique" being used by PCC is power misapplied, and is accepting expressions which are not allowed by the language definition (unless you define the language as "what the compiler accepts"). -- Morris M. Keesan keesan@bbn-unix.ARPA {decvax,ihnp4,etc.}!bbncca!keesan
ark@alice.UUCP (Andrew Koenig) (07/02/85)
> and so the expressions > > a ? b , c : d > a ? b = c : d > a ? b : d = c > > although perfectly plausible and unambiguous, are not valid expressions in Ummm. a?b:d=c is ambiguous. Does it mean a ? b : (d = c) or (a ? b : d) = c Yeah, I know: ?: doesn't give an lvalue. That's just a semantic quibble.