role.c: In function 'plnamesuffix':
role.c:1615:19: warning: operand of '?:' changes signedness from 'int' to 'unsigned int'
due to unsignedness of other operand [-Wsign-compare]
1615 | ? (int) (eptr - gp.plname)
^~~~~~~~~~~~~~~~~~~~~~~~
Since Strlen() (actually hacklib's Strlen_ function) returns 'unsigned' for the
second operand of the '?:', the compiler was having to change the signedness
of the first operand '(int) (eptr - gp.plname)' to 'unsigned' and issuing the
warning.
Cast the result of Strlen() to int to make both operands of the '?:' the same
('signed').
The unlink call wasn't operating the same on a makedefs built
on mingw, and dat/mdXXXX files were being left behind post-build.
Provide an alternative way of doing the temporary files if
MD_USE_TMPFILE_S is defined during the compile of makedefs.c
bkglyph variable gets initialized to GLYPH_UNEXPLORED so ends
up being returned by get_bk_glyph() if something more interesting
wasn't chosen in the switch statement.
The Windows win32 interface will then use the tile mapped to
GLYPH_UNEXPLORED as a background. The tile is 16x16 all black
pixels. That looked very odd.
Treat GLYPH_UNEXPLORED as an out-of-range value.
Closes#929
If you were on a level teleporter, the spoteffects() call after
the hero gets expelled could end up going to a new level and
freeing all the monst chains from the level you were originally
engulfed on.
#0 0xba0507 in free
#1 0x87feda in dealloc_monst src/mon.c:2369
#2 0x880a02 in dmonsfree src/mon.c:2194
#3 0x9a7aa2 in savelev_core src/save.c:507
#4 0x9a7a21 in savelev src/save.c:466
#5 0x71eb9d in goto_level src/do.c:1483
#6 0x71833f in deferred_goto src/do.c:1903
#7 0xa2533f in level_tele src/teleport.c:1117
#8 0xa2567b in level_tele_trap src/teleport.c:1198
#9 0xa5c007 in trapeffect_level_telep src/trap.c:1861
#10 0xa5f856 in trapeffect_selector src/trap.c:2497
#11 0xa47497 in dotrap src/trap.c:2586
#12 0x7d669b in spoteffects src/hack.c:2859
#13 0x89d495 in xkilled src/mon.c:3187
The latter parts of xkilled() after the spoteffects() call would
then attempt to dereference the free'd monst pointer.
Save a copy of the monst struct prior to spoteffects() if you were
expelled, then point at the reference copy afterwards.
Resolves#938
The consolidation of global variables from scattered source
files into decl.c and declared in decl.h was begun in 3.7.0.
Their placement in common files was done for centralized
initialization and potential re-initialization during a
"play again" scenario.
It wasn't really necessary for all of them to be housed in a
single huge structure to meet the "play again" requirement,
and the single huge structure has been a little unwieldy when
it comes to maintenance.
Following this commit, instead of one single extremely large structure
named 'g' to house all of the relocated global variables, they
are distributed into several ga through gz.
To make things easy for the developer, each variable is placed
into the struct corresponding to the starting letter of the variable.
That way, no lookup is required in order to know which struct houses
a particular variable, it is a simple match to the starting letter
for all the centralized global variables.
A global variable named 'amulets', would be found in ga.
ga.amulets
^ ^
A global varable named 'move', would be found in gm.
gm.moves
^ ^
A global variable named 'val_for_n_or_more' would be found in gv.
gv.val_for_n_or_more
^ ^
A global variable named 'youmonst' would be found in gy.
gy.youmonst
^ ^
Although gcc specifies support for declaring a function as
noreturn after the function name and parameters, other compilers
do so via an attribute at the start of the declaration. Add some
macro support for the attribute-at-the-beginning method:
o MS Visual Studio compiler
o Upcoming C23 standard (untested at this point)
../win/curses/cursinit.c:102:9: warning: variable 'min_message_height' set but not used [-Wunused-but-set-variable]
int min_message_height = 1;
^
1 warning generated.
When dist2() got changed to use coordxy parameters, a macro that uses
it in its definition was overlooked and it had (int) casts in it.
That caused a warning about possible data loss when the int
then got converted to coordxy for the dist2() call.
Give online2() coordxy parameters instead of int, like its bretheren.
Avoid a couple of implicit conversion warnings where ints were being assigned
to smaller uchar or ints being assigned to smaller short.
A couple of signed vs unsigned warnings on some rumor processing.
Avoid some signed vs unsigned warnings in mdlib/makedefs where a signed int
param eventually got used in an external call that took size_t.
Eliminate all of it by just having the outer NetHack routine also take
a size_t.
Lastly, insert some default C99 alternative time-related code
in mdlib/makedefs since asctime() and ctime() are being flagged as
deprecated in the upcoming C23 standard and will now start to trigger
warnings for anyone using a C23-compliant compiler.
1. remove all window interface bits from compiler.370, and have
the preceding include files set some variables to control
the behavior of compiler.370 when it comes to c++.
2. some more common Makefile lines into sys/unix/hints/include/multiw-3.370.
3. make it so you can pass cppregex=1 on the Make command line to build with
sys/share/cppregex.cpp instead of posixregex.c
4. fix sys/share/cppregex.cpp so that it will build with clang compiler
(required an additional header include). I don't know if it would have
worked with g++ without that change. The include can be placed into an #ifdef
block if there's an issue with the change on other compilers.
5. Anything that needs to compile using c++ (Qt, sys/share/cppregex.cpp) can
just ensure that CPLUSPLUS_NEEDED Makefile variable is set above the lines
in compiler.370 to ensure that things get set up for c++. It no longer
checks specifically for Qt. That is what sys/unix/hints/include/multiw-2.370
does now.
Add a 3rd multi-window include file that comes after compiler.370.
Relocate a small section of Makefile lines common to both macOS.370
and linux.370 to multiw-3.370.
Also relocate a section near the tail of compiler.370 that really
has nothing to do with compilers or compiler flags, but was
related to Qt which is one of the supported multi-window interfaces.
As far as I know, there's no such thing as WIN32_GRAPHICS in the
current source tree. The Windows graphical port uses the preprocessor
macro MSWIN_GRAPHICS.
Some recent testing with a multi-platform compiler encountered difficulty
with the use of a variable 'near' (and presumably 'far', but we don't have
any of those in the source tree) due to reserved word extensions.
Avoid using that as a variable name.
..\src\allmain.c(1061): warning C4221: nonstandard extension used: 'ed': cannot be initialized using address of automatic variable 'omdump'
..\src\allmain.c(1056): note: see declaration of 'omdump'
Resolves#916
Instead of using index() macro defined to strchr, use C99 strchr.
Instead of using rindex() macro defined to strrchr, use C99 strrchr.
If you want to try building on a platform that doesn't offer those
two functions, these are available:
define NOT_C99 /* to make some non-C99 code available */
define NEED_INDEX /* to define a macro for index() */
define NEED_RINDX /* to define a macro for rindex() */
mhitm.c: In function 'hitmm':
mhitm.c:583:30: warning: '%s' directive writing between 8 and 9 bytes into a region of size between 0 and 255 [-Wformat-overflow=]
583 | Sprintf(buf, "%s %s", magr_name,
| ^~
In file included from ../include/config.h:671,
from ../include/hack.h:10,
from mhitm.c:6:
../include/global.h:279:24: note: 'sprintf' output between 10 and 266 bytes into a destination of size 256
279 | #define Sprintf (void) sprintf
mhitm.c:583:13: note: in expansion of macro 'Sprintf'
583 | Sprintf(buf, "%s %s", magr_name,
| ^~~~~~~
nhmall