If your inventory is full and you aren't already carrying a loadstone,
you can pick one up into the overflow slot. But if you are already
carrying one and the one you're trying to pick up won't merge with it
(only criterium that matters would be BUC state, I think), you can't
pick it up and get a message saying so. If loadstone isn't known
yet, the message always referred to it as "gray stone" rather than
"stone called <whatever-you-called-it>".
Replace the single strnlen() use with strlen() so as not to require
something from posix.1 (2008) when we supposedly only require c99.
If someone manages to produce a string that's longer than will fit
within size_t, strlen()'s length count will wrap and Strlen_() might
not notice. Since size_t has to be at least 32 bits, that doesn't
seem like something to worry about.
If checking for size_t overflow is considered essential, we should
just switch to counting the length via an in-line loop that imposes
a similar limit to strnlen().
When ready to return, check for overlooked overflow (shouldn't happen)
and panic, or report the first excessively long but not overflown
description to paniclog, similar to xname.
Make ConcUpdate() more robust by not needing bp_eos to be previously
set. Less efficient but I think that boat has left the barn? :=}
Fix a comment typo.
Issue reported by Umbire: suggestion to always destroy adjacent webs
via 'F'<dir> if wielding Sting or Fire Brand.
Sting already did that; this adds Fire Brand.
This also augments the #untrap command when wielding either of those,
or any other blade. And rephrases successful untrap message
"You remove {the or your} {bear trap or webbing} from Fido." to
"You extract Fido from {the or your} {bear trap or web}." since the
trap remains intact.
Forcefight and #untrap against webs ought to be reconciled to remove
[some of] their differences and/or share code. But not by me...
Closes#1201
Avoid two new warnings in xname_flags() about strncpy() not supplying
a terminating '\0'. That's exactly why strncpy() was being used.
The gcc manual lists -Wno-stringop-truncation to suppress the warning
but not -Wstringup-truncation to voluntarily enable it, so the pragma
stuff in warnings.h probably won't work for this. Just switch from
strncpy() to memcpy() instead even though it seems like obfuscation.
u_init.c had had assessments for nonnull arguments on
its local functions carried out already.
A couple of new static functions added earlier today immediately
dereference their args, so declare those as nonnull.
This also gives a more self-describing name to one arg.
PR #1140 added checking the thrown, stolen, and dropped flags of an
item when testing whether it would merge (at my suggestion...) with
a stack in the target list (hero's invent). That interferred with
picking it back up--whether via autopickup or explicit pickup--while
inventory was full even when the item would otherwise be mergable.
There was some trial and error involved when trying to figure where
to put the fix but things seem to be working.
This replaces a static analyzer workaround and could possibly bring
its unwarranted complaint back.
Try harder to prevent buffer overflow when formatting objects.
I don't have any test cases where overflow has been happening so
don't really know whether this works reliably. And it doesn't try
to check prefix construction by doname(). [Yet?]
Run GC on the themeroom lua states, as they're not freed
until end of game.
Allocate the exact amount of data we use instead of padding it.
Free our state data after closing the lua state; doing it
the other way is the way to madness, which was kept at bay
by the padded allocation amount.
Have monster spells
| "shower of missiles" (AT_MAGC+AD_MAGM: Angels, Yeenoghu)
scuff an engraving at the hero's spot if there is one,
| "frost" (AT_MAGC+AD_COLD: only Asmodeus)
freeze water and lava terrain,
| "flames" (AT_MAGC+AD_FIRE: moot, no monster has this attack)
burn items on the floor at the hero's spot and melt ice terrain,
| "pillar of flame" (AT_MAGC+AD_CLRC+randomly chosen clerical spell)
which already burns floor items, melt ice too, and
| "lightning" (same casters as pillar of flame)
give a tiny chance of destroying iron bars. The chance to hit bars
is low and the hero has to be targeted while located on an iron bars
spot so probably won't happen before the sun burns out, but only
needed one extra line of code.
Only the first two have been thoroughly tested.
If a covetous monster tried to teleport adjacent to the hero but the
level was too full to move it from its current spot, it would be
sent off level to wait for the hero to leave and return instead just
staying put.
Issue reported by chappg: if a monster or object covered an engraving,
examining that monster or object with farlook would include the text
of the engraving even though it wasn't the thing being examined.
The report was for a bones level but that only mattered because it was
a ghost on top of a grave (and the engraving on its headstone) that was
being examined; bones data itself wasn't pertinent. It would happen
with any engraving once the spot was mapped as an engraving or a grave
provided that something else was currently displayed at the location.
Bug was introduced by commit 389f03e90e
two months ago. Mea culpa.
Closes#1200
Hero attempting to cut an adjacent web can so with secondary weapon
if dual wielding and primary isn't a blade.
Mostly message handling for the 'neither weapon is a blade' situation.
Adds a new boolean option, spot_monsters. If on, every time
the hero notices a monster which was out of sight before,
a message is given. Combine with accessiblemsg to get the
monster location:
(3north): You see a newt.
Breaks saves and bones.
