../sys/msdos/font.c:24:12: warning: declaration of 'flags' shadows a global declaration [-Wshadow]
24 | uint32 flags;
| ^~~~~
In file included from ../include/hack.h:285,
from ../sys/msdos/font.c:3:
../include/flag.h:422:29: note: shadowed declaration is here
422 | extern NEARDATA struct flag flags;
| ^~~~~
make[2]: Entering directory '/home/nhmall/git/NHsource/util'
src/mkroom.c(1068) :
warning C4701: potentially uninitialized local variable 'insidex' used
src/mkroom.c(1070) :
warning C4701: potentially uninitialized local variable 'insidey' used
The warning is because the insidex and insidey variables only get
assigned a value conditionally within a for-loop, but contain random
values if that for-loop is not executed, and they are used unconditionaly
later on in the code.
Initializing them changes that from containing random values to containing
zeros, whether that is appropriate or not.
In this particular case, insidex and insidey look to be riding on the coat
tails of insidect and there is a check for invalid insidect in the code,
so that should catch the situation.
../win/curses/cursmain.c: In function 'curses_init_nhwindows':
../win/curses/cursmain.c:157:17: warning: unused variable 'pdc_font' [-Wunused-variable]
157 | static char pdc_font[BUFSZ] = "";
| ^~~~~~~~
../win/curses/cursmain.c: At top level:
../win/curses/cursmain.c:157:17: warning: 'pdc_font' defined but not used [-Wunused-variable]
An Xcode update has started causing the same problem that was experienced on
Linux with newer compiler or glibc a while back.
˜
In file included from monst.c:6:
In file included from ../include/config.h:670:
In file included from ../include/integer.h:54:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/include/stdint.h:52:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdint.h:52:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:32:
/Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:302:39: error: too few arguments provided to function-like macro invocation
^
1 error generated.
make[1]: *** [monst.o] Error 1
Please enter the commit message for your changes. Lines starting
warning: for tile 250 (numbered 250) of objects.txt,
found 'huge chunk of meat' while expecting 'enormous meatball'
../win/share/objects.txt: 460 tiles
options.c: In function ‘option_help’:
options.c:8820:55: warning: ‘%s’ directive writing up to 255 bytes into a region of size 220 [-Wformat-overflow=]
8820 | Sprintf(buf, "Set options as OPTIONS=<options> in %s", configfile);
| ^~ ~~~~~~~~~~
make pmatchregex regex_error_desc return type match cppregex.cpp and
posixregex.c
make the extern declaration for loadsyms[] in options.c match the
one in symbols.c.
The pull request included some changes that were neither accidental nor
unintentional, so only a subset of the changes from pull request #869
submitted by klorpa were manually applied.
behaviour -> behavior
speach -> speech
knowlege -> knowledge
incrments -> increments
stethscope -> stethoscope
staiway -> stairway
arifact -> artifact
extracing -> extracting
The uses of "iff" were left alone.
Close#869
Some static analyzers flagged the last-resort values as
out of bounds (which they were).
There's a small number of other complaint-suppression items in here too,
but nothing drastic.
Some discrepencies between glyph_is_cmap and glyph_to_cmap
arose after b14b830b because the change resulted in
glyph_is_cmap matching on zap beams which weren't accounted
for in the glyph_to_cmap macro. It is unlikely that
glyph_to_cmap will ever be used on such a glyph, but at least
have glyph_to_cmap return a sane value rather than drop through
to the last-resort value (currently NO_GLYPH) which is far
outside the range of the defsyms[] array indices.
I think some of these discrepencies between glyph_is_cmap and
glyph_to_cmap started after b14b830b because the additional
ranges added by that didn't have a corresponding return in
glyph_to_cmap.
invent.c: In function 'getobj':
invent.c:1579:29: warning: 'cnt' may be used uninitialized [-Wmaybe-uninitialized]
1579 | if (cnt < 1 || otmp->quan <= cnt)
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~
invent.c:1529:10: note: 'cnt' was declared here
1529 | long cnt;
| ^~~
../win/X11/winstat.c: In function 'update_fancy_status_field':
../win/X11/winstat.c:1920:28: warning: declaration of 'active' shadows a global declaration [-Wshadow]
1920 | static boolean active = FALSE;
| ^~~~~~
In file included from ../include/hack.h:196,
from ../win/X11/winstat.c:36:
../include/wintype.h:180:5: note: shadowed declaration is here
180 | active = 0x001,
| ^~~~~~
Change the inner workings of the experimental TTY_PERM_INVENT.
Switch to delivering the content to tty for the experimental perm_invent
via the existing window port interface (start_menu(), add_menu(), end_menu).
This also adds a new window port interface call ctrl_nhwindow() for
delivering information to the window port, and/or obtaining specific
information from the window port. The information and requests can
be extended as required. To be documented later once the changes settle
down.
Due to the intrusive nature of these changes and the possibility of
some bugs in the new code, I'm going to leave TTY_PERM_INVENT commented
out in the repository for a day or two. Anyone wishing to test it out
can do so by uncommenting TTY_PERM_INVENT in config.h.
One of the drivers of this change was that screen coordinates require a
type that can hold values greater than 127. Parameters to the window
port routines require a large type in order to be able to have values
a fair bit larger than COLNO and ROWNO passed to them, particularly for
their use to the right of the map window.
This splits the uses of xchar into 3 different situations, and adjusts
their type and size:
xchar
|
-----------------------
| | |
coordxy xint16 xint8
coordxy: Actual x or y coordinates for various things (moved to 16-bits).
xint16: Same data size as coordxy, but for non-coordinate use (16-bits).
xint8: There are only a few use cases initially, where it was very
plain to see that the variable could remain as 8-bits, rather
than be bumped to 16-bits. There are probably more such cases
that could be changed after additional review.
Note: This first changed all xchar variables to coordxy. Some were
reviewed and got changed to xint16 or xint8 when it became apparent that
their usage was not for coordinates.
This increments EDITLEVEL in patchlevel.h
nhmall