readobjnam()'s "overlapping strcat"
commit272d32b343d8dcf515d072956a20602803a13e9d
authorPatR <rankin@nethack.org>
Sat, 14 Nov 2015 08:46:19 +0000 (14 00:46 -0800)
committerPatR <rankin@nethack.org>
Sat, 14 Nov 2015 08:46:19 +0000 (14 00:46 -0800)
tree2f9a066878a76cf40d42d65aad80e05895a9a925
parentffcc6f1bc2943cc63ad1e07d9bd14f678e21ca9d
readobjnam()'s "overlapping strcat"

Replace the code that uses strcat with two pointers into the same buffer.
Treated separately, they point at distinct strings (no overlap possible),
but the C standard does disallow that in order to enable optimizations
using block transfer or such, so the tool that complained about it isn't
wrong.  The characters getting appended to the output pointer can end
up overlapping the beginning of the other input pointer, conceivably
breaking an implementation that didn't use simple left-to-right byte-at-
a-time copying.

Also, I noticed that wishing for "luck stone" gave me a random gem.
There's code to strip off " stone" and compare against gem types, but it
prevents other code that accepts "foo bar" as a match for "foobar" and
vice versa from finding a match, since "luck" doesn't match anything
once "stone" is gone.  So add the four gray stones into the array of
alternate spellings.

Another bit:  it now accepts " gem" in addition to " stone" as optional
gem suffix, so "ruby", "ruby stone", and "ruby gem" all yield ruby.
("luck gem" won't work; you'll end up with a random gem-class object.)

And a last other bit:  wishing for "lamp (lit) named foo" would yield
an unlit, unnamed lamp because "(lit)" followed by anything didn't match
"(lit)" and threw away everything past the opening paren.  Now it will
produce "lamp named foo (lit)"--a lit lamp named "foo".  (Wishing for
"lamp named foo (lit)" produces an unlit lamp named "foo (lit)".  That's
acceptable to me... I'm not crawling any farther down this hole.  Maybe
object formatting should be changed to keep the lit attribute in front
of the name?)
src/objnam.c