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.
This is a more convenient behaviour (truncating on overflow and
always null terminating the buffer) compared to the MSVC
safe strcat_s which aborts the process if the string doesn't fit
into the target buffer.
Also mark the source buffer as const in the function prototype.
Make the MSVC "safe" version truncate instead of aborting the
process if the buffer is too small.
Update all the other functions to use the right parameter
(iSizeInBytes, not iCount) as 'n' parameter to strncpy.
(By passing iCount as parameter to the normal strncpy functions,
it meant that the resulting buffer actually never was null
terminated.)
Additionally make sure that the other implementations of WelsStrncpy
always null terminate the resulting buffer, just as the MSVC safe
version does when passed the _TRUNCATE parameter.
This simplifies the code and makes the buffer size checks
more consistent. Additionally, the previous version wrote
the extra space character without checking if it actually fit
into the buffer.
These were essentially useless - if strlen() ever was used as
fallback, it either indicated that those ports of the library
were insecure, or that strnlen never was required at all.
In this case it turned out to be the latter (at least after
the preceding cleanups) - all uses of it were with known null
terminated strings.
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.
The object files for this tool aren't built with the /GL flag
(Whole Program Optimization), leading to the following warning
when linking:
/LTCG specified but no code generation required; remove /LTCG from
the link command line to improve linker performance
Enabling link time code generation for the console front end binary
isn't of much use, since this tool in itself isn't performance
critical.
