Descent3/multi_dll_mgr.cpp:974:43: warning: deleting "void*" is
undefined [-Wdelete-incomplete]
(``delete`` requires that types are _complete_, so as to find the
right destructor to call; ``void`` is incomplete by definition.)
This solves problem of inability determine generated output directory of libraries targets. Now `add_custom_command()`, used on HOG generation, correctly locates all needed paths and not depends on generated variables.
Before this change, Descent 3 would look for all of its game data files
in a single directory. This change allows users to spread out Descent
3’s game data over multiple directories.
Building Descent 3 produces multiple files that can be freely
redistributed (Descent3, d3-linux.hog, online/Direct TCP~IP.d3c, etc.).
Running Descent 3 requires those files and several additional files that
cannot be freely redistributed. Before this change, the files that were
redistributable had to be in the same directory as the files that were
not redistributable. This change makes it so that they can be in
separate directories.
The main motivation behind this change is to allow people to package
Descent 3 for Linux in a reasonable manner. For the most part, binary
packages for Descent 3 will contain all of the freely redistributable
components. Package managers will copy those components into system
directories that are owned by root and that users probably shouldn’t
edit manually. Users will then create a new directory and copy the game
data from their copy of Descent 3 into that new directory. Users will
then be able to run:
Descent3 -setdir <path-to-proprietary-files> -additionaldir <path-to-open-source-files>
The -additionaldir option can also be used to support more complicated
scenarios. For example, if the user is using Debian’s
game-data-packager [1], then they would do something like this:
Descent3 -setdir <path-to-writable-directory> -additionaldir <path-to-gdp-directory> -additionaldir <path-to-open-source-files>
The -additionaldir option can also be used to load a mod that replaces
.hog files:
Descent3 -setdir <path-to-base-game-data> -additionaldir <path-to-mod-files>
[1]: <https://github.com/DescentDevelopers/Descent3/issues/373#issuecomment-2120330650>
Before this change, Base_directory was a char array. In general, it’s
better to use an std::filesystem::path to represent paths. Here’s why:
• char arrays have a limited size. If a user creates a file or directory
that has a very long path, then it might not be possible to store that
path in a given char array. You can try to make the char array long
enough to store the longest possible path, but future operating systems
may increase that limit. With std::filesystem::paths, you don’t have
to worry about path length limits.
• char arrays cannot necessarily represent all paths. We try our best to
use UTF-8 for all char arrays [1], but unfortunately, it’s possible to
create a path that cannot be represent using UTF-8 [2]. With an
std::filesystem::paths, stuff like that is less likely to happen because
std::filesystem::path::value_type is platform-specific.
• char arrays don’t have any built-in mechanisms for manipulating paths.
Before this commit, the code would work around this problem in two
different ways:
1. It would use Descent 3–specific functions that implement path
operations on char arrays/pointers (for example, ddio_MakePath()).
Once all paths use std::filesystem::path, we’ll be able to simplify
the code by removing those functions.
2. It would temporarily convert Base_directory into an
std::filesystem::path. This commit simplifies the code by removing
those temporary conversions because they are no longer necessary.
[1]: 7cd79025 (Merge pull request #494 from Jayman2000/encoding-improvements, 2024-07-20)
[2]: <https://github.com/rust-lang/rust/issues/12056>
Before this change, API.vp[5] was cast to a pilot pointer and then cast
to a char pointer immediately afterwards. Nothing gets done to API.vp[5]
while it’s a pilot pointer, so we can remove the pilot pointer cast
without changing any behavior.
vp[26] is `int *`, so it tries to read 4 bytes on amd64, even though
TCP_Active, which is behind vp[26] is just a bool and 1 byte.
==95927==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000004734f40 at pc 0x7f4f8d93b952 bp 0x7ffc57f191b0 sp 0x7ffc57f191a8
READ of size 4 at 0x000004734f40 thread T0
f0 DLLMultiInit $GIT/netcon/includes/mdllinit.h:314
f1 LoadMultiDLL(char const*) $GIT/Descent3/multi_dll_mgr.cpp:690
f2 RunServerConfigs $GIT/Descent3/dedicated_server.cpp:236
f3 LoadServerConfigFile() $GIT/Descent3/dedicated_server.cpp:357
f4 InitDedicatedServer $GIT/Descent3/init.cpp:1778
f5 InitD3Systems2(bool) $GIT/Descent3/init.cpp:1952
f6 Descent3() $GIT/Descent3/descent.cpp:504
f7 oeD3LnxApp::run() $GIT/Descent3/sdlmain.cpp:151
0x000004734f41 is located 0 bytes after global variable 'TCP_active' defined in '$GIT/networking/networking.cpp:383:6' (0x4734f40) of size 1
SUMMARY: AddressSanitizer: global-buffer-overflow $GIT/netcon/includes/mdllinit.h:314 in DLLMultiInit
