kevin@crash.cts.com (Kevin Hill) (01/16/91)
I was pleasantly surprised today, Wednesday Morning 1:10am, to find my
mailbox, full of letters telling me that I forgot to initialize 'i' in the
code that I posted earlier. However, I do assure you, that I was initialized...
I finally gave up and defined the 8 positions of surround by typing each case
out. Oh, well. Also, many Kudo's to Tom Shores who told me to get rid of
the blob of programming I had, and use the following
if ((gx+k<0)||(gx+k>GXMAX)||(gy-j<0)||(gy-j>GYMAX))
surround[i] = -1;
Wheeeew, I didn't know I could smash all my code into that two line
peice of if for loop! Yowzers inspector gadget!
I'll have to call on Tom to omptimize my program that I am writing for
me!
Thanks to everyone who wrote, if you know of any bugs in Think C 3.01p4,
that involve for loops, please tell me because the problem that I am having,
is something that should not happen.
Also, all the variables, are initialized and surround is defined as a
int surround[9]; variable. here's the code again, for those who missed it
>
> for(j = -1;j < 2;j++)
> {
>
> for(k = -1;k < 2;k++)
> {
> printf("%3d %3d\t",j,k);
> i++;
> surround[i] = track[gx+k][gy+j];
> if ( (gx+k) < 0)
> surround[i] = -1;
> if ( (gx+k) > GXMAX)
> surround[i] = -1;
> if ( (gy-j) < 0)
> surround[i] = -1;
> if ( (gy-j) > GYMAX)
> surround[i] = -1;
> }
>
> }
The problem seems to be that the variables j and k do wild things after they
do what is expected of them. Then they go off to change the correct value
of surround[9] to something wierd and go off into lala land.mxmora@unix.SRI.COM (Matt Mora) (01/17/91)
In article <6968@crash.cts.com> kevin@crash.cts.com (Kevin Hill) writes: > > The problem seems to be that the variables j and k do wild things after they >do what is expected of them. Then they go off to change the correct value >of surround[9] to something wierd and go off into lala land. Have you bothered to single step through your code with a source level debugger (or macsbug for that matter)? Maybe you can find out why j and k "do wild things" or where they get tromped on. Just curious. Matt -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@QM.SRI.COM SRI International | my SUN mxmora@unix.sri.com ___________________________________________________________
emmayche@dhw68k.cts.com (Mark Hartman) (01/17/91)
Kevin writes: > The problem seems to be that the variables j and k do wild things after they >do what is expected of them. Then they go off to change the correct value >of surround[9] to something wierd and go off into lala land. This is really reaching, but... how are j and k defined? -- Mark Hartman, N6BMO "What are you just standing there for? Where Applelink: N1083 or BINARY.TREE do you think you are, DIS-ney World??" Internet: emmayche@dhw68k.cts.com -- General Knowledge, from uucp: ...{spsd,zardoz,felix}!dhw68k!emmayche CRANIUM COMMAND
n67786@lehtori.tut.fi (Nieminen Tero) (01/18/91)
>In article <20058@unix.SRI.COM> mxmora@unix.SRI.COM (Matt Mora) writes: > >>In article <6968@crash.cts.com> kevin@crash.cts.com (Kevin Hill) writes: >> >> The problem seems to be that the variables j and k do wild things after >>they do what is expected of them. Then they go off to change the correct >>value of surround[9] to something wierd and go off into lala land. > >Have you bothered to single step through your code with a source level >debugger (or macsbug for that matter)? Maybe you can find out why j and k >"do wild things" or where they get tromped on. Loop variables are usually allocated in cpu registers and thus their value is not guarranteed outside the loop. The registers might or might not get trashed immediately after the last statement in the loop. Read the documentation of your compiler. -- Tero Nieminen Tampere University of Technology n67786@cc.tut.fi Tampere, Finland, Europe
dorner@pequod.cso.uiuc.edu (Steve Dorner) (01/23/91)
>Loop variables are usually allocated in cpu registers and thus their >value is not guarranteed outside the loop. The registers might or might >not get trashed immediately after the last statement in the loop. Read >the documentation of your compiler. WRONG. In Pascal perhaps, but not in C. You can depend on the fact that: main() { short i; for (i=0;i<8;i++); printf("%d\n",i); } will print "8". The storage class of the variable has nothing to do with it, either. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
d88-jwa@dront.nada.kth.se (Jon W{tte) (01/24/91)
In article <1991Jan22.191628.29221@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >>Loop variables are usually allocated in cpu registers and thus their >>value is not guarranteed outside the loop. The registers might or might >WRONG. In Pascal perhaps, but not in C. You can depend on the fact that: >The storage class of the variable has nothing to do with it, either. ALL OF the loop variables in C I've seen have had volatile values. That's because I've seen none, there aren't any ! The for construct is just a fleshed-out while... h+ Jon W{tte, Stockholm, Sweden, h+@nada.kth.se :: This article is fake. If you take it for real, the _REAL_ :: Jon W{tte will sue you for slander. So there ! Nyah ! :-)