MSVC only got stdbool.h in MSVC 2013; provide a manual typedef
for this compiler instead.
The C interface test makes sure that this doesn't break the ABI.
Within I420 (as the decoder outputs), the first chroma plane is
U and the second is V, and similarly, in NV12, the chroma components
are written in the order U, V.
This doesn't have any practical effect, it only makes the
variable naming while it previously was misleading.
TRUE/FALSE has intentionally been left in use for the few
platform specific APIs that define these constants themselves
and expect them to be used, for consistency.
This file contains the local UI state of the resource editor,
and should not be committed to version control.
A similar file was removed earlier in c61b040, but this one
was missed.
The actual float and double data types are defined in C89 and are
usable as such without any extra typedefs.
Removing the extra typedefs simplifies the compatibility typedef
headers, simplifies portability and makes the code base easier
to work with for people new to the library.
Instead of byteswapping a 32 bit word and writing it out as a
whole (which could even possibly lead to crashes due to
incorrect alignment on some platforms), write it out explicitly
in the intended byte order.
This avoids having to set a define indicating the endianness.
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.
As long as WelsFileHandle* is equal to FILE* this doesn't matter,
but for consistency use the WelsF* functions for all handles
opened by WelsFopen, and use WelsFileHandle* as type for it
instead of FILE*.
