$GIT/scripts/LEVEL15.cpp: In function ‘void aMatCenPuzzleInit()’:
$GIT/scripts/LEVEL15.cpp:833:38: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
833 | #define MagicMatCenSwitchSequence (*((int *)(&User_vars[17])))
$GIT/scripts/LEVEL15.cpp:834:25: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
834 | #define MatCenStateA (*((int *)(&User_vars[0])))
...
$GIT/scripts/Level6.cpp: In function ‘void aPriestKeyEnter(int)’:
$GIT/scripts/Level6.cpp:910:47: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
910 | #define Var_ThereIsPlayerInPriestKeyPuzzle (*((int *)(&User_vars[7])))
Turn ``User_var`` into an array of std::variant, the latter of which can hold
either float or int. Savegames do not carry the necessary type information
which variant (float/int) is in use; instead, this is statically decided by
the level DLL logic on a per-index basis. This approach is retained for now.
A lot of ``Var_something = 0`` is used despite Var_something being
logically used as float, so we need to override op= to keep the
variant type as-is.
Due to ``#include "DallasFuncs.cpp"``, DF is recompiled 52 times.
Rework it to build just once. The compile time goes down for me
from 1m45.3s to 1m38.8s on my 1135G7 CPU running make -j8.
I want to namespace the stuff in DallasFuncs.cpp, and when I do that,
there comes about an ambiguity between ``NewNamespace::aUserFlagSet``
and the ``::aUserFlagSet`` declared by LEVEL15 (also ``qUserFlag``).
Due to ``#include "DallasFuncs.cpp"``, LEVEL15.cpp already has a
declaration (and definition) for ``aUserFlagSet``, and so we can jsut
remove the two lines.
The vast majority of this is fixing up `char *` that should be `const char *`
but a handful of other fixes, like potential buffer overflows that GCC
noticed, etc, were applied as well.
This removes `-Wno-write-strings` from CMakeLists.txt, as it is no longer
necessary, as there is no longer a flood of compiler warning spam when
building.
This does not fix all compiler warnings; there are still a handful, and they
are legitimate, but they can be dealt with in a future commit.
Most of the warnings were caused by uninitialized values. Some were in plug-ins that didn't have a break in a switch, causing the memory to be deleted twice.
