Add missing 'sysconf' to sys/unix/ and sys/winnt/ sections of Files.
Update sys/unix/sysconf; I started out just to remove the duplicate
DEBUGFILES entry but ended up expanding several of the comments too.
Also, fix a typo in the vms build/install instructions.
Update the unix Makefiles and the older OSX hints files to handle the
pile marker tile overlay. I didn't touch hints/macosx10.10 and .11
since I think there's still a merge for them pending.
A couple of formatting tweaks for bemain.c are included, for no
compelling reason. What are the odds that anyone will every build
that again?
Confusing build failure, explained by a typo in sys/unix/Makefile.utl.
dgn_lex.o didn't get rebuilt after modifying unixconf.h to take out
the #define MONITOR_HEAP I had in place, resulting in link failure for
dgn_comp because the old object file was referencing 'nhalloc' rather
than 'alloc'. dgn_lex.o accidentally didn't care about modifications
to config.h and the other headers that pulls in, such as unixconf.h.
This typo was already present when the last cvs repository was
initialized nearly 14 years ago.
I tracked down the widest lines, which sometimes occur due to mis-indent
of block comments (see tradstdc.h for an example), and fixed those up.
For the files affected, I also converted tabs to spaces.
A couple of macros with comments in the midst of their expansions got
badly mangled by the automated reformat and one ended up with a line
that was over 150 characters wide.
Some reformatting (replacing tabs with spaces), but mostly updating some
of the comments, particularly about SYSCF.
Shouldn't GENERIC_USERNAMES be controllable via SYSCF?
When reading a novel, select a random passage which hasn't been shown
already. Once you've run through all the passages, it resets to get
them all again (with new random order that might happen to the be same
order if there aren't many passages). Switching to a different novel--
even another copy of the same one--will cause the previous passage
selection to be discarded and restarted from scratch if the prior book
is read again. Passage tracking for the most recently read novel is
kept across save and restore. (That means I needed to bump EDITLEVEL,
so it will need to be reset to 0 again before release.)
Keep window bookkeeping up to date when tty interface is shuting down.
The other interfaces should do something similar when they make windows
known to the core become unavailable.
exit_nhwindows() is called before terminate(), and the tty incarnation
destroys all windows--including 'pickinv_cache_win'--without setting
the various index variables used to access them to WIN_ERR, then
terminate() calls freedynamicdata() which calls free_pickinv_cache()
which tries to destroy 'pickinv_cache_win' since it isn't WIN_ERR (if
the perm_invent option has been enabled during that playing session).
Some of the other <interface>_exit_nhwindows() also tear things down
without resetting the variables used to track them, so fixing this in
exit_nhwindows() would have been pretty messy.
Call free_pickinv_cache() before exit_nhwindows() in done(). At the
moment it's only called from done(), so other exit paths won't release
the small chunk(s) of memory used for the alternate inventory window
(if it got created for perm_invent support).
Replace the code that uses strcat with two pointers into the same buffer.
Treated separately, they point at distinct strings (no overlap possible),
but the C standard does disallow that in order to enable optimizations
using block transfer or such, so the tool that complained about it isn't
wrong. The characters getting appended to the output pointer can end
up overlapping the beginning of the other input pointer, conceivably
breaking an implementation that didn't use simple left-to-right byte-at-
a-time copying.
Also, I noticed that wishing for "luck stone" gave me a random gem.
There's code to strip off " stone" and compare against gem types, but it
prevents other code that accepts "foo bar" as a match for "foobar" and
vice versa from finding a match, since "luck" doesn't match anything
once "stone" is gone. So add the four gray stones into the array of
alternate spellings.
Another bit: it now accepts " gem" in addition to " stone" as optional
gem suffix, so "ruby", "ruby stone", and "ruby gem" all yield ruby.
("luck gem" won't work; you'll end up with a random gem-class object.)
And a last other bit: wishing for "lamp (lit) named foo" would yield
an unlit, unnamed lamp because "(lit)" followed by anything didn't match
"(lit)" and threw away everything past the opening paren. Now it will
produce "lamp named foo (lit)"--a lit lamp named "foo". (Wishing for
"lamp named foo (lit)" produces an unlit lamp named "foo (lit)". That's
acceptable to me... I'm not crawling any farther down this hole. Maybe
object formatting should be changed to keep the lit attribute in front
of the name?)
The fun stuff section in config.h contains nothing fun anymore,
so let's remove it. Move SCORE_ON_BOTL to the next section,
and add couple other defines there too.
The memory leak (monst->mextra->edog, monst->mextra->mname,
monst->mextra for some monster were not released) I noticed recently
was due to recording a pet's full monster attributes with its corpse.
During save and restore, obj->oextra->omonst was being treated as a
full-fledged monster so worked as intended, but when freed, omonst
was treated as a black box and its mextra details weren't handled.
Use casts to try to suppress a couple of assignments of long to short
that Michael's compiler warns about. 'cw->maxrow' might have a value
that's too big for 'short' (when dealing with really big menus), but
'cw->maxcol' never will (unless someone comes up with a terminal or
emulator that's wider that 32K-1 characters...).
dungeon.o depending on lev.h is the only change found by 'make depend'.
(I'm a bit suspicious about that.)
I haven't attempted to reconcile the vms Makefiles with the Unix ones,
just put in this one new dependency. I know vms/Makefile.src lacks
handling for sys/share/*regex.c and vms/Makefile.top and install.com
both lack handling for 'sysconf'.
> Somebody has changed versioning so that the game incorrectly states
> 3.6.1 in messages. It looks like someone updated patchlevel instead of
> editlevel?
Yes, that was me. I meant to increment EDITLEVEL and nobody noticed
the mistake until now....
This changes PATCHLEVEL back to the correct value of 0, and implicitly
resets EDITLEVEL to 0 for release (by not changing it to 1 as it was
supposed to have been for the past 3-4 weeks).
Data files from Oct. 18 through today are actually compatible but will
be rejected once anyone rebuilds with this fix, same as would happen
when EDITLEVEL changs. Data files from before Oct. 18 will be
incompatible but be accepted by nethack but not work correctly due to
a change in the 'context' structure.
Changes to be committed:
modified: src/objects.c
modified: win/share/tilemap.c
Warnings during tile builds (and incorrect tile mappings
at run time when MAIL wasn't defined):
Creating 16x16 binary tile files (this may take some time)
warning: for tile 325 (numbered 325) of objects.txt,
found 'ETAOIN SHRDLU' while expecting 'stamped / mail'
warning: for tile 326 (numbered 326) of objects.txt,
found 'LOREM IPSUM' while expecting 'ETAOIN SHRDLU'
The recent addition of the first new extra scroll descriptions in a
very long time caused this problem to show up when MAIL was undefined.
There was a magic number in use that made an assumption that there
were only 4 such extra scroll descriptions, those being
"FOOBIE BLETCH", "TEMOV","GARVEN DEH","READ ME"
Release some dynamically allocated memory prior to exit. These were
previously left alone due to assumed complexity (at least by me...),
but dealing with them turned out to be straightforward.
|#if FREE_ALL_MEMORY
free BASE_WINDOW -- tty-specific; other windows are drawn on top of it
free ttyDisplay -- tty's basic data structure
|#endif
free nh_HI, nh_HE -- termcap values handled differently from the rest
These are the last things that 'heaputil' always reported as not freed
for the basic Unix+tty configuration. (I've observed other things not
being freed; those are post-3.4.3 bugs that need to be found and fixed.)
This isn't urgent, but I figure that until the mac build stuff gets
merged in, the core is still fair game....
'O' command's autopickup_exceptions was freeing a menu pick-list even
when it hadn't been allocated (for the list case, and for the remove
case if nothing was chosen for removal). That code was evidently used
as the model for msgtype and menucolors; they had the same situation.
I think ANSI and ISO sanction free(NULL) as a no-op, but pre-ANSI free
implementations don't necessarily handle that benignly. Even if they
all do, freeing something--even if that 'something' is nothing--which
hasn't been allocated is a bug on our end.