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.]
This reverts commit 7f0f43e6f9 and some related
subsequent commits.
This compiles, but I have not done extensive testing.
Conflicts:
include/config.h
include/decl.h
include/extern.h
include/global.h
include/tradstdc.h
include/wintty.h
src/drawing.c
src/files.c
src/hacklib.c
src/mapglyph.c
src/options.c
sys/winnt/nttty.c
win/tty/getline.c
win/tty/topl.c
win/tty/wintty.c
This is the code I built trying to figure out the large window size issue.
It completely compiles out if not needed (see -DWINCHAIN in hints/macos10.7)
and except for one call during setup has zero overhead if compiled in and
not used. See window.doc for more info.
Defs for UNUSED parms. I know this has been controversial, so use is isolated
to the chain code and windows.c (where it shouldn't be intrusive and saves about
50 warnings).
Hints file for 10.7, but the build process still needs to be migrated from
the branch.
Pat noted that I neglected to drop the SCCS lines on the files I've been
committing, so clean up those and any others I could find where the SCCS
line date is out of date.
This is all tiny stuff - allow overriding WIDENED_PROTOTYPES from the hints
file, missing NO_SIGNAL conditionals, remove a GCC-ism, conditional indentation,
void return in a non-void function.
- ensure that wchar.h is included even if it is not included
from another system header file as it is on some platforms.
- attempt to make the NHWCHAR_P definition more appropriate
for more platforms.
This patch attempts to add some levels of unicode support
to NetHack.
The master on/off switch for any Unicode support is
defining UNICODE_SUPPORT in config.h. Currently
there is code support for two subsets of unicode support:
UNICODE_DRAWING
If UNICODE_DRAWING is defined, then the data
structures used to house drawing symbols are expanded
to the size of wchar_t, big enough to hold unicode characters.
A typdef called `nhsym' is involved and if UNICODE_DRAWING
is defined, it is wchar_t, otherwise it is uchar.
UNICODE_WIDEWINPORT
If UNICODE_WIDEWINPORT is defined, then the data
structures inside the window port are expanded to the size of
wchar_t, big enough to hold unicode characters. Both map
symbols and text within the window port are expanded, in order
for potential support for displaying multinational characters some
day, but this patch only provides viewing of map symbols.
A typdef called `nhwchar' is involved and if UNICODE_WIDEWINPORT
is defined, it is wchar_t, otherwise it is char.
The only window port with code support for UNICODE_WIDEWINPORT
currently is the TTY port. Don't enable UNICODE_WIDEWINPORT
unless:
- it is a TTY port
- the underlying platform specific routines can
handle the larger data structures.
Don't enable UNICODE_SUPPORT unless:
- your compiler can handle wchar_t.
- your compiler can accept L'a' characters.
- your compiler can accept L"wide" strings.
Note that if your compiler can handle the above, you could
enable the larger data structures (currently if TTY) even if your
platform can't actually display unicode or UTF-8, by messing
with u_putch() in win/tty/wintty.c to only deal regular chars.
That should be the only function that actually pushes wide characters
out to the display.
If you enable UNICODE_SUPPORT, and your platform is capable
you will need to turn on the unicode run-time option to be able to
load unicode character sets from the symbol file, to be able to
push unicode characters to the display. You'll also want to load
a unicode symbol set once the unicode option is toggled on. In
a config file you would do that via these two lines:
OPTIONS=unicode
OPTIONS=symset:Unicode_non_US
The repository was stamped with NETHACK_PRE_UNICODE
prior to applying this patch, and stamped with
NETHACK_POST_UNICODE afterwards. The code differences
between those two tagged versions are this patch.
Hide pointer formatting in alloc.c by eliminating the need for callers
to know how big a buffer is required. I generally prefer the caller to
pass in its own buffer for this sort of thing, but in this case the usage
is almost entirely for debugging so using static buffers results in less
clutter in the rest of the code.
Move the new VOID_ARGS and some other argument manipulation stuff
from global.h to tradstdc.h where it feels like a better fit. Make the
definition of VOID_ARGS more general; it should work nearly everwhere
these days even if it is only needed for one configuration. XXXconf.h
can redefine it as empty if necessary.
For MONST_P and OBJ_P, I left "void*" as is but I'm pretty sure that
the lack of space in between the two components was never part of the
issue there. (The Ultrix system I used to have access to is long gone.
It was chugging along on autopilot, effectively defenseless, at the time
a linux box on the same subnet got hacked. It probably would have been
shut down for Y2K anyway if it had lasted til then.)
Add absent prototypes to some core routines.
Also add some port function() to function(void) in some win32 routines.
Also updates the Borland C Makefile for win32.
* Updated preprocessor conditionals for the MPW compilers.
* Use new system call names provided for in the latest Apple
Universal Headers.
* Tune up some of the includes for CodeWarrior.
* Define YY_NEVER_INTERACTIVE for the dungeon and level compilers.
* Remove pointless debugging code.
