It corrupted the stack when called with buffers allocated on the stack
and numSamples that are not a multiple of four, apparently, by writing
4 floats too many, at least in the 22KHz Stereo case..
This caused the crash described in
https://github.com/dhewm/dhewm3/issues/303#issuecomment-678809662
Now it just uses the generic C code, like all platforms besides MSVC/x86
already do.
idStr::StripFileExtension() (and SetFileExtension() which uses it) and
others didn't work correctly if there was a dot in a directory name,
because they just searched from last to first char for '.', so if the
current filename didn't have an extension to cut off, they'd just cut off
at any other '.' they found.
So D:\dev\doom3.data\base\maps\bla could turn into D:\dev\doom3
(or, for SetFileExtension(), D:\dev\doom3.map)
While at it, I made most of the idStr code that explicitly checked for '\\'
and '/' (and maybe ':' for AROS) use a little "bool isDirSeparator(int c)"
function so we don't have the #ifdefs for different platforms all over
the place.
On Windows, ID_INLINE does __forceinline, which is bad if the function
calls alloca() and is called in a loop..
So use just __inline there so the compiler can choose not to inline
(if called in a loop).
This didn't cause actual stack overflows as far as I know, but it could
(and MSVC warns about it).
The Doom3: Lost Mission (aka D3LE) mod uses string table entry keys that
don't follow the proper Doom3 scheme of "#str_01234", but look like
"#str_adil_exis_pda_01_audio_info" - the "hash" algorithm of idLangDict,
which basically just converts the number after "#str_" into an int,
probably doesn't work very well with this and there was an assertion
to prevent this..
However, it seems to work well enough, so now I only print one warning
for the first "invalid" key and otherwise accept those keys.
The stringtable (strings/*.lang) also has font-related entries
(like "#font" "Chainlink_Semi-Bold") that triggered another assertion,
now everything that starts with "#font" is silently skipped.
it could happen that i is 1 but numPlanes is still 0
(=> if for i = 0: ( p[j] - p[i] ).LengthSqr() < 0.01f )
so planes[-1] would be accessed which of course is invalid and can crash
Sometimes memory was allocated with new[] but freed with delete instead
of delete[], which is wrong.
And there were some small memory leaks, too.
Furtunately clang's AddressSanitizer detected all that so I could easily
fix it.
(There seem to be some more small memory leaks which are harder to fix,
though)
__builtin_trap() causes an illegal instruction and thus the process
can't resume afterwards.
raise(SIGTRAP) only breaks into the debugger and thus allows to
"ignore" the assertion while debugging.
Everytime List.h is included in a new file (and sys/platform.h isn't)
there are confusing compiler-errors..
So just #include sys/platform.h in List.h directly, because it uses
ID_INLINE which is defined there
GCC had shitloads of superfluous warnings wherever List.h and Str.h were
included.. get rid of them by using #pragma GCC diagnostic at some places
in List.h and Str.h.
Also add some casts, initialize some variables for other warnings
Apart from some minor stuff, this changes the signature of some methods
of Parser and Token classes and of the (unused) Random2 class.
That no problem though, because the calling code uses normal ints
anyway.
The original implementation was pretty broken (but not used anyway),
it is now fixed and improved a bit (got rid of one inner loop).
This (at least part of the problem) was detected by PVS-Studio,
see http://www.viva64.com/en/b/0120/ Fragment 3
Bug introduced with e97d3288. This doesn't work with MinGW, since
the struct members might not be aligned to the native pointer
size (in this case idSampleDecoderLocal was aligned to a 8 byte
boundary on win32).
Just switch the two members to avoid ugly code.
