gcc has recognized various "magic comments" for white-listing
occurrences of implicit fallthrough in switch statements for
a long time:
The range and shape of "falls through" comments accepted are
contingent upon the level of the warning. (The default level is =3.)
-Wimplicit-fallthrough=0 disables the warning altogether.
-Wimplicit-fallthrough=1 treats any kind of comment as a "falls through" comment.
-Wimplicit-fallthrough=2 essentially accepts any comment that contains something
that matches (case insensitively) "falls?[ \t-]*thr(ough|u)" regular expression.
-Wimplicit-fallthrough=3 case sensitively matches a wide range of regular
expressions, listed in the GCC manual. E.g., all of these are accepted:
/* Falls through. */
/* fall-thru */
/* Else falls through. */
/* FALLTHRU */
/* ... falls through ... */
etc.
-Wimplicit-fallthrough=4 also, case sensitively matches a range of regular
expressions but is much more strict than level =3.
-Wimplicit-fallthrough=5 doesn't recognize any comments.
Plenty of other compilers did not recognize the gcc comment convention,
and up until now the compiler warning for detecting unintended
fallthrough had to be suppressed on other compilers. That's because the code
in NetHack has been relying on the gcc approach, and only the gcc approach.
The C23 standard introduces an attribute [[fallthrough]] for the
functionality, when implicit fallthrough warnings have been enabled.
Several popular compilers already support that, or a very similar attribute
style approach, today, even ahead of their C23 support:
C compiler whitelist approach
--------------------------- -------------------------------------
C23 conforming compilers [[fallthrough]]
clang versions supporting
standards prior to
C23 __attribute__((__fallthrough__))
Microsoft Visual Studio
since VS 2022 17.4.
The warning C5262 controls
whether the implict
fallthrough is detected and
warned about with
/std:clatest. [[fallthrough]]
This adds support to NetHack for the attribute approach by inserting a
macro FALLTHROUGH to the existing cases that require white-listing, so
other compilers can analyze things too.
The definition of the FALLTHROUGH macro is controlled in include/tradstdc.h.
The gcc comment approach has also been left in place at this time.
Issue reported by elunna: sleeping mimics can grab the hero, and
zapping a concealed mimic with a wand of sleep describes the target
as a mimic but doesn't bring it out of concealment.
The grab-when-asleep case is reasonable. It's a reflexive counter-
attack by a magical creature. And the mimic wakes up in the process.
But the mimic wasn't being brought out of concealment. Do that.
Unconceal mimics hit by wand of sleep unless already sleeping.
Fixes#1299
Issue reported by youkan700: shape change anomalies. Shapechangers
could change shape despite active protection-from-shape-changers if
hero wore two rings of protection from shape changers and took one
off. Shapechangers who migrated to a not-yet-visited level that
eventually got visited with protection from shape changers in effect
would be stuck in their current shape, even if the PfSC attribute
got toggled off and back on.
The issue included suggested fixes and those are what I've used. I
noticed a third case that only applies to wizard mode: if player
used #wizintrinsic to set a timed value for PfSC, monsters wouldn't
resume changing shape after it timed out, unless/until it got toggled
on and back off via a PfSC ring or hero left the level and returned.
Fixes#1312
If a vampire in fog cloud form moves under a closed door and then
before moving further gets killed and revives in vampire form,
destroy the door instead of moving the vampire to a nearby open
spot (which might be a distant spot if the map is crowded). If the
door is trapped, explode the trap. That will damage the vampire but
usually not by enough to kill it.
This probably ought to be generalized to be done for any shape change
at a closed location but I ran out of gas.
Change noit_mon_nam() to work as if it was noit_y_monnam() (without
renaming it or adding yet another monster naming routine) to use
"your <mon>" rather than "the <mon>" when <mon> is a pet that can
be seen (so not the case where "it" gets replaced by "someone" or
"something").
Commit c4a1f298e8 two and a half
months ago gave lawful Angels and Archons a chance to start with
a mace instead of a long sword so that they might get Demonbane.
It was a bit convulted; this redoes it to be more straightforward.
Fix a FIXME in Amulet_off() for removing an amulet of magical
breathing when within a poison gas cloud.
Redo message sequencing for both Amulet_on() and Amulet_off().
Use up an amulet of change if put on while the Unchanging attribute
is active (via #wizintrinsic) instead of wearing it with no effect.
Don't discover amulet of strangulation if put on while already
Strangled (via #wizintrinsic).
Add enlightenment feedback for Sunsword's blocking of becoming blind
from light flashes. It uses an extra property so that wizard mode
can report the reason.
EDITLEVEL is being incremented, so existing save and bones files are
invalidated.
When accessiblemsg is Off, coordiates supplied for various messages
stayed put after becoming stale. If you used 'mO' to toggle that
option On, you could see things like
(2east):'accessiblemsg' option toggled on.
After that, accessibility message coordinates behaved as intended.
Clear a11y.msg_loc.x,y for every pline instead of just when they
are used to augment the current message.
Most players who use accessiblemsg are bound to set it in their
config file rather than toggle it interactively so never noticed.
Misc 1: option.c doesn't need '#include <ctype.h>' because
cstd.h includes it unconditionally. Several other src/*.c are in
the same situation but I didn't touch them.
Misc 2: move set_msg_dir() and set_msg_xy() out of a warning
suppression block that isn't relevant to them.
If eating a tin killed the hero (choked, turned to stone, poly'd into
a new man with new Xp too low to survive) and bones were saved, the
tin remained intact in them.
When hero who is poly'd into metallivore form eats a tin, give a
little extra nutrition for the tin itself. Also, eat it immediately
by skipping the "It smells like <creature>" message and "Eat it? [yn]"
prompt. (The message while eating it also reports <creature>, so
skipping the 'smells' one doesn't end up hiding anything.)
In sys_early_init(), the values for sysopt.gdbpath and
sysopt.greppath were being assigned by calling dupstr()
without ensuring that a value previously assigned by
dupstr() were free()'d.
Also, the sysopt struct definition is changed to sysopt_s,
not because there's anything wrong with the original
struct sysopt sysopt;
but because I couldn't convince the debugger to use the
correct thing when trying to track down the leak.
This is additional groundwork related to
https://github.com/NetHack/NetHack/issues/1320
This additional groundwork just puts some safeguards
in place to make it rather tough to end up with an
instant death from handling a cockatrice corpse in
your inventory without appropriate protection.
At this point, still no actual petrification will occur.
Wishing is powerful, so if you cannot safely handle a cockatrice
corpse, then have a wish for one result in the corpse materializing
on the floor rather than in your inventory.
Resolves#1320
Related to #1309https://github.com/NetHack/NetHack/issues/1309
K2 commented: "This might help - k21971/EvilHack@afed641"
A comment in there states:
"Fix: sections of wall being visible when they shouldn't yet.
This has been a long-standing bug for as long as I can remember, and qt
appears to have figured it out. What was happening: the player would all
of the sudden see a section of wall in an area that they hadn't explored
yet. It was discovered that this was only occurring if that section of
wall had any type of tree up against it."
The fix there attempts to leave trees out of the check_pos non-zero return,
so give that a shot.
I didn't attempt to reproduce the situation myself,
and therefore cannot confirm that this does resolve it.
Feedback on effectiveness or side-effects are welcomed. If someone is
able to confirm that this resolves the issue without creating new
issues, we can close it, otherwise this can be reverted.
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/1315https://www.reddit.com/r/nethack/comments/1gkc9ub/even_if_you_drop_an_item_before_drinking_from_the/
Commit 22884522, ported (from Sporkhack, Evilhack), added the ability
for monsters to maintain awareness of player resistances that they
observed.
Since they will refrain from using a ranged attack that they deem
futile, take the specific monster's seen_resistance field into consideration
when choosing code paths based on the availability of ranged attacks.
Resolves#1307
