What the two different implementations currently do is simply
to write a 32 bit number, in the native endianness, into the
given buffer.
The actual purpose of this function is still unknown though,
it can be removed completely without breaking decoding - it
is possibly a remnant from earlier functionality in the
decoder.
The code interprets an array of 4 uint8_t values as one uint32_t
and does shifts on the value. The same optimization can be
kept in big endian as well, but the shift has to be done in the
other direction.
This code could be made truly independent of endianness, but
that could cause some minimal performance degradaion, at least
in theory.
This makes "make test" pass on big endian, assuming that
WORDS_BIGENDIAN is defined while building.
This makes the code work properly on big endian.
The MC case is similar to how it's done in the encoder.
Neither of these should have any significant performance
impact.
strlen is not dangerous if the string is known to be null
terminated (and MSVC does not warn about its use either).
For the cases in the decoder welsCodecTrace.cpp, the string
passed to all WriteString instances is produced by WelsVsnprintf
which always null terminates the buffer nowadays.
Additionally, as the string was passed to OutputDebugStringA
without any length specifier before, it was already assumed to
be null terminated.
The file name parameter passed to DumpDependencyRec and
DumpRecFrame in encoder.cpp is always null terminated,
which was already assumed as it is passed to WelsFopen as is.
As for the encoder utils.cpp, the strings returned by GetLogPath
are string constants that are null terminated.
Both encoder and decoder versions were functionally equivalent,
but I picked the decoder version (but added the static inline
keywords to it) since the encoder one was quite messy with a lot
of commented out code.
Instead of using "defined(MSC_VER) || defined(__MINGW32__)" to
indicate the windows platform, just check for the _WIN32 define
instead.
Also remove an unused codepath - the removed codepath would
only be used under the condition
"(defined(MSC_VER) || defined(__MINGW32__)) && !defined(_WIN32)",
and I'm not aware of any environment with MSVC or MinGW that
doesn't define _WIN32, thus this codepath never was used.
This fixes two separate issues.
First, with the MSVC _snprintf implementations, the return value
is negative if the buffer wasn't large enough - this would in
the worst case lead to making iBufferUsed negative, writing before
the start of the buffer.
Secondly, when both iBufferUsed and iBufferLeft are accumulated,
one can't do "iBufferLeft -= iBufferUsed;". As an example,
say the buffer is 100 bytes in total and iBufferLeft is 40 and
iBufferUsed is 60. If SNPRINTF then writes 5 more bytes to the
buffer, iBufferUsed would be 65, but if we now do
"iBufferLeft -= iBufferUsed;" then iBufferLeft would end up as
-25 even though there's 35 bytes left in the buffer to use.
Therefore, we use a separate variable to store the return value
from the latest SNPRINTF call. This is checked to make sure it
wasn't negative, and only this amount is added to iBufferUsed
and subtracted from iBufferLeft.
This is the same pattern used in codec/encoder/core/src/utils.cpp.
strftime never returns negative numbers, so those calls don't
need as much checking.
Checking iBufferLeft > iBufferUsed does not make sense, since
this would stop writing into the buffer alredy after the buffer
is half full, when there is less space left than has been used.
The right check is iBufferLeft > 0.
No code exists within the project for building such a trace library.
This also fixes building on OS X with -Wno-deprecated-declarations
removed, since this code contained calls to deprecated functions
within #ifdef MACOS, which now are enabled when building on OS X.
