fix #H6861 - whatis behaves weirdly with plurals

Report indicated that looking up "more info?" for "kittens" would show
the data.base entry for "kitten" and then when the display window was
dismissed, another "--More--" prompt for a empty second display window
would occur.  Looking up "2 arrows" from a closely-seen object on the
map behaved similarly.  User correctly diagnosed that the two-pass
lookup left the 'found_in_file' flag set from the first pass during
the second but that just clearing that resulted in "I have no info
about such things" on the second pass.  The code is on the convoluted
side and needed an extra flag to handle 'seen on first pass' in
addition to clearing found flag after the first pass.  I also added a
check to skip the second display if primary and secondary keys don't
match each other but both find the same entry.  To test it, I tried
"a +0 aklys named aclys".  That found the aclys entry but failed to
find "+0 aklys", so I added another change to have the key massaging
remove +/-N after removing "a", "an", or "the".

If "Want to see more info \"" + lookup string + "\"?" was too long,
the prompt buffer passed to yn() was being left uninitialized.  Also,
test for too long was based on BUFSZ but yn() complains (to paniclog)
if the prompt is longer than QBUFSZ.  Make checkfile() construct a
truncated prompt if the lookup string is too long.

I untangled some spaghetti by making all the 'goto's be forward.  It
didn't help a lot but did simplify a few early returns by having them
jump to a common exit instead of replicating the file close.
This commit is contained in:
PatR
2018-02-24 19:35:56 -08:00
parent 5dd6c05322
commit f44ff54c7f
3 changed files with 119 additions and 59 deletions

View File

@@ -509,8 +509,10 @@ the Wizard, Angels and lawful minions, the Riders, shopkeep/priest in own room
are never frightened by tooled horns
'Iu' would reveal unknown container contents if carrying one unpaid item inside
a hero-owned container whose contents weren't known
docall wasn't taking the space allocation needed for the object name + "Call :"
into account in the prompt string
docall for type of object could overflow its prompt buffer if there was a very
long type name previously assigned
whatis lookup for 'more info?' would behave strangely for plural names, either
entered by player or from "N foo" stacks on the map
Fixes to Post-3.6.0 Problems that Were Exposed Via git Repository