fix Windows/MSVC build portability - #1
Open
terbin wants to merge 1 commit into
Open
Conversation
- rsa.cpp: open the key file with _wfopen on Windows, where std::filesystem::path::c_str() is const wchar_t*; add <cstdio> - biomes.cpp: use std::clamp<int> so the arguments share a type (UINT8_MAX is unsigned char on the MSVC UCRT but int on glibc, which breaks deduction) - CMakeLists: on Windows, resolve zlib/OpenSSL via find_package imported targets instead of the Unix link names z/crypto
This was referenced Jul 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three portability fixes so
mc_cppcompiles and links under Windows (clang targeting the MSVC ABI, dependencies via vcpkg). Non-Windows behavior is unchanged.Changes
include/mc_cpp/crypto/rsa.cpp:std::filesystem::path::c_str()returnsconst wchar_t*on Windows, so it doesn't matchfopen(const char*, ...). Use_wfopenon Windows andfopenelsewhere; add#include <cstdio>. Using_wfopenwith the native wide path also keeps Unicode paths intact; a narrowfopenwould route the filename through the lossy ANSI code page (CP_ACP).include/mc_cpp/registry/registries/biomes.cpp:std::clamp(a, b, c)deduces a single type from all three arguments.UINT8_MAXisunsigned charon the MSVC UCRT (butinton glibc), so deduction fails to compile on MSVC. Pinstd::clamp<int>(...); a no-op where the arguments were alreadyint.CMakeLists.txt:z/cryptoare Unix library names. On Windows, resolve zlib and OpenSSL viafind_package(ZLIB)/find_package(OpenSSL)and link the imported targetsZLIB::ZLIB/OpenSSL::Crypto(plusws2_32). The non-Windows branch keeps the existinglink_libraries(z crypto)unchanged.Verification
Builds and links as part of the PlaceViewer native library on Windows (clang 22 + vcpkg:
boost-iostreams,zlib,openssl) and Linux (g++ 13.3). The non-Windows code paths (the#elsefopen, theelse()link branch) are unchanged from upstream. The resulting library was also run on a live Windows Paper 1.21.4 server, wheremc_cpp's registry initialization executed successfully.Notes / possible follow-up
The imported-target link approach could be made unconditional (it would also modernize the Linux link and drop the discouraged directory-scope
link_libraries). This PR intentionally keeps the Linux path byte-identical to avoid touching the currently-working build; happy to make it unconditional if preferred.Part of a coordinated Windows/g++ portability set
2b2tplace/zvcr, companion: fix builds under MSVC and g++ zvcr#62b2tplace/mc-cpp: this PR2b2tplace/PlaceViewer, companion, depends on this + zvcr: fix Windows native build portability PlaceViewer#4