There's a different version of the same function in the encoder,
but they're not identical - the encoder version has got stricter
alignment requirements.
If someone can confirm that it is ok to use the function from the
encoder, pixel_sad_neon.S in processing could be deleted, and the
encoder version moved to codec/common instead.
The caller of the function should not need to know exactly which
implementation of it is being used.
For the variants that don't support detecting the number of cores,
the pNumberOfLogicProcessors parameter can be left untouched
and the caller will use a higher level API for finding it out.
This simplifies all the calling code, and simplifies adding
more implementations of cpu feature detection.
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.
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.
int8_t in general should to be defined as signed char, since there
are actual envrionments where a plain 'char' is unsigned.
This also reduces the differences between the typedef headers of
the different sub-libraries.
This makes them match the same macros in the main decoder/encoder
libraries. long_t (which is typedeffed to long) actually is 64
bit on 64 bit unix platforms, which might not be what was
intended.
Just use the standard inline keyword with sufficient backwards
compatibility defines, similar to how it is done in the main decoder
and encoder libraries.
This fixes building on mingw-w64.
Include stdint.h on everything except MSVC for definitions of
common standard types, include stddef.h on MSVC instead, since
MSVC doesn't have stdint.h in all older versions that are
supposed to be supported, but MSVC always defines intptr_t via
stddef.h.
The old InitializeCriticalSection function isn't available in
these API partitions, and the new InitializeCriticalSectionEx
function is only available since Vista, so we want to keep using
the old function for normal desktop code.
astyle was only run on .cpp files this time - already in
ff6b66917 where the style cleanup was done initially, not all
.h files seem to have gotten the same styling (rerunning astyle
on .h files at that commit produces a huge diff).
