ralf@b.gp.cs.cmu.edu (Ralf Brown) (08/21/87)
The new 1.4f version of NetHack has a number of typos!
-----
In decl.c and zap.c,
change
'\'
to
'\\'
(unterminated character constant error)
-----
In prisym.c, change
symbol.room
to
ROOM_SYM
("symbol" does not exist)
-----
In msdos.c, change
symbol = s ;
to
showsyms = s ;
(again, "symbol" does not exist)
-----
Finally, two minor changes for Turbo C:
in makedefs.c, exchange the include statements for config.h and stdio.h
(getchar winds up multiply #defined in the given order)
in shk.c, move the declaration
struct obj *carrying() ;
outside of the function inshop() to prevent a (spurious? YA TC bug?) type
mismatch error in a later function.
-----
Also, the fileinfo[] array of structures needs to be zeroed out (at least
the "where" field) at the beginning. Uninitialized global arrays are not
zeroed out in Turbo C (and probably many other compilers), so I get a crash
on trying to go down to level 2, because fileinfo[2].where is nonzero--
which is supposed to mean the level exists!
--
-=-=-=-=-=-=-=-= {harvard,seismo,ucbvax}!b.gp.cs.cmu.edu!ralf =-=-=-=-=-=-=-=-
ARPAnet: RALF@B.GP.CS.CMU.EDU BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA
AT&Tnet: (412) 268-3053 (school) FIDOnet: Ralf Brown at 129/31
DISCLAIMER? Who ever said I claimed anything?
"I do not fear computers. I fear the lack of them..." -- Isaac Asimovchris@cs.hw.ac.uk (Chris Miller) (08/23/87)
In article <83@b.gp.cs.cmu.edu> ralf@b.gp.cs.cmu.edu (Ralf Brown) writes: > >The new 1.4f version of NetHack has a number of typos! >... >Finally, two minor changes for Turbo C: >... >Also, the fileinfo[] array of structures needs to be zeroed out (at least >the "where" field) at the beginning. Uninitialized global arrays are not >zeroed out in Turbo C (and probably many other compilers), ... This does not seem to be the case in Turbo C; the User Guide, page 168 states "In C, all global variables are initialized to 0 by default unless you explicitly initialize them to a different value". Any compiler that did not implement this would not be a true C compiler. I have attempted to determine empirically whether Turbo C conforms to its own documentation in this respect, and as far as I can tell, it does (of course, no amount of such testing can constitute proof). In each memory model, and for each scalar type, some pointer types, and a structure type containing char, int, long, float and double fields, I declared an uninitialised global array and wrote a loop to compare each element (each field of each element, for the structure) against the constant 0 (uncast, and hence implicitly cast to the type of the appropriate element). In every case, all components of the array (and fields of the structure) were initialised properly to 0. I have not encountered the bug that you describe in NetHack, either. Is this a problem with very early releases of Turbo C? -- Chris Miller, Heriot-Watt University, Edinburgh chris@cs.hw.ac.uk <EUROPE>!ukc!hwcs!chris chris@hwcs.uucp chris@uk.ac.hw.cs
ralf@b.gp.cs.cmu.edu (Ralf Brown) (08/24/87)
In article <1438@brahma.cs.hw.ac.uk> chris@cs.hw.ac.uk (Chris Miller) writes: >In article <83@b.gp.cs.cmu.edu> ralf@b.gp.cs.cmu.edu I write: >> >>Also, the fileinfo[] array of structures needs to be zeroed out (at least >>the "where" field) at the beginning. Uninitialized global arrays are not >>zeroed out in Turbo C (and probably many other compilers), ... > >This does not seem to be the case in Turbo C; the User Guide, page 168 >states "In C, all global variables are initialized to 0 by default >unless you explicitly initialize them to a different value". Any >compiler that did not implement this would not be a true C compiler. >I have attempted to determine empirically whether Turbo C conforms to its >own documentation in this respect, and as far as I can tell, it does >(of course, no amount of such testing can constitute proof). ... >I have not encountered the bug that you describe in NetHack, either. >Is this a problem with very early releases of Turbo C? >-- > Chris Miller, Heriot-Watt University, Edinburgh > chris@cs.hw.ac.uk <EUROPE>!ukc!hwcs!chris chris@hwcs.uucp > chris@uk.ac.hw.cs [This is a reply to a mail message, but I am also posting it because of the additional bugfix.] What I did to fix the problem was put in a for loop (#ifdeffed to __TURBOC__) that sets all the .where elements to zero. I just recompiled lev.c (which defines fileinfo[]) to assembly code, and fileinfo is given as 'nn dup (?)', so now I am relinking with the /MAP flag, to see where it gets put in the .EXE file, and then I'll look at the .EXE. (running stuff in the background with DESQview is so nice...) Strange...the data area for fileinfo is indeed all zeros--so why did I keep getting crashes because the level wasn't created (fileinfo[].where != 0) until I added the code to zero out fileinfo[].where? In other bugfixes, I kept getting "at gets null at xx yy" whenever I or a monster moved off of an upward stairway "<". It turns out that there is a bug in msdos.c, in the code which reads the GRAPHICS option in HACK.CNF. The scanf() below uses %u to read in the graphics characters from decimal numbers, but stores them in unsigned chars! This works OK for the characters actually read, as they are contiguous, so each %u wipes out the null high byte of the previous %u. The character for the upstair is immediately after the last character read by the GRAPHICS option, so it gets wiped. } else if (!strncmp(buf, "GRAPHICS", 4)) { struct symbols s = defsyms ; if (sscanf(bufp, "%u%u%u%u%u%u%u%u%u", &s.vwall, &s.hwall, &s.tlcorn, &s.trcorn, &s.blcorn, &s.brcorn, &s.door, &s.room, &s.corr) == 9) { s.upstair = defsyms.upstair ; /* got wiped */ showsyms = s; } -- -=-=-=-=-=-=-=-= {harvard,seismo,ucbvax}!b.gp.cs.cmu.edu!ralf =-=-=-=-=-=-=-=- ARPAnet: RALF@B.GP.CS.CMU.EDU BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA AT&Tnet: (412) 268-3053 (school) FIDOnet: Ralf Brown at 129/31 DISCLAIMER? Who ever said I claimed anything? "I do not fear computers. I fear the lack of them..." -- Isaac Asimov