iterating gi.invent (github issue #1315)

GitHub issue #1315 points out that it is possible for
a downstream function to change an object's nobj field
to point to a completely different chain.

The cited example by @vultur-cadens was:

     for (obj = gi.invent; obj; obj = obj->nobj)
         if (obj->oclass != COIN_CLASS && !obj->cursed && !rn2(5)) {
             curse(obj);
             ++buc_changed;
         }

    curse() drops the weapon with drop_uswapwep(),
        which calls dropx(),
            which calls dropy(),
                which calls dropz(),
                    which calls place_object().

place_object alters the nobj pointer, to point to the floor chain:
    otmp->nobj = fobj;
    fobj = otmp;

The result was that the next loop iteration was then using floor
objects from the floor chain.

This alters several for-loops to use a more consistent approach,
particularly when the obj is being handed off to a function,
where a downstream function might, or might not, alter the nobj
field.

References:

https://github.com/NetHack/NetHack/issues/1315
https://www.reddit.com/r/nethack/comments/1gkc9ub/even_if_you_drop_an_item_before_drinking_from_the/
This commit is contained in:
nhmall
2024-11-06 16:59:51 -05:00
parent b953625e5b
commit e863583c56
10 changed files with 55 additions and 31 deletions

View File

@@ -2626,15 +2626,17 @@ dozap(void)
staticfn void
boxlock_invent(struct obj *obj)
{
struct obj *otmp;
struct obj *otmp, *nextobj;
boolean boxing = FALSE;
/* (un)lock carried boxes */
for (otmp = gi.invent; otmp; otmp = otmp->nobj)
for (otmp = gi.invent; otmp; otmp = nextobj) {
nextobj = otmp->nobj;
if (Is_box(otmp)) {
(void) boxlock(otmp, obj);
boxing = TRUE;
}
}
if (boxing)
update_inventory(); /* in case any box->lknown has changed */
}