Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!rochester!PT!b.gp.cs.cmu.edu!ralf
From: ralf@b.gp.cs.cmu.edu (Ralf Brown)
Newsgroups: comp.sources.bugs
Subject: Re: Minor fixes to NetHack 1.4f (and another)
Message-ID: <85@b.gp.cs.cmu.edu>
Date: Mon, 24-Aug-87 07:29:52 EDT
Article-I.D.: b.85
Posted: Mon Aug 24 07:29:52 1987
Date-Received: Tue, 25-Aug-87 01:43:18 EDT
References: <83@b.gp.cs.cmu.edu> <1438@brahma.cs.hw.ac.uk>
Organization: Carnegie-Mellon University, CS/RI
Lines: 63

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