'unsigned long' isn't big enough to hold a pointer in my configuration,
and the old "only micros are sure to support %p format" is long out of
date. Just assume that everyone has %p these days, and provide a hook
to avoid it for anyone who doesn't. (Opt-out instead of opt-in.)
Define a macro NH_C to provide a shorter & simpler way to test for
which C standard the build is being carried out under (c99 or c23).
NH_C > 202300L Being compiled under C23 or greater
NH_C > 199900L Being compiled under C99 or greater
NH_C > 198900L Being compiled under C89 or greater,
or C std could not be determined.
While NetHack only requires c99, we've been taking advantage
of some c23 features (attributes), if they are available,
to allow the use of ATTRNORETURN/NORETURN and FALLTHROUGH on
compilers other than gcc.
Also add some comment documentation to tradstdc.h about NetHack's
use of c99.
The sys/unix/Makefile.top change overcomes a warning in the
Makefile-generated nhlua.h. That warning arises under some compilers
that rely on attribute [[noreturn]] ahead of a declaration
(NetHack macro ATTRNORETURN), rather than the trailing gcc
__attribute((noreturn)) (NetHack macro NORETURN). The sed command
is modified to include ATTRNORETURN at the start of the declaration
in addition to the NORETURN at the end of the declaration, in the
generated file. That's the same combination that's used for the
declaration of other functions that don't return.
gcc has recognized various "magic comments" for white-listing
occurrences of implicit fallthrough in switch statements for
a long time:
The range and shape of "falls through" comments accepted are
contingent upon the level of the warning. (The default level is =3.)
-Wimplicit-fallthrough=0 disables the warning altogether.
-Wimplicit-fallthrough=1 treats any kind of comment as a "falls through" comment.
-Wimplicit-fallthrough=2 essentially accepts any comment that contains something
that matches (case insensitively) "falls?[ \t-]*thr(ough|u)" regular expression.
-Wimplicit-fallthrough=3 case sensitively matches a wide range of regular
expressions, listed in the GCC manual. E.g., all of these are accepted:
/* Falls through. */
/* fall-thru */
/* Else falls through. */
/* FALLTHRU */
/* ... falls through ... */
etc.
-Wimplicit-fallthrough=4 also, case sensitively matches a range of regular
expressions but is much more strict than level =3.
-Wimplicit-fallthrough=5 doesn't recognize any comments.
Plenty of other compilers did not recognize the gcc comment convention,
and up until now the compiler warning for detecting unintended
fallthrough had to be suppressed on other compilers. That's because the code
in NetHack has been relying on the gcc approach, and only the gcc approach.
The C23 standard introduces an attribute [[fallthrough]] for the
functionality, when implicit fallthrough warnings have been enabled.
Several popular compilers already support that, or a very similar attribute
style approach, today, even ahead of their C23 support:
C compiler whitelist approach
--------------------------- -------------------------------------
C23 conforming compilers [[fallthrough]]
clang versions supporting
standards prior to
C23 __attribute__((__fallthrough__))
Microsoft Visual Studio
since VS 2022 17.4.
The warning C5262 controls
whether the implict
fallthrough is detected and
warned about with
/std:clatest. [[fallthrough]]
This adds support to NetHack for the attribute approach by inserting a
macro FALLTHROUGH to the existing cases that require white-listing, so
other compilers can analyze things too.
The definition of the FALLTHROUGH macro is controlled in include/tradstdc.h.
The gcc comment approach has also been left in place at this time.
Yesterday I said that I'd done all of pager.c and part of objnam.c,
but I was talking about the prototypes in extern.h. This does more
of the same, this time for the local prototypes in pager.c so "all of
pager.c" should be accurate now.
For now, this will prevent the NONNULLxxx arguments from being
defined under a djgpp compiler or crosscompiler.
paxed reported a segfault under msdos:
nethack.exe
Exiting due to signal SIGSEGV
Page fault at eip=000c3f8c, error=0004
eax=00000000 ebx=00000000 ecx=00000000 edx=0000000f esi=00000000 edi=00000001
ebp=00589988 esp=00589970 program=C:\NH370\NETHACK.EXE
cs: sel=00a7 base=00400000 limit=0063ffff
ds: sel=00af base=00400000 limit=0063ffff
es: sel=00af base=00400000 limit=0063ffff
fs: sel=008f base=00001a20 limit=0000ffff
gs: sel=00bf base=00000000 limit=0010ffff
ss: sel=00af base=00400000 limit=0063ffff
App stack: [00589ba8..00389ba8] Exceptn stack: [00389af4..00387bb4]
Call frame traceback EIPs:
0x000c3f8c _read_config_file+19
0x0017619f _initoptions_finish+577
0x00176371 _initoptions+157
0x0025cec4 _pcmain+365
0x0025d8d9 _main+41
He was able to 'git bisect' to the macro definitions change,
and confirmed that the segfault no longer occurs after this commit.
There may be further investigation on this later.
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.
We received a report from someone whose build was failing because
of the use of cchar_t and setcchar(). They were getting errors
even though they were using an up-to-date curses library.
Apparently, ncurses requires that _XOPEN_SOURCE_EXTENDED must be
defined before the curses header files in order for those features
to be available.
We had already updated our .370 series of hints and hints/include
files with
-D_XOPEN_SOURCE_EXTENDED=1
but this person must have been building in some other way.
Instead of failing to build in that situation, allow the
fallback to the older, less-functional genl_putmixed() function,
but also try not to do so silently and display a message that
functionality is reduced.
The difference between the use of genl_putmixed() and
curses_putmixed() or tty_putmixed(), is that when doing
'/' farlook operations, curses_putmixed() and tty_putmixed() try to
display a character in the message window that looks exactly the same
as the one on the map, even if a symbol from a symset is being used
on the map, or when using ENHANCED_SYMBOLS.
Related note: curses_putmixed() matches the symbol and the color,
whereas tty_putmixed() (at present) does not attempt to match the
color.
The pull request from argrath would have moved the definition of
VDECL from tradstdc.h to vmsconf.h because some out of date references
to it in sys/vms/*.c were the only place it still appeared to be used.
Instead of applying that, remove those old references.
NetHack 3.7.x requires C99 so just remove VDECL since it was present
in order to support pre-ANSI compilers. (There is at least one
comment that still mentions it though.)
This also gets rid of another chunk of tradstdc.h that was allowing
either pre-ANSI or nearly-ANSI compilers to deal with nethack's old
code. I left the USE_STDARG/USE_VARARGS/USE_OLDARGS stuff in place
even though anything supporting C99 shouldn't need that. Some or
all of the [UN]WIDENED_PROTOTYPES stuff is still there too.
Closes#1030
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)
GCCs older than 3.1 understand __attribute__(printf(...)), but only
with functions; it doesn't work with function pointers. This change
uses PRINTF_F_PTR to remove the attribute from two function pointers.
This change establishes GCC 3.0 as the minimum version to build
NetHack. Older versions have trouble with the variadic macros and
variable declarations in mid-block.
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
Refine commit 4885653014.
> I'm not sure whether gcc 3 is really the right test for whether the
> returns_nonnull attribute setting is available.
The gcc.gnu.org website only goes back to 5.1, and searching the
documentation of that version for returns_nonnull finds it. I used
ftp to get gcc-core-3.0.0 and gcc-core-4.0.0 and their doc files don't
mention this attribute. It might have been added for some later 4.x
but that really doesn't matter for nethack's purposes.
Use __GNUC__ >= 5 instead of __GNUC__ >= 3 when testing whether
__attribute__(returns_nonnull) is available.
Mark alloc()--also dupstr() and re_alloc()--for gcc and clang as
always returning non-Null. This should silence some of the static
analysis complaints.
Almost all the monster and object naming functions (anything that
returns an mbuf or an obuf) should be marked this way too but I'll
leave that for somebody else to deal with.
I didn't attempt to mark alloc() with the 'malloc' attribute because
macro definitions could end up causing trouble. Specifying its
deallocator would probably be useful but is at even bigger risk of
macro interference.
I'm not sure whether gcc 3 is really the right test for whether the
returns_nonnull attribute setting is available.
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
NetHack was trying to suppress warn_unused_result
in include/tradstdc.h, by defining warn_unused_result
to an empty string. That began causing a build error
in a system-supplied header file cdefs.h
when using 20.10 ubuntu impish.
Try skipping that in tradstdc.h for any linux, unless
the NetHack build defines GCC_URWARN to force it into
play.
Redo the UCHAR_P handling from df84da3ec2
(5 weeks ago) and 02b21865fd followup.
The earlier #define was happening too late in the #include sequence;
tradstdc.h is processed before global.h+(vmsconf.h,unixconf.h,...).
Also, DEC C in 'common' mode complains about indented '#' starting a
line but not in column 1. Putting #pragma in column 2 was deliberate
in case of an ancient compiler which doesn't understand that directive.
Splitting the difference via non-indented '# pragma' may or may not
mollify the latter when it's bypassing conditionally excluded code.
Suppress Isaac64 on VAX were there isn't an easy way to do 64-bit
arithmetic. (Hard way isn't worth it for just an alternate RNG.)
Eliminate or suppress some diagnostics:
1) In strict ANSI mode, DEC C was reporting that '$' in identifier is
an extension (one time for each file in sys/vms/*.c). (It doesn't do
that for the default 'relaxed ANSI' mode.)
2) DEC C uses WIDENED_PROTOTYPES but widens uchar (unsigned char)
differently depending upon the mode it is operating in. (Applies to
Unix as well as VMS; based on documentation rather than testing.)
Update the comment in tradstdc.h about WIDENED vs UNWIDENED_PROTOTYPES.
An old comment in config1.h about a problem with the earliest version
of DEC C was probably based on an incorrect assumption of what was
really going, but I have no way to go back in time to verify that....
The Unix Makefile.{src,utl} use the compiler name 'gcc' by default on
OSX, and that invokes clang which defines __GNUC__ to deal with gcc
extensions. But when invoked via the Xcode IDE, it evidently uses its
own name instead, and wasn't defining __GNUC__. tradstdc.h started
down the road of duplicating gcc features; switch to pretending to be
gcc instead.
Casting to (void) to discard a function return value doesn't satisfy
gcc's -Wunused-result (which we aren't enabling but is apparently
being activated for particular functions by glibc header files). Turn
it into a no-op to suppress three dozen warnings from Travis builds.
Fix lev_comp's variable argument usage by changing it to make
add_opvars() expect an int rather than a long when given the "i"
indicator, and add "l" for really passing a long. The ints are
conveted to longs when setting up the interpreter. I think I changed
just about all the integer opvars to int, although there is one use
of "l" in lev_main.c just to make sure it works. There could be
arguments that really do need to be 'long'; if so, the add_opvars()
calls for them will have to have its indicator string updated and
possibly add or remove some casts.
There's a lot of reformatting included but it's not consistent about
tab replacement. Some of the changes are due to renaming long-named
'variable_definitions' to 'vardefs' to shorten a bunch of lines.
Updated sys/share/*_yacc.c will be checked in separately. The ones
currently in the repository won't work with patched lev_main.c due to
that renamed variable.
Files modified:
include/tradstdc.h, sp_lev.h, system.h
util/lev_main.c
Silence a bunch of warnings generated by recent gcc which weren't there
with whatever version I had when 3.6.0 was being readied for release.
For lev_main, there were two basic types: not enough arguments in calls
to lc_pline, lc_warning, and lc_error (since we weren't passing dummy
arguments as is done for add_opvars), and conversion from 'int' or
narrower to 'char *' (from -Wint-to-pointer-cast, which either wasn't
there yet in the older gcc, or wasn't included in -Wall back then).
[Note that for any configuration decrepit enough to actually need
USE_OLDARGS, such conversions will either work fine or else nethack
simply won't be viable.]
src/pline.c generates a bunch of warnings (for USE_OLDARGS). The fix
for that will be (2 of 2).
To test, instead of mucking about with CFLAGS or sys/unix/hints, I've
been temporarily adding unconditional
|#undef USE_STDARG
|#undef USE_VARARGS
|#define USE_OLDARGS
to the end of config1.h and then doing my normal build--which is why
-Wall (or possibly -W) is drawing -Wint-to-pointer-cast warnings.
Mark panic() as never returning so that code analysis might be able
to do a smarter job. It required splitting done() into two routines
since the first part really can return (but not if PANICKED was the
reason it got called). done() is now much shorter and ends with a
call to new really_done(), and panic() skips done()'s might-return
part by calling really_done() directly.
Noticed in passing: the "report error to <list of SYSCF WIZARDS>"
code calls a routine which uses alloc(), which won't work very well
if the reason for panic was because malloc() ran out of memory.
I tracked down the widest lines, which sometimes occur due to mis-indent
of block comments (see tradstdc.h for an example), and fixed those up.
For the files affected, I also converted tabs to spaces.
I did my best to exempt some of the bigger aligned blocks from the reformatting
using the /* clang-format off */ and /* clang-format on */ tags. Probably some
that shouldn't have been formatted were anyway; if you encounter them, please
fix.
The clang-format tags were left in on the basis that it's much easier to prune
those out later than to put them back in, and it means that, modulo my custom
version of clang-format, I should be able to run clang-format on the source tree
again without changing anything, now that Pat has fixed the VA_DECL issues.
Make the variadic functions look more like ordinary code rather than
have the function opening brace be hidden inside the VA_DECL() macro.
That brace is still there, but VA_DECL() now needs to be followed by
a visible brace (which introduces a nested block rather than the
start of the funciton). VA_END() now provides a hidden closing brace
to end the nested block, and the existing closing brace still matches
the one in VA_DECL().
Sample usage:
void foo VA_DECL(int, arg) --macro expansion has a hidden opening brace
{ --new, explicit opening brace (actually introduces a nested block)
VA_START(bar);
...code for foo...
VA_END(); --expansion now provides a closing brace for the nested block
} --existing closing brace, still pairs with the hidden one in VA_DECL()
This should help if/when another round of reformatting ever takes place,
and also with editors or other tools that do brace/bracket/parenthesis
matching.
I had forgotten that there were variadic functions in sys/* and ended
up modifying a lot more files than intended. The majority of changes
to those just inserted a new '{' line so that revised VA_END()'s '}'
won't introduce a syntax error. A couple of them needed VA_END() moved
so that local variables wouldn't go out of scope too soon. Only the
Unix ones have been tested.
The previous USE_OLDARGS worked with gcc on Intel, but was inherently
unsafe. This method is completely safe, just obnoxiously intrusive.
It you disliked debugpline*(), you're bound to hate this....
Remove the requirement for <stdarg.h> that was introduced to lev_comp.
USE_STDARG still works. USE_OLDARGS required hackery but has been
tested and actually works, although I wouldn't trust it on platforms
where 'long' and 'char *' aren't the same size. USE_VARARGS didn't
require any hackery--aside from the conversion to core's pline code--
but has not been tested: <varargs.h> supplied with OSX won't compile,
with an #error directive that basically says "switch to <stdarg.h>".
I changed several printf formats of %i and %li to %d and %ld because
I'm not sure how widespread the 'i' variant was back in days of yore.
[TODO: avoid use of snprintf since pre-ANSI systems won't have it.]
