Path: utzoo!utgpu!water!watmath!clyde!att!cbnews!res
From: res@cbnews.ATT.COM (Robert E. Stampfli)
Newsgroups: comp.lang.c
Subject: Re: possible operator precedence bug?
Message-ID: <1484@cbnews.ATT.COM>
Date: 7 Oct 88 19:31:48 GMT
References: <751@mcrware.UUCP> <7652@rpp386.Dallas.TX.US>
Reply-To: res@cbnews.ATT.COM (Robert E. Stampfli)
Organization: AT&T Bell Laboratories, Columbus
Lines: 28

>In article <751@mcrware.UUCP> jejones@mcrware.UUCP (James Jones) writes:
>>A recently-posted C program that generates random mazes gives me cause to
>>wonder about C operator precedence.
>>
>>I include the source here for reference--it's very short:
>
>char*M,A,Z,E=40,J[40],T[40];main(C){for(*J=A=scanf(M="%d",&C);
>--            E;             J[              E]             =T
>[E   ]=  E)   printf("._");  for(;(A-=Z=!Z)  ||  (printf("\n|"
>)    ,   A    =              39              ,C             --
>)    ;   Z    ||    printf   (M   ))M[Z]=Z[A-(E   =A[J-Z])&&!C
>&    A   ==             T[                                  A]     
>|6<<27<rand()||!C&!Z?J[T[E]=T[A]]=E,J[T[A]=A-Z]=A,"_.":" |"];}
  ^^^^^
>

When I tried compiling this, it didn't work, generating mazes which were
always columnar except for one horizontal row at the bottom.

However, by changing the "6<<27" to "4<<11" I found it worked
for my "big-endian" type machines.  The rand() function returns a
number in the range 0 - 2^15-1 on my systems, making the program 
always fail the comparison, as originally written.  Other systems
may have slightly different rand() functions, I suppose.  Regardless,
this is one jewel of a program.  Hope this helps someone.

Rob Stampfli
att!cbnews!res