jon@gaia.UUCP (Jonathan Corbet) (12/19/87)
I found the answer to the bug I posted the other day, wherein the dungeon
was simply devoid of objects on Microport systems. I'm not sure of the
bug is in the nethack code, or in the Microport C compiler. What happens
is that the result of the somex() and somey() macros in mklev.c are "xchar"
values, while the mkgold() and mkobj_at() routines expect full integers.
Most compilers will widen the values accordingly, but not here...The fix
is to go into mklev.c, and change lines like
mkgold (0L, somex (), somey ());
to
mkgold (0L, (int) somex (), (int) somey);
and similarly with the mkobj_at() calls. I think there were only three
that needed to be changed.
I also found the nifty glitch that can cause failures if you set "dogname"
in HACKOPTIONS. Line 406 of options.c reads:
if(*cs == ',') break;
which is fine unless "dogname" is the last option you set, in which case there
is no comma. Replace with:
if(*cs == ',' || *cs == '\0') break;
and the problem goes away.
--
Jonathan Corbet
{rutgers | ames | gatech}!hao!gaia!jon
{uunet | ucbvax | allegra | cbosgd}!nbires!gaia!jonrupley@arizona.edu (John Rupley) (12/24/87)
In article <339@gaia.UUCP>, Jonathan Corbet writes > I found the answer to the bug I posted the other day, wherein the dungeon > was simply devoid of objects on Microport systems. I'm not sure of the > bug is in the nethack code, or in the Microport C compiler. The bug is in the code, which is broken for 80286 machines but not for the likes of Vaxen, where longs and ints have the same width. > What happens > is that the result of the somex() and somey() macros in mklev.c are "xchar" ^^^^^ In fact, they are longs, typed by the rand() call in the macros. > values, while the mkgold() and mkobj_at() routines expect full integers. > Most compilers will widen the values accordingly, but not here... Not quite... one long on the stack is read as two integers by the function, garbaging both integer parameters; thus the compiler is doing what it should. > The fix > is to go into mklev.c, and change lines like > mkgold (0L, somex (), somey ()); > to > mkgold (0L, (int) somex (), (int) somey); > and similarly with the mkobj_at() calls. I think there were only three > that needed to be changed. Right, but it is simpler to make the cast from long to int in the #defines for the somex and somey macros: #define somex() (int )((rand()%(croom->hx-croom->lx+1))+croom->lx) #define somey() (int )((rand()%(croom->hy-croom->ly+1))+croom->ly) some[xy] are defined as long also in fountain.c, but they are harmlessly truncated to int in the code. John Rupley uucp: ..{ihnp4 | hao!noao}!arizona!rupley!local internet: rupley!local@megaron.arizona.edu telex: 9103508679(JARJAR) (H) 30 Calle Belleza, Tucson AZ 85716 - (602) 325-4533 (O) Dept. Biochemistry, Univ. Arizona, Tucson AZ 85721 - (602) 621-3929