There are two hardfought code additions that render save and bones files incompatible
with the upstream NetHack-3.7, and that makes testing with hardfought
save and bones files more challenging than it needs to be, when
investigating and troubleshooting bug reports.
Add some unused fields to advance towards achieving save file parity with
hardfought, which is a significant source of play-testing for NetHack-3.7.
1) the elbereth field addition to u_conduct
This adds an unused placeholder field named 'hf_reserved1', at the appropriate
place in u_conduct to achieve struct field parity with the one in use on
hardfought.
2) hardfought adds a field to struct monst:
char former_rank[25]; /* for bones' ghost rank in their former life */
Instead of adding that to every monst, this adds a new mextra struct
named 'former', which currently contains the equivalent 25-character
field called 'rank' which can hold the content that was in the
former_rank[25] field. That way, the field will only be added when it
is needed.
A pull request https://github.com/k21971/NetHack37/pull/2 has been
done on hardfought to do it the same way (untested there as of yet).
Even though NetHack-3.7 does not utilize that information presently,
this will be a further step toward allowing hardfought-generated save
and bones files to be used for troubleshooting, without modification,
on a similar architecture running stock NetHack-3.7 code.
That savefile parity won't be achieved until the after the
hardfought pull-request mentioned above (or equivalent) is merged.
As this change will not be compatible with existing save and bones
files, it will be accompanied with an EDITLEVEL increment.
Tame earth elemental picked up a no_charge object from a shop and moved
it out of the shop, causing "no_charge obj not inside tended shop"
impossible. Non-tame monsters picking up no_charge items cleared that
bit, so make the same happen for pets.
> if (strlen(simpleoname) > BUFSZ - sizeof "the ")
> simpleoname[sizeof "the "] = '\0';
The second line should have been
| simpleoname[strlen(simpleoname) - sizeof "the "] = '\0';
but fixing that isn't adequate. The BUFSZ limit is not valid when
dealing with object names since xname() leaves room for a prefix so
doesn't return the start of a BUFSZ-sized buffer.
Strangely enough, the complaint that caused me to add those two lines
isn't being triggered any more. Some other change at the same time,
perhaps splitting
Strcpy(simpleoname, obufp = the(simpleoname));
into
obufp = the(simpleoname);
Strcpy(simpleoname, obufp);
pacified the analyzer. However, it didn't resolve the valid complaint
that inserting "the " might result in overflow.
I've added a comment about simpleonames(), ansimpleoname(), and
thesimpleoname() about the possible overflow, but I don't think that
such overflow can actually happen when user-applied object name is
being suppressed.
This construct triggered several complaints about passing Null to
Strcpy(simpleoname, obufp = the(simpleoname));
Changing that to
obufp = the(simpleoname);
Strcpy(simpleoname, obufp);
prevents it, but the original complaint is bogus and the "fix"
doesn't do anything to deal with Null arguments.
A couple of other changes introduce different code in order to get
different behavior. I updated from llvm-16 to llvm-19 but didn't
eliminate any of the spurious complaints.
Clear "next" boulder so that when pushing a pile of boulders, only
the first message for each of the 2nd, 3rd, &c will be formatted as
"next boulder". If any of them trigger additional messages, those
messages will use normal "boulder".
Commit 1acc2727 helped ensure that the which_armor(mtmp, W_SADDLE)
test at the top of put_saddle_on_mon() wouldn't lead to an obj
leak.
This commit covers off the adjacent can_saddle() test in
put_saddle_on_mon(), because if that failed, it could also lead
to a memory leak of the saddle obj passed by the caller.
- have put_saddle_on_mon() create and use its own saddle obj
if a NULL saddle obj is passed, instead of having to do that
in the caller.
- where an existing saddle obj needs to be passed from the caller,
ensure that the caller has done its own can_saddle(mon) check prior
to calling put_saddle_on_mon(), so that the can_saddle() test
in put_saddle_on_mon() won't fail.
- lastly, add an impossible() to put_saddle_on_mon() to catch
a failure when a saddle obj is passed from the caller and either
test has failed, just in case. That should not happen with any of
the existing cases now, but it will provide some bullet-proofing
for new code, new callers.
makemon() has a 1% chance to bestow a worn saddle when creating any
rideable monster. If that chance kicked in on a knight's starting
pony, an extra saddle would end up being created but not worn nor
in inventory nor on floor so not be freed when the game ended.
That 1% chance also overrode saddle suppression for pauper knights.
There wouldn't be any extra saddle but their pony could start with
one, against intent.
Have makedog() (which is only used for starting pet) tell makemon()
to suppress inventory when creating the initial pet.
Overzealous change yesterday. For use_defensive(), the unicorn
horn case already has guards for Null item and the added one
issues bogus panic() when a unicorn or ki-rin uses its own horn.
I'm not really sure about this one. insert_branch(branch,) is
specified as not accepting a Null pointer and doesn't have any
defense against it, but the know level setup seems to allow a null
pointer through. I'm not sure whether this is the right fix.
If one or more boulders were next to lava and hero broke a wand of digging
next to that location, the boulder(s) stayed over the lava causing a sanity
checking error.
The missing break meant that executation fell through to the default
case and reset xlocale and ylocale to 0. The comment states that
this is for the fuzzer; I have no idea whether this fix matters to it.
Verifying that strlen(string) isn't too long, then allocating and
copying strlen(string)+1 draws a complaint about strcpy() overflowing
its output buffer.
Not an issue for regular play, but could matter for config file and
sysconf manipulation.
Picked arbitrarily; there weren't any unresolved analyzer complaints
for trap.c. I wonder why the onefile analysis isn't complaining here.
'in_sight' may have been relevant before the trapeffect_xyz() code
was split apart, but it isn't useful for trapeffect_hole() despite
the comment about it.
release_holding_trap() is fairly convoluted and the complaints being
addressed here were relevant.
This cleans up analyzer feedback in shk.c, based on the set of
warnings specified by hints/MacOS.370 and the lower level hints it
applies, rather than anything specified during periodic 'onefile'
processing.
shk.c is the only file I've analyzed, to try again to figure out
how to suppress the old complaint that has been causing a special
case in Genonefile. It isn't triggering during my testing but that
might be due to something in use by onefile but not by normal hints.
I'm running ccc-analyzer from llvm-16; I don't know whether that
matches Genonefile.
Casting charm monster with pets nearby could reset the edog struct.
If the pet ate a mimic corpse and was pretending to be something else
when that edog reset happened, the sanity checking would issue an impossible.
The error happened because meating was reset, but the pet appearance was not,
but the edog struct reset is the part being wrong. Lets not do that.
To reproduce, turn on sanity checking, create a tame dog, give it a mimic corpse
to eat, #wizcast charm monster next to it.
