this was so broken, I think if anyone ever tried to use __DATE__ or
__TIME__ it must've crashed, either from free(curtime) (which was the
return value of ctime()) or from things like token[7] = NULL when token
was a pointer (to a single element!).
I think it could work now.
Also fixed potential memory leaks in cases that don't "return" anything
These are now used by idStr::(v)snPrintf(), and in the future can
be used if a (v)snprintf() that's guaranteed not to call
common->Warning() or similar is needed (e.g. used during early startup)
idStr is used in both the main thread and the async sound thread, so
it should better be thread-safe.. idDynamicBlockAlloc is not.
Use realloc() and free() instead.
For some reason this caused a lot more crashes (due to inconsistencies
in the allocator's heap) with newer Linux distros (like XUbuntu 20.04)
and when using GCC9, while they rarely reproduced with GCC7 or on
XUbuntu 18.04
fixes#391
according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839
the real compiler flag enabling this bullshit isn't
-fexpensive-optimizations but -ffp-contract=fast which for some(*)
reason is default in optimized builds.
I think it's best to disabled that optimization globally in case it
also breaks other code (I really don't want to spend several days to
hunt such an idiot bug again). I really doubt it makes any measurable
performance difference.
As https://twitter.com/stephentyrone/status/1399424911328874499 says
that clang might also enable this in the future (though to =on instead
of =fast which should be a bit saner but would still break our code),
just set this option for all GCC-ish compilers incl. clang.
(*) the reason of course is that GCC developers don't develop GCC for
their users but to win idiotic SPEC benchmarks
Only happend if `ONATIVE` was enabled (or some other flag was set
that enables the FMA extension), the root cause was that the cross
product didn't return 0 when it should, but a small value < 0.
Caused some faces to be missing in maps compiled with dmap.
https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/436#issuecomment-851061826
has lots of explanation.
I think this is a compiler bug, this commit works around it.
fixes#147
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
