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.
This README provides the instructions for building the unofficial Mac binaries using the Apple provided developer IDE named XCode. Establish a developer team in XCode =================================== Your first step should be to establish a developer team within XCode. Launch XCode and open the preferences dialog (XCode Menu->Preferences). Select the "Accounts" tab. Add an account (usually this should just be your apple ID account you used to setup the Mac). After adding the account, select the account and then add a team (usually this will be just a personal team for Mac Development). Obtain your developer team identifier ===================================== Your DEVELOPMENT_TEAM can be found by opening Keychain Access (found by Finder->Applications->Utilities). Click on "My Certificates". Look for your "Mac Developer" certificate. Right click on the certificate to open a dialog that shows certificate details. Look for "Organizational Unit" among the details. This ten digit value is your development team identifier. Create XCodeLocal.xcconfig file =============================== Now you need to create the XCodeLocal.xcconfig file that will be used by XCode to get your development team identifier. Create the file in sys/unix and add a single line such as: DEVELOPMENT_TEAM = XXXXXXXXXX Where XXXXXXXXXX is replaced with your development team identifier. Open the project and build ========================== In XCode open the project file sys/unix/NetHack.xcodeproj, select the product NetHack and build. The build results are placed in ~/nethackdir.