Fixes#200
The Guidebook claims that there's no symbol for 'S_strange_object'
which is literally true, but there is one for S_strange_obj. It has
been in place longer than the paragraph claiming that there's no way
to customize that symbol. I'm not sure why variant spelling was used.
Also, files.c doesn't use loadsyms[], it calls a routine which returns
a pointer to a specific element in that array.
Make some progress on a couple of next minor release checklist
items, hopefully without introducing too many new bugs. This
is just the initial commit, and work continues.
Checklist items:
Savefiles compatible between Windows versions, whether 64-bit
or 32-bit in little-endian field format.
Selection of file formats:
historical (structlevel saves),
lendian (little-endian, fieldlevel saves),
and just for proof-of-concept, ascii fieldlevel saves
(the ascii is huge! 10x bigger than little-endian).
For the fieldlevel save, all complex data structures recursively
get broken down until until it is one of the simple types that
can't be broken down any further, and that gets when it gets
written to the output file.
New files needed for this build:
hand-coded:
include/sfprocs.h
src/sfbase.c - really a dispatcher to one of the
output/input format routines.
src/sflendian.c - little-endian output writer/reader.
src/sfascii.c - ascii text output writer/reader.
auto-coded (generated):
include/sfproto.h
src/sfdata.c
This is just one approach. I'm sure there are countless others
and they have different pros and cons.
For producing the auto-coded files a utility called
universal-ctags, that is actively maintained and evolving,
was used to do all the heavy-lifting of parsing the
NetHack C sources to tabulate the data fields, and store
them in an intermediate file called util/nethack.tags
(not required for building NetHack if you already have a
generated include/sfproto.h and src/sfdata.c)
util/readtags (also not required for building NetHack
itself) will decipher the nethack.tags file and produce
the functions that can deal with the NetHack struct data
fields.
You can obtain the source for universal-ctags by cloning it
from here:
https://github.com/universal-ctags/ctags.git
The combination universal-ctags + util/readtags has been
tried and tested under both Windows and Linux, so it is
not tied to a particular platform.
Note: util/readtags will work only with universal-ctags
output, so other ctags are unlikely to work as-is.
Universal-ctags can be build from source very easily
under Linux, or under Windows using visual studio.
Observed on a text file with crlf endings on Linux, where the
so-called blank lines weren't being ignored as they should
have been, despite there being a line to remove \r from the
end.
A pointer was being pre-decremented before the check for a
matching whitespace character.
Changing an inventory item's bknown flag wasn't followed by a call to
update_inventory() in many circumstances, so information which should
have appeared wasn't showing up until some other event triggered an
update.
I ran the fuzzer with MONITOR_HEAP enabled and heaputil found a dozen
or so un-free'd allocations, all made by the same dupstr() call in
special_handling() for "symset" and "roguesymset". (Reproducible with
a few tens of thousands of fuzzer moves, although you have to take
over from the fuzzer and make a clean exit rather than just interrupt
it or there'll be lots of other un-free'd memory.) I haven't actually
figured out how/why it was leaking, but reorganizing the code has made
the leak go away (according to a couple of even longer fuzzer runs) so
I'm settling for that.
There was a spurious seli-colon after an if's test, making a boundary
check be ineffective. When looking at that, I noticed that the 'O'
command's display of the current value for mouse_support ("0=off" and
so forth) was relying on implicit concatenation of adjacent string
literals, which would break K&R compilation. Do that concatenation
the old fashioned way....
While testing (after temporarily adding WC_MOUSE_SUPPORT to tty's
window_procs), I also noticed that wording used by config_error_add
looked strange when it was in response to giving a bad value via 'O'
command. Suppress its "config_error_add: " prefix is that situation.
New: call to panic() in impossible() used arbitrary string as a
format so was vulnerable to percent signs in that string. (This
potentially serious problem is not limited to USE_OLDARGS.)
Old: revised message string for impossible ("save/restore might fix
this" instead of "perhaps you'd better quit") passed wrong number of
arguments to pline() when using the clumsy VA_PASSx() mechanism (was
missing arg 0 for the fixed-arg format argument).
Old: varargs config_error_add() in files.c wouldn't compile for
USE_OLDARGS. Evidently no one has been impacted by that but this
fixes it anyway. (Two problems: prototype used FDECL() when it
should have been using VDECL(), and calls to config_error_add() in
the same file would need the VA_PASSx() stuff to force presence of
all optional args. I moved it instead of adding the latter.)
Remove trailing spaces, and remove tabs from the files that had
trailing spaces.
Also, rndorcname() was using a random value to terminate a loop
and was recalculating a new one each iteration.
When entering a new menucolor via options, show regex error
immediately afterwards, instead of asking for color and attribute
before showing the error.
Also actually show config errors even if config error handler
hasn't been initialized.
