f4a6da2e52
This is the second of a series of changes related to save/restore.
No EDITLEVEL bump has been included, because although the code
is changed extensively by this, the content of the savefiles have
not been changed.
Push the use of the structlevel bwrite() and mread() function use
out of the core and into sfstruct.c. This is groundwork for upcoming
changes.
In the core, replace the bwrite() and mread() calls with the
use of type-specific savefile output (Sfo) and savefile
input (Sfi) macros. The macros are defined in a new header file
savefile.h, which also contains the prototypes for the sfo_* and
sfi_* functions that the macros ultimately expand to. The functions
themselves are in src/sfbase.c.
On C99, each Sfo or Sfi macro expansion refers directly to the
corresponding type-specific sfo_* or sfi_* function.
If C23 or later is is use, the majority (all but 3 types) of the
macros refer to a single _Generic output routine sfo(nhfp, dt, tag),
and a single _Generic input routine sfi(nhfp, dt, tag), which handles
the dispatch of the type-specific underlying functions. This was
somewhat experimental, but turned out to be practical because the
compiler would gripe if the type for a variable was not included in
the _Generic when passed as an argument, so it could be fixed.
This alters the savefile verication process by having a common set
return values for the related functions such as uptodate(),
check_version(), etc. The new return values return more information
about savefile incompatibilities, beyond failure/sucess. The
additional information will be useful for an upcoming addition.
The expanded return values are:
SF_UPTODATE (0) everything matched and looks good
SF_OUTDATED (1) savefile is outdated
SF_CRITICAL_BYTE_COUNT_MISMATCH (2) critical size count mismatch
SF_DM_IL32LLP64_ON_ILP32LL64 (3) Windows x64 savefile on x86
SF_DM_I32LP64_ON_ILP32LL64 (4) Unix 64 savefile on x86
SF_DM_ILP32LL64_ON_I32LP64 (5) x86 savefile on Unix 64
SF_DM_ILP32LL64_ON_IL32LLP64 (6) x86 savefile on Windows x64
SF_DM_I32LP64_ON_IL32LLP64 (7) Unix 64 savefile on Windows x64
SF_DM_IL32LLP64_ON_I32LP64 (8) Windows x64 savefile on Unix 64
SF_DM_MISMATCH (9) some other mismatch
The callers in the core have been adjusted to deal with the expanded
return values.
Other miscellaneous inclusions:
- go.oracle_loc -> svo.oracle_loc.
- add a bit (1UL << 30) to called SFCTOOL_BIT as groundwork
for changes to follow.
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.