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

@@ -1236,14 +1236,15 @@ really_done(int how)
display_nhwindow(WIN_MESSAGE, FALSE);
if (how != PANICKED) {
struct obj *obj;
struct obj *obj, *nextobj;
/*
* This is needed for both inventory disclosure and dumplog.
* Both are optional, so do it once here instead of duplicating
* it in both of those places.
*/
for (obj = gi.invent; obj; obj = obj->nobj) {
for (obj = gi.invent; obj; obj = nextobj) {
nextobj = obj->nobj;
discover_object(obj->otyp, TRUE, FALSE);
obj->known = obj->bknown = obj->dknown = obj->rknown = 1;
set_cknown_lknown(obj); /* set flags when applicable */