If ERR_DROP during Com_GameRestart after shutting down client, Com_Error
needs to restart the client otherwise there is just a black window. Also,
clear the game restarting flag in Com_Error otherwise it's not possible to
run Com_GameRestart again later.
I don't know of a way to trigger ERR_DROP, in FS_Restart for instance,
without engine changes however.
Offer to restore settings when loading a mod that crashed, not the first
mod that gets loaded after a crash. Before the first mod loaded (usually
baseq3) would get the option even if missionpack or some other mod crashed.
- Make pid files separate for each fs_game.
- Remove/write pid every time switching fs_game.
- Create path before writing pid file otherwise it fails on first run.
- Show mod description.txt or fs_game instead of engine name in abnormal
exit message.
- Check com_fullyInitialized in Com_Error before removing PID,
otherwise "ioquake3 --version" segfaults when accessing fs_gamevar->string
(plus not fully initialized isn't really a normal shutdown).
As with the other branch of the if/else, each element of
foundPlayerServerNames is in fact the same size as each element of
foundPlayerServerAddresses, so it was fine; but it's better to make
it obvious that we are using the right array sizes.
This function is used in the Team Arena menus
I don't think it's actually possible to reach this line with
foundPlayerServerNames < 1, because by the time we get here we have
set it to 1 + the actual number of servers; but if we did, it would
clearly underflow into foundPlayerServerNames[-1], which would be
undefined behaviour. gcc 6 diagnoses this with a warning:
code/ui/ui_main.c: In function ‘UI_BuildFindPlayerList’:
code/ui/ui_main.c:4138:16: warning: array subscript is below array bounds [-Warray-bounds]
Also correct the sizeof() invocation to make it more obviously
correct (in fact the buffers for names and addresses happen to both
be of size MAX_ADDRESSLENGTH, so it was fine, but it's good to be
obvious).
Given an array b[] of length n, pointers to &b[0]..&b[n] are defined
(where only &b[0]..&b[n-1] can be validly dereferenced). &b[-1], or
equivalently b-1, is not something we can use in valid Standard C.
gcc 6 diagnoses this as:
code/client/snd_wavelet.c:33:9: warning: array subscript is below array bounds [-Warray-bounds]
and might take this undefined behaviour as permission to emit
"more efficient" object code that is not what the author expected,
for example nothing at all. Use a macro to fake a 1-based array instead.
The goal of reproducible builds is that a rebuild of the same source
code with the same compiler, libraries, etc. should result in the same
binaries. SOURCE_DATE_EPOCH provides a standard way for build systems
to fill in the date of the latest source change, typically from a git
commit or from metadata like the debian/changelog in Debian packages.
This does not change anything if SOURCE_DATE_EPOCH is not defined;
the intention is that a larger build system like a Debian package
will define it.
Please see https://reproducible-builds.org/ for more information about
reproducible builds.
This can be used for LDFLAGS that would be inappropriate for shared
libraries, such as the "-fPIE -pie" used to link position-independent
executables. PIEs make it more difficult to exploit various classes
of security vulnerability.
