Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ptsfa!ihnp4!cuae2!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP
Newsgroups: comp.sources.d
Subject: Re: Bug Fix for Hack (panicking in makemon)
Message-ID: <1676@ttrdc.UUCP>
Date: Sun, 26-Apr-87 16:07:35 EDT
Article-I.D.: ttrdc.1676
Posted: Sun Apr 26 16:07:35 1987
Date-Received: Thu, 30-Apr-87 05:59:23 EDT
References: <1264@svax.cs.cornell.edu>
Organization: AT&T, Skokie, IL
Lines: 41
Summary: auggh, what coding

In article <1264@svax.cs.cornell.edu>, gil@svax.cs.cornell.edu (Gil Neiger) writes:
< The problem is when ct is decremented when KOPS is on (see ***);
                            ^^^^^^^^^^^
< tmp needs to be correspondingly (if it is greater than 0).
< Specifically, that portion of the code should look like this
< 
< 		tmp = rn2(ct*dlevel/24 + tmp);
< 		if(tmp < dlevel - 4) tmp = rn2(ct*dlevel/24 + 12);
< 		if(tmp >= ct) tmp = rn1(ct - ct/2, ct/2);
< 		ct = 0;
< #ifdef KOPS
< 		ct++;  tmp = (tmp) ? tmp-- : tmp;
                ^^^^
< #endif KOPS
< 		for(; ct < CMNUM; ct++){
< 			ptr = &mons[ct];
< 
< Now you can be assured that the loop will terminate correctly and
< that there will be no panic.
< 
< 					- Gil

Huh?  Do you mean INCREMENTED?  Or should that be a ct--?

Also,

	tmp = (tmp) ? tmp-- : tmp;

is unportable code, and may blow up in environments other than the one you
tested it in.  If the compiler arranges for tmp-- to be executed before
the value of the expression is stuffed back into tmp, the effect of the
decrement will be undone.

Why not, instead,

	if (tmp) tmp--;
-- 
|------------dan levy------------|  Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
|         an engihacker @        |		vax135}!ttrdc!ttrda!levy
| at&t computer systems division |  Disclaimer:  try datclaimer.
|--------skokie, illinois--------|