I forced a test compile to -std=c++20 mostly to see what we would
be up against. There was only a small number of things and they
are corrected in this commit.
c++20 has some issues with comparisons and bit twiddling between
different enums.
The vendor-supplied Qt5 header files triggered some of those issues as
well, so the qt_pre.h and qt_post.h NetHack header files were adjusted
to make those new warnings go away. I have not tested Qt6 under the
new compiler and c++ version yet.
Because there are multiple pragmas in qt_pre.h now, the conditional
ifdef structure in there was modified a little to make maintenance
simpler and have a single pragma push at the top. The pragma pop
comes after the Qt vendor-supplied header files, and is done
in qt_post.h.
The display.h macro cmap_to_glyph() was used in
a Qt c++ file and triggered a series of warnings because of that.
Rather than write c++20-friendly versions of those macros, the
simple fix is to provide a function on the C side of things
to front the cmap_to_glyph() macro, so fn_cmap_to_glyph()
was added.
Also thrown into this commit, PatR picked up on the fact that for
yesterday's new warning in qt_menu.cpp, the compiler had correctly
picked up on the fact that the format range of the variable 'cash'
had been correctly upper-capped at 999999999L in the warning message
because of an assignment prior. He suggested that perhaps by also adding
if (cash < 0)
cash = 0;
the warning might be eliminated altogether.
After a test, that was proven to be correct, so yesterday's
more-kludgy change is reverted and replaced with that variable
variable restriction ahead of the snprintf().
A test build with gcc-12 cause two new warnings to appear.
mkmaze.c: In function ‘makemaz’:
mkmaze.c:983:44: warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=]
983 | Sprintf(protofile, "%s%d-%d", g.dungeons[u.uz.dnum].proto,
| ^
In file included from ../include/config.h:665,
from ../include/hack.h:10,
from mkmaze.c:6:
../include/global.h:262:24: note: ‘sprintf’ output between 4 and 31 bytes into a destination of size 20
262 | #define Sprintf (void) sprintf
mkmaze.c:983:17: note: in expansion of macro ‘Sprintf’
983 | Sprintf(protofile, "%s%d-%d", g.dungeons[u.uz.dnum].proto,
| ^~~~~~~-+
As usual, that one can easily be rectified by replacing it with an Snprintf() call.
There were several Sprintf calls in the vicinity, targeting the same destination
buffer, so I figured that I might as well replace the several.
../win/Qt/qt_menu.cpp: In member function
‘virtual void nethack_qt_::NetHackQtTextWindow::UseRIP(int, time_t)’:
../win/Qt/qt_menu.cpp:1082:63: warning:
‘%ld’ directive output may be truncated writing between 1 and 20 bytes into a region
of size 17 [-Wformat-truncation=]
1082 | (void) snprintf(rip_line[GOLD_LINE], STONE_LINE_LEN + 1, "%ld Au", cash);
| ^~~
../win/Qt/qt_menu.cpp:1082:62: note: directive argument in the range [-9223372036854775808, 999999999]
1082 | (void) snprintf(rip_line[GOLD_LINE], STONE_LINE_LEN + 1, "%ld Au", cash);
| ^~~~~~~~
../win/Qt/qt_menu.cpp:1082:20: note: ‘snprintf’ output between 5 and 24 bytes into a destination of size 17
1082 | (void) snprintf(rip_line[GOLD_LINE], STONE_LINE_LEN + 1, "%ld Au", cash);
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That one was a little different. It wasn't complaining about the destination buffer
size in the way -Wformat-overflow was on the previous warning from gcc, and it
was already using snprintf().
It looks like what the C++ compiler was warning about there, was that snprintf()
informs you after-the-call that the destination buffer was too small for the
result string to be fully written. It informs the developer of that by returning
the number of characters that would have been written if the buffer had been big
enough. Presumably, the C++ compiler picked up on the fact that the return value
was being cast to void, thus throwing away that truncation information from the
return value.
Worked around it by putting the return value into a variable, and flagging the
variable with nhUse(variable) so as not to exchange the -Wformat-truncation
warning with a variable-set-but-not-used warning.
starting screen (Issue #783)
On 2022-06-01 12:22 p.m., NetSysFire wrote:
> Steps to reproduce:
>
>1. Get any prompt and answer it. In my case it was a horribly old
> save I forgot about or when I wiztested something and forgot
> about that save, too.
>2. See that the copyright information got overwritten by the prompt:
>
>There is already a game in progress under your name. Destroy old game? [yn] (n)
> By Stichting Mathematisch Centrum and M. Stephenson.
> Version 3.7.0-59 Unix Work-in-progress, built May 31 2022 12:28:31.
> See license for details.
>
>
> Shall I pick character's race, role, gender and alignment for you? [ynaq]
>
> Expected behavior:
>
> Redraw after a prompt was answered, so the prompt vanishes and the
> entirety of the starting screen will be shown.
>
> NetHack, Copyright 1985-2022
> By Stichting Mathematisch Centrum and M. Stephenson.
> Version 3.7.0-59 Unix Work-in-progress, built May 31 2022 12:28:31.
> See license for details.
>
>
> Shall I pick character's race, role, gender and alignment for you? [ynaq]
>
> Proposed severity: low. Not gamebreaking, it is cosmetic only and does
> not have any other consequences.
>
The Copyright notice is placed by tty internal routines writing onto
the BASE_WINDOW fairly early in the startup sequence.
The prompt to "Destroy old game? [yn] (n)" is using the in-game
routine to write to the message window at the top of the screen and
prompt there, just like in-game prompts and messages.
If the player answered 'y' to that, the prompt for
"Shall I pick character's race, role, gender and alignment..."
appeared immediately after. That one, however, is written using
the BASE_WINDOW routines in tty, like the copyright notice.
This change does the following:
It moves the copyright lines down a little bit leaving room for the
"Destroy.." prompts.
It places the "Shall I pick characters's..." prompt further down the
screen by default, leaving some room for about 3 raw_print startup
messages after the copyright notice, just in case there are any.
The "Shall I pick character's..." prompt will still appear immediately
if there is a prompt such as "Destroy old game?..."
There were a couple of other issues around raw_print startup messages
too. Those are delivered using a raw_print mechanism to ensure they
are written even if the window-port is not fully operational. However,
they were only on the screen for the blink of an eye. This call
sequence in restore.c made them disappear almost immediately:
docrt() -> cls()
Put in a mechanism to detect the presence of raw_print messages
from the early startup, and if there were some, wait for a
keypress before obliterating the unread notifications.
Add new routine 're_alloc()' that functions as MONITOR_HEAP-aware
libc realloc(). 'nhrealloc()' is the version that passes source
file and line info if built with MONITOR_HEAP enabled. The heaplog
data might now contain '<' (freed by realloc), '>' (replacement
allocation by realloc), and '*' (resized by realloc) entries in
addition to the previous '+' (allocated) and '-' (freed) entries.
heaputil has already been updated in the NHinternal repository.
Move FITSint_() and FITSuint_() from hacklib.c to alloc.c so that
they can be accessed by miscellaneous utility programs.
Remove three or four copies of FITSint_() that were duplicated in
utility programs like dlb and tile2bmp due to those not having
access to src/hacklib.o. They do have access to src/alloc.o (and
util/panic.o).
original code:
if (linestart && (*cp & 0x80) != 0) {
g_putch(*cp);
end_glyphout();
linestart = FALSE;
} else {
(void) putchar(*cp);
}
new code:
if (linestart) {
if (SYMHANDLING(H_UTF8)) {
/* FIXME: what is actually in that line? is it the \GNNNNNNNN or UTF-8? */
g_putch(*cp);
} else if ((*cp & 0x80) != 0) {
g_putch(*cp);
end_glyphout();
}
linestart = FALSE;
} else {
(void) putchar(*cp);
}
The new code didn't output a character if linestart was true and the character did
not have bit 0x80 set.
fixed code:
if (linestart) {
if (SYMHANDLING(H_UTF8)) {
/* FIXME: what is actually in that line? is it the \GNNNNNNNN or UTF-8? */
g_putch(*cp);
} else if ((*cp & 0x80) != 0) {
g_putch(*cp);
end_glyphout();
} else {
(void) putchar(*cp);
}
linestart = FALSE;
} else {
(void) putchar(*cp);
}
The preprocessor directives in win/tty/wintty.c were crossed-up
under MSDOS build. I think I got them straightened out now.
For a crosscompile situation, the tilemap utility (which runs on
the host) needs to produce an output src/tile.c that is compatible
for the target platform.
Don't use ENHANCED_SYMBOLS under MSDOS, for now anyway.
A new feature, enabled by default to maximize testing, but one which can
be disabled by commenting it out in config.h
With this, some additional information is added to the glyphmap entries
in a new optional substructure called u with these fields:
ucolor RGB color for use with truecolor terminals/platforms.
A ucolor value of zero means "not set." The actual
rgb value of 0 has the 0x1000000 bit set.
u256coloridx 256 color index value for use with 256 color
terminals, the closest color match to ucolor.
utf8str Custom representation via utf-8 string (can be null).
There is a new symset included in the symbols file, called enhanced1.
Some initial code has been added to parse individual
OPTIONS=glyph:glyphid/R-G-B entries in the config file.
The glyphid can, in theory, either be an individual glyph (G_* glyphid)
for a single glyph, or it can be an existing symbol S_ value
(monster, object, or cmap symbol) to store the custom representation for
all the glyphs that match that symbol.
Examples:
OPTIONS=glyph:G_fountain/U+03A8/0-150-255
(Your platform/terminal font needs to be able to include/display the
character, of course.)
The NetHack core code does parsing and storing the customized
entries, and adding them to the glyphmap data structure.
Any window port can utilize the additional information in the glyphinfo
that is passed to them, once code is added to do so.
Also, consolidate some symbol-related code into symbols.c, and remove it from
files.c and options.c
When trap detection finds trapped doors and trapped chests, it shows
those as bear traps. When the hero comes within view, they revert to
normal and the detected trap is forgotten. This doesn't change that,
it is just groundwork to be able to show them distinctly. Like the
TT_BEARTRAP patch, it increments EDITLEVEL so this seemed like a good
time to put the groudwork in place.
There shouldn't be any visible changes even though internal glyph and
tile values have been renumbered after inserting two new entries.
Adding traps after S_vibrating_square was quite a hassle and suffered
though a couple of off-by-one errors that weren't trivial to find and
fix.
More context-sensitive inventory support. While examining inventory,
if you pick an item other than gold and it has a quantity of more
than 1, "I - Adjust inventory by splitting this stack" will be one
of the menu choices.
Breaking doorganize() into two parts was much easier than expected,
but the new internal command added to be an alternate for the first
part had more niggling details than anticipated.
Message history only shows the first digit with "Split off how many?"
if the player enters more than that.
For Qt with 'popup_dialog' off, if I typed "#quit" then the prompt
"Really quit?" was displayed in the message window as expected.
But if I typed "#" and then clicked on [quit], sometimes the prompt
wasn't visible even though the program was waiting for me to answer
it. I've noticed this a time or two in the past and just pretended
that it hadn't happened; since I usually enter extended commands by
typing their name, it didn't stand out much. Testing #repeat with
extended commands brought it back to mind.
I don't understand what's going on, but this one-line patch seems
to solve it. (With a multi-line message window, clear_nhwindow()
doesn't erase anything, but for Qt it does update the most recent
entry.)
Fix '#repeat' for tty; both it and ^A can repeat an extended command.
Fix both for curses; they can repeat an extended command instead of
just repeating the initial '#' to start getting an extended command.
X11 (tested), Qt (tested), and probably Windows GUI (not tested)
behave the same as before: ^A (or #repeat) after an extended command
just repeats the # to run the dialog to get an extended command.
I hope this introduces fewer bugs than it fixes but I don't think I'd
bet on that....
While testing the new mouse action menus, it was quite annoying
to try and hit some shorter entries. Make all the selectable entries
the same maximum length, and with text left justified.
menuitem_invert_test() is intended for invert-all/invert-page/
select-all/select-page but was being called for group accelerators.
In the #wizidentify menu, the 'all' choice specifies ^I as a group
accelerator but that stopped working on tty when it recently became
flagged as skip-invert.
Catch up with tty, curses, X11, and Qt: menuitem_invert_test()
applies to select as well as invert and if menuinvertmode is 2 then
it also applies to unselect.
Not tested.
Catch up with tty, curses, and X11. Items flagged as skip-invert
will not be toggled On by select-all. If menuinvertmode is 2, they
also won't be toggled Off by unselect-all.
Catch up with tty and curses. Menu items flagged as skip-invert will
not be toggled On by select-all and select-page. If menuinvertmode
is 2 they also won't be toggled Off by deselect-all and deselect-page.
Change curses' use of menuitem_invert_test() to match the recently
changed tty behavior: when menuinvertmode is 1 the test excludes
special menu items that are flagged 'skip-invert' while handling
select-all and select-page as well as invert-all and invert-page,
and when that option is 2 then it also operates on deselect-all and
deselect-page.
github issue #697 from copperwater points out that using a menu for
pickup and attempting to give a count to pickup a subset of gold was
ignoring the count and picking up all gold. That was an unintended
side-effect of making '$' be a group accelerator for gold in addition
to being the 'letter' for a stack of gold (so that it can be chosen
even when not displayed on the current page, the way other groups
behave).
Picking groups via their accelerator ignored any pending count (in
tty; curses seems to apply the count). Change tty to apply a pending
count to all menu entries that get toggled on via group accelerator.
It's intended to address the gold bug but might also be used to
select one from every potion stack via '1!', for example. (Seems to
be of very limited functionality, but that was more straightforward
than singling out gold's group to behave differently.)
While in there, change how tty uses menuitem_invert_test(): call it
for set-page/set-all/unset-page/unset-all in addition to existing
invert-page/invert-all. unset-page/unset-all won't actually be
affected unless 'menuinvertmode' option is set to 2.
Closes#697
observed: parallel build attempts of makedefs that trampled over
one another.
attempted workaround: Add a dependency as per Pat R's suggestion.
observed: Concurrent header file movement collisions were sometimes
causing file busy errors and build failures.
workaround: Eliminate tile.h header file movement from the
Makefile build so that the collisions won't occur with that
particular file. Leave the header file tile.h in win/share as it
is in the distribution and just adjust the include path in the
rule for the specific files that use it.
observed: tiletxt.c created on-the-fly from Makefile echo statements
sometimes resulted in garbled and duplicate content in it when
parallel makes were involved, and that caused a build failure.
workaround: Instead of creating a tiletxt.c on-the-fly via echo
statements in the Makefile, simplify things and use that
same #include "tilemap.c" approach but make it an actual file
in the distribution. That makes it available for other platforms
too.
Fix up the level descriptions used when logging an "entered new level"
event. Most of the change is for adding an extra argument to calls
to describe_level(). The curses portion is in a big chunk of old code
suppressed by #if 0.
I didn't notice that the level entry events are classified as LL_DEBUG
until all the work was done. This promotes the entry events for the
four Plane of <Element> levels from debug events to major ones instead.
It doesn't do that for the Astral Plane because the entered-the-Astral-
Plane achievement already produces a major event for that. Most other
key level entry events are in a similar situation--or will become that
way once another set of achievements eventually gets added--so there
aren't any other event classification promotions.
When testing the menu/incomplete map situation I noticed that <return>
didn't work to dismiss the "list autopickup exceptions" menu. <space>
or <escape> was required. That was clearly intentional but doesn't
seem reasonable. Make <return> behave the same for PICK_NONE as it
does for other menu modes in tty and as it does for other interfaces.
When a 'full-screen' (cw->offx and cw->offy both 0) menu was immediately
followed by an offset menu -- as in the case of selecting certain
options from the options menu, or using loot to take out/put in items
after using ':' to describe the contents of a very full container --
there were some odd interactions with the map.
Only certain parts of the map near/under the menu window would be
redrawn if the first offset menu was followed by another one, while
a getlin prompt would cause the entire map to be redrawn, with parts
intersecting the window being drawn on top of it and obscuring it.
Flushing the display immediately after the docrt call when closing a
full-screen menu seems to fix both these issues.
In a curses menu, if you type a digit to start a count, the cursor
jumps to the spot on the screen where the hero is. Strange and very
noticeable if that spot is covered by the menu, although I didn't
notice it when working on digits as group accelerators (changes for
that didn't trigger this).
Despite the cursor_on_u location, it isn't related to the recent
flush_screen/cursor_on_u changes either. In 3.6.x, curses used it's
own count entry code. Early on with to-be-3.7 it was changed to use
the core's get_count(), so uses a different routine to get next input
character. And the curses edition of that routine deliberately
positions the cursor at the hero's location on the assumption that
it only gets called when the map window is active.
Have curses catch up with tty, X11, and Qt: if a menu of objects has
any heavy iron balls, their entries can be toggled on or off by using
'0' as a group accelerator. That's been supported by tty and X11 for
ages and by Qt since yesterday. This also supports having any digit
as a group accelerator so that the 'O' hack to pick number_pad mode by
typing the digit that matches the value description works (except for
menu entry for mode -1; '5' happens to work for that one but doesn't
match its description).
Have Qt catch up with tty and X11: in a menu, when not already
entering a count and player types a digit, check whether it is the
group accelerator for any of the menu entries. If so, toggle their
selection state; if not, begin counting for the next item the player
eventually picks.
I don't try to toggle 'number_pad' very often, but when I do I almost
always type '0' instead of 'a' for Off or '1' instead of 'b' for On
on the first attempt. The menu shows
| a - 0 (off)
| b - 1 (on)
| c - 2 (on, MSDOS compatible)
| d - 3 (on, phone-style digit layout)
| e - 4 (on, phone-style layout, MSDOS compatible)
| f - -1 (off, 'z' to move upper-left, 'y' to zap wands)
This change makes '0' through '4' be undocumented group accelerators
for 'a' through 'e' (and '5' for 'f') in the sub-menu put up by 'O'.
tty and X11 worked as-is for '0' and required what amounts to a pair
of one-line changes to handle the other digits.
It doesn't work for curses and Qt (no idea about Windows GUI) because
they insist on treating any typed digit as the start of a count even
if one or more menu entries include that digit as a group accelerator.
(They also fail to support '0' as the group accelerator for iron-ball
class in the menu for multiple-drop.)
