The player name is stored in whoami[], which is length 80 in most games
(1024 in rogue5). Only the first 10 chars were used to create
file_name, because that buffer is the same length. Increasing the size
of file_name to 256 permits using all of whoami.
The name is also no longer truncated to 20 chars when writing the log.
All games should now be able to handle 79-character names without
collisions. Anything more would break save compatibility.
In rogue5/state.c, rs_read_daemons() zeroes out the argument and delay
if the daemon slot is empty. Unfortunately that code ended up on the
wrong side of the brace that closes the for loop, so instead of running
after each daemon, it got run once after the loop exited, when the
index was of course out of bounds.
This tended to manifest, when compiled with -O2, by overwriting hw and
setting it to NULL. When inventory() next ran, hw would be passed to
wgetch(), which returns ERR when it gets a NULL argument. This made
md_readchar() think something was wrong and autosave the game.
Upon investigation, rogue3 was found to commit the same mistake.
rogue4 and srogue don't zero the data. arogue5 already does it
properly.
Someday I am going to run all this through Valgrind. Someday when I
am a kinder person who will not be driven to invoke hordes of trolls
and centaurs upon the original authors.
md_readchar() mapped KEY_BACKSPACE to CTRL-H, but get_str(), which
handles prompts for strings, only backs up when it receives the erase
character. The key should be mapped to md_erasechar().
This fixes Red Hat Bugzilla #847852.
In all games, rs_write_room_reference() stored -1 for a nonexistent
room, but rs_read_room_reference() did not check for out-of-bounds
values, leading to pointers to rooms[-1], which sometimes caused
crashes. rs_read_room_reference() has now been modified to use NULL
instead.
Some of the games required further changes to replace NULL with the
pointer to the actual room. Others are capable of handling NULL for
objects not in any room.
