new .h files: hacklib.h selvar.h stairs.h
new .c files: calendar.c, getpos.c, report.c, selvar.c, stairs.c,
strutil.c, wizcmds.c
cleanup of hacklib.c and mdlib.c
hacklib contains functions that do not have to link with the core
relocate wiz commands from cmd.c to wizcmds.c
relocate CRASHREPORT stuff to report.c
relocate getpos stuff from do_name.c to getpos.c
remove temporary struct definition from extern.h
cross-compile PRE-section split into cross-pre1.370 and cross-pre2.370
Windows sys/windows/Makefile.nmake and sys/windows/Makefile.mingw32 and
visual studio project file updates
Unix sys/unix/Makefile.src, sys/unix/Makefile.utl
populate selvar.c and selvar.h
build on MS-DOS (not cross-compile) Makefile updates
for sys/msdos/Makefile.GCC (untested)
vms updates for above (untested)
Before using this updated packaging you will need
to do the following (one time):
sh sys/msdos/fetch-cross-compiler.sh
And you'll need to update your Makefiles as follows.
On Linux:
sh sys/msdos/setup.sh sys/unix/hints/linux.370
or on macOS;
sh sys/msdos/setup.sh sys/unix/hints/macOS.370
Create the msdos package with:
make CROSS_TO_MSDOS=1 package
Define some macros in include/tradstdc.h, for compilers that support
__attribute__((nonnull)), to assist in identifying which parameters
on functions are not supposed to be null pointers.
Next, for the majority of functions declared in include/extern.h, this
adds the appropriate macro that matches the actual use of each function's
parameters. The additions were done after performing some analysis.
These were the rules that were followed when determining which function
parameters should be nonnul, and which are nullable:
1. If the first use of, or reference to, the pointer parameter in the
function is a dereference, then the parameter will be considered
nonnull.
2. If there is code in the function that tests for the pointer parameter
being null, and adjusts the code-path accordingly so that no segfault
will occur, then the parameter will not be considered nonnull (it can
be null).
The use of the nonnull attributes allows the compiler to detect code in
callers of the function where a null parameter could get passed to the function.
If a warning is received the developer will have to do one of the following:
- If the null being passed to the function is now appropriate,
and the function should be able to expect a null parameter, then the
NONNULLxxx macro will have to be removed from the function's prototype.
or
- If the null being passed to the function is not appropriate,
correct the caller so it is not passing null.
or
- If the warning is about comparing to null, it may indicate an
unnecessary null check in the code involved. If it is deemed to be
unnecessary, it can then be removed.
Some static analysis tools apparently can work with the attribute, as well.
Following this, it was discovered that some functions were using one of the
(now) nonnull parameters in the first argument to the 'is_art(obj, ART)'
macro, which is defined like so:
=> #define is_art(o,art) ((o) && (o)->oartifact == (art))
That macro expansion inline resulted in a diagnostic warning because of the
'(o)' portion of the expanded macro, anywhere the macro was used with one of
the nonnull parameters. A test against null for a 'nonnull parameter' causes
a diagnostic warning.
To work around that, I replaced the is_art() macro with a function in
artifact.c, that accomplishes the same thing as the macro.
=> boolean
is_art(struct obj *obj, int art)
{
if (obj && obj->oartifact == art)
return TRUE;
return FALSE;
}
Some documentation...
These are the macros that have been defined for use when specifying the nonnull
parameters in a function prototype:
----------------------------------------------------------------------------
| Macro | Purpose |
+----------------+---------------------------------------------------------+
| NONULL | The function return value is never NULL. |
+----------------+---------------------------------------------------------+
| NONNULLPTRS | Every pointer argument is declared nonnull. |
+----------------+---------------------------------------------------------+
| NONNULLARG1 | The 1st argument is declared nonnull. |
+----------------+---------------------------------------------------------+
| NONNULLARG2 | The 2nd argument is declared nonnull. |
+----------------+---------------------------------------------------------+
| NONNULLARG3 | The 3rd argument is declared nonnull. |
+----------------+---------------------------------------------------------+
| NONNULLARG4 | The 4th argument is declared nonnull (not used). |
+----------------+---------------------------------------------------------+
| NONNULLARG5 | The 5th argument is declared nonnull. |
+----------------+---------------------------------------------------------+
| NONNULLARG7 | The 7th argument is declared nonnull (bhit). |
+----------------+---------------------------------------------------------+
| NONNULLARG12 | The 1st and 2nd arguments are declared nonnull. |
+----------------+---------------------------------------------------------+
| NONNULLARG13 | The 1st and 3rd arguments are declared nonnull. |
+----------------+---------------------------------------------------------+
| NONNULLARG123 | The 1st, 2nd and 3rd arguments are declared nonnull. |
+----------------+---------------------------------------------------------+
| NONNULLARG14 | The 1st and 4th arguments are declared nonnull. |
+----------------+---------------------------------------------------------+
| NONNULLARG134 | The 1st, 3rd and 4th arguments are declared nonnull. |
+----------------+---------------------------------------------------------+
| NONNULLARG17 | The 1st and 7th arguments are declared nonnull (this |
| | was a special-case added for askchain(), where the |
| | arguments are spread out that way. This macro |
| | could be removed if the askchain arguments in the |
| | prototype and callers were changed to make the |
| | nonnull arguments side-by-side). |
+----------------+---------------------------------------------------------+
| NONNULLARG145 | The 1st, 4th and 5th arguments are declared nonnull |
| | (this was a special-case added for find_roll_to_hit(), |
| | in uhitm.c, where the arguments are spread out that way.|
| | We can't just use NONNULLPTRS there because the 3rd |
| | argument 'weapon' can be NULL). |
+----------------+---------------------------------------------------------+
| NONNULLARG24 | The 2nd and 4th arguments are declared nonnull (this |
| | was a special-case added for query_objlist() |
| | in invent.c). |
+----------------+---------------------------------------------------------+
| NONNULLARG45 | The 4th and 5th arguments are declared nonnull (this |
| | was a special-case added for do_screen_description(), |
| | in pager.c, where the arguments are spread out that |
| | way. We can't just use NONNULLPTRS there because the |
| | 6th argument can be NULL). |
+----------------+---------------------------------------------------------+
| NO_NONNULLS | This macro expands to nothing. It is just used to |
| | mark that analysis has been done on the function, |
| | and concluded that none of the arguments could be |
| | marked nonnull.That distinguishes a function that has |
| | not been analyzed (yet), from one that has. |
+----------------+---------------------------------------------------------+
The NO_NONNULLS macro is meant to place a flag on the prototype to
make people aware that an assessed function was determined to not
be eligible for nonnull parameters. It expands to nothing.
Unfortunately, that macro was added partway through this exercise, so there
aren't many instances of it in the upper parts of include/extern.h, even though
the functions there were likely assessed and categorized as not having any
eligible nonnull parameters. It just never got any macro at all, in that case.
Following the parameter usage analysis that was done, the following was
noted:
Some NetHack functions have added a test to catch a passed null
parameter, and exit the function early as a result, or call
impossible(), and then exit. While that approach prevents segfaults
from dereferencing a null parameter, the early return is silent
(when impossible is not called anyway), and the function's true
purpose is not fulfilled. Also, the calling function may have no
awareness that the function did not complete its intended purpose,
in many instances.
Functions with such a test and early return, cannot have the parameter
declared 'nonnull', because the code to test for 'null' will cause a
diagnostic to be issued if the parameter is nonnull.
It might be good to revisit some of those functions and consider,
on a case by case basis, declaring the parameter nonnull in the
prototype, and the test/code-path commented out.
Allow 'make USE_MANDOC=1 distrib' to be used for generating
the doc/*.txt files for systems that have mandoc and may not have groff.
(macOS Ventura doesn't include groff in the OS).
USE_MANDOC=1 is not restricted only to macOS.
Have hints/macOS.370 specify the /usr/share/man/man6 directory for the macOS
man pages, so that 'make manpages' will target the correct directory on
that platform.
Some changes to achieve the following MAN2TXT commands...
If groff version is 1.23 or greater:
nroff -man -Tascii -P -cbou
If groff version is less than 1.23:
nroff -man -Tascii -c | col -b
If non-groff nroff:
nroff -man | col -b
Closes#1153 again.
Following a commit for Issue #1153, g-branden-robinson commented:
> Mac OS X stayed on _groff_ 1.19.2 for over a decade (presumably due to
> _groff_ 1.20 adopting to GNU GPLv3), until finally dropping _groff_
> altogether for macOS Ventura (2022).
>
> There _has_ been an interface change in that time. The [`-P` option I
> advised about is new to _groff_ 1.23.0 (July 2023)]
> (https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n86).
> [...]
>
> There is a significant number of _groff_ users via Homebrew (enough that
> we hear from them occasionally via bug reports). Some of these have
> upgraded to 1.23.0 via that mechanism.
> [...]
>
> `nroff -` is not necessary with any _nroff_ known to me; like many other
> Bell Labs Unix programs, it reads from the standard input stream by default
> if not given any operands.
Action taken:
1. Remove the unnecessary ' -' from the nroff command in Makefile.doc.
2. In the misc.370 file containing make snippets to include, test whether
groff >= 1.23, and only insert the -P option for 1.23 or greater.
rename hints/include/multiw-3.370 to hints/include/misc.370
keep the portable nroff options in sys/unix/Makefile.doc,
and relocate the non-portable bits to a variable defined
in sys/unix/hints/include/misc.370
This assumes that the groff options are compatible between
Linux and macOS implementations of groff.
If that turns out not to be the case, this bit:
ifneq "$(NROFFISGROFF)" "" # It's groff
# add the groff-specific plain text flags
MORE_MAN2TXT_FLAGS += -Tascii -P -cbou
endif
should relocate from sys/unix/hints/include/misc.370
to sys/unix/hints/linux.370 and sys/unix/hints/macOS.370,
immediately following the inclusion of misc.370, and the
appropriate platform-specific groff options can be
adjused in whichever of those appropriately needs it.
Closes#1153
../lib/pdcursesmod/dos/../common/dosutil.c:36:15: warning: comparison of integer expressions of different signedness: 'long int' and 'long unsigned int' [-Wsign-compare]
36 | while( ms > MAX_NAP_SPAN)
| ^
It isn't something that we can actually resolve within NetHack,
so just suppress the submodule build warning.
This commit will trigger the CI to carry out a test of the build.
There could be some follow-up after the results.
String definitions were being used with a pointless leading double
quote. This syntax is used only to define strings containing leading
space characters. (You might also use it defensively if you're defining
one string whose contents start with the interpolation of another, and
the latter might interpolate leading space--but that is not the case
here.)
Remove unnecessary leading quotes from string definitions.
* doc/Guidebook.mn: Do it. Also annotate empty strings with comment.
* sys/unix/hints/include/gbdates-post.370: Don't put them back.
https://www.gnu.org/software/groff/manual/groff.html.node/Strings.html
The curses interface was using genl_putmixed() which doesn't
preserve the symbol actually used for a glyph on the display.
This is a first-attempt at implementing curses_putmixed().
On Linux you'll need to distribute the Makefiles again
sh sys/unix/setup.sh sys/unix/hints/linux.370
On macOS, you'll need to distribute the Makefiles again
sh sys/unix/setup.sh sys/unix/hints/macOS.370
A bunch of new warnings appeared by default on macOS compiler provided with Xcode,
including on every usage of sprintf(). Suppress those for now.
The issues with utilizing WANT_ASAN=1 on the make command line with macOS seem
to be resolved in this latest version, so allow it to be specified. Don't specify
it if using a problematic clang version.
When the address sanitizer is in use for gcc, clang, or visual studio,
(-fsanitize=address) define the NetHack preprocessor symbol USING_ADDRESS_SANITIZER.
In addition to C99=1 on the make command line, also allow
C89=1 or C11=1 or C23=1.
NOTE: Those won't all lead to a successful build of NetHack,
and the use of C23=1 (-std=c2x) will only be valid on recent
compiler versions (clang-15, for one, accepts it).
CSTD can be manually set near the top of src/Makefile, util/Makefile
or by including c99=1 or C99=1 on the build make command line if
using the linux.370 or macOS.370 hints files.
sound_verbal(char *text, int32_t gender, int32_t tone, int32_t vol,
int32_t moreinfo);
-- NetHack will call this function when it wants to pass text of
spoken language by a character or creature within the game.
-- text is a transcript of what has been spoken.
-- gender indicates MALE or FEMALE sounding voice.
-- tone indicates the tone of the voice.
-- vol is the volume (1% - 100%) for the sound.
-- moreinfo is used to provide additional information to the soundlib.
-- there may be some accessibility uses for this function.
It may be useful for accessibility purposes too.
A preliminary implementation has been attempted for macsound to test
the interface on macOS. No tinkering of the voices has been done.
Use of the test implementation requires the following at build time with make.
WANT_SPEECH=1
That needs to be included on the make command line to enable the test code,
otherwise just the interface update is compiled in.
I don't know for certain when AVSpeechSynthesizer went into macOS, but older versions
likely don't support it, and would just leave off the WANT_SPEECH=1.
If built with WANT_SPEECH=1, the 'voices' NetHack option needs to be enabled.
It was a bit strange, when I first started up the test, to hear Asidonhopo,
the shopkeeper, talking to me as I entered his shop and interacted with him.
Start to add supporting code to windsound and macsound. The latter
remains commented out because I haven't had a chance to try
it on macOS yet.
In order to test it out, I added two more stock sounds:
sa2_xplevelup and sa2_xpleveldown.
Move pieces of the Makefile hints sound-related changes that
are not macOS-specific from sys/unix/hints/macOS.370 to some new
include files. The WANT_MACSOUND block stays in
sys/unix/hints/macOS.370 because it is system-specific.
Before this change, the various Makefiles were assembled via
hints files macOS.370 or linux.370. Both were using included
portions from the following files in the sys/unix/hints/include
directory, in this sequence:
-INCLUDE multiw-1.370
-INCLUDE multiw-2.370
-INCLUDE compiler.370
-INCLUDE multiw-3.370
-INCLUDE cross-pre.370
-INCLUDE gbdates-pre.370
-INCLUDE gbdates-post.370
-INCLUDE cross-post.370
After this change, the various Makefiles will still be assembled
via hints files macOS.370 or linux.370. They will continue to use
included portions from the following files in the
sys/unix/hints/include directory, but with three additional
include files related to sound and soundlibs. This is the new
sequence:
-INCLUDE multiw-1.370
-INCLUDE multiw-2.370
-INCLUDE compiler.370
-INCLUDE multiw-3.370
+ -INCLUDE multisnd1-pre.370
-INCLUDE cross-pre.370
-INCLUDE gbdates-pre.370
+ -INCLUDE multisnd2-pre.370
-INCLUDE gbdates-post.370
+ -INCLUDE multisnd-post.370
-INCLUDE cross-post.370
The include mechanism continues to allow common portions that can
be shared between macOS and Linux to be maintained in a single
place only, with minimal duplication. Now, that has been extended
to include Makefile lines related to sounds and soundlib.
Use macOS AppKit framework routines for a first cut at a
macsound soundlib interface.
Requires WANT_MACSOUND=1 on build.
Nothing has been done to move the stock sounds into the resources
of a bundle, so after building, if you want to try the stock sounds
out:
cp sound/wav/*.wav ~/Library/Sounds
Because the NSSound macOS routines always do the search, supposedly
the following locations are searched in this order:
1. the application’s main bundle
2. ~/Library/Sounds
3. /Library/Sounds
4. /Network/Library/Sounds
5. /System/Library/Sounds
Although not specifically implemented as of yet, it may be pretty
close to being able to put soundeffects wav files (by se_ name)
into ~/Library/Sounds working for the SND_SOUNDEFFECTS_AUTOMAP feature.
Feedback is welcome. Contributions for improving it are even more
welcome.
The new soundlib supporting file is named
sound/macsound/macsound.m since it's got objective C in it.
Known bugs and glitches:
The Hero_playnotes on a set of 5 notes goes too fast, so there
needs to be a slight delay added between the note of a multi-note
play.
Groundwork for a more versatile interface for using
sound libraries. A lot of sound libraries work across
multiple platforms.
The current NetHack sound stuff is quite limited.
Binaries can have a variety of window ports linked into
them, and it makes sense to have something similar for
sound.
This tries to set things up in a more soundlib-centric way,
rather than inserting things in a platform-centric way.
It establishes a new top-level directory sound (akin to win
for the window interface routines, or "window-port") where
sound-related additions and sndprocs and support files can be
added and used across platforms.
The default interface is nosound and the 'nosound' interface
is in src/sounds.c
The interface for 'windsound', which contains the same minimal
USER_SOUNDS support using built-in routines that has been in the
windows port for a long time is added to
sound/windsound/windsound.c.
For now, the sound interface support for 'qtsound' has been added
to the existing Qt files win/Qt/qt_bind.h and win/Qt/qt_bind.cpp,
and a note has been placed in sound/qtsound/README.md to avoid
confusion.
New header file added: include/sndprocs.h.
Also includes support by paxed for polearm targeting using the
frame color.
Also renames USE_TILES to TILES_IN_GLYPHMAP which is a more
accurate description.
Not all window interfaces have full support for the color framing
of the background square yet.
MS-DOS needs further work (to bring it to both VESA and VGA, with
and without tiles.
Windows GUI is missing support.
X11 and Qt have been started, but may require further refinement.
