Suggested-by: lvqcl <lvqcl.mail@gmail.com>

Thomas Zander authored Oct 11, 2015 and Erik de Castro Lopo committed Oct 12, 2015

- build/config.mk: some OS call x86_64 amd64
- build/config.mk: FreeBSD needs -DHAVE_SYS_PARAM_H in CFLAGS
- build/exe.mk and lib.mk: default compilers on FreeBSD are cc/c++
- src/libFLAC++/Makefile.lite: $(OS) is not defined
- src/libFLAC++/Makefile.lite: Link -lstdc++ on FreeBSD
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>

Suggested by Christopher Key.

Closes: https://sourceforge.net/p/flac/patches/43/

Fix suggested by Daniel Macks.

Closes: https://sourceforge.net/p/flac/bugs/433/

Tristan Matthews authored Sep 29, 2015 and Erik de Castro Lopo committed Sep 30, 2015

Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>

Tristan Matthews authored Sep 29, 2015 and Erik de Castro Lopo committed Sep 30, 2015

Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>

When doing a flac to flac conversion, bad data read from the input file
was making it all the way through the encoder to cause a read past the
end of the buffer in the CRC calculation.

Fix had two parts:

* bitwriter.c: Make a debug only assert (assert bits < 32) into a proper
  failure.
* stream_encoder.c: Catch the error condition of wasted bits being greater
  that bits_pers_sample and limit it to the bits_per_sample value.

Found using the American Fuzzy Lop fuzzer.

Patch-from: lvqcl <lvqcl.mail@gmail.com>

libFLAC_static.vcxproj was missing a dependency on win_utf8_io_static.

Patch-from: lvqcl <lvqcl.mail@gmail.com>

Left shift if a negative integer such that the sign bit is affected is
(according to the C spec) undefined behaviour and the residual
calculations using the shift operator were hitting this.

Fortunately these same calculations using plain multiplication do not
invoke UB and according to benchmarking (on x86_64 linux) have the same
performance as the bit shift version.

Undefined behaviour in the test support code.

In the case where seek_table->num_points is zero, seek_table->points
will be NULL and passing that to qsort() invokes undefined behaviour.

Since seek_table->num_points is zero, the only sensible thing to do
is to short circuit return 0.

Found by compiling with -fsanitize=undefined and running the testsuite.

Improve folding of signed to unsgned to avoid UB.

The function FLAC__bitreader_read_raw_int32() triggered undefined behaviour
when sign extending an unsigned value. The Stanford Grahpics bithacks page
provided an alternative that avoided UB.

Make sure ctx->capacity gets updated correctly when safe_realloc()
fails.

Patch-from:  lvqcl <lvqcl.mail@gmail.com>

Leak introduced in commit d9ae5e91. Thanks to lvqcl <lvqcl.mail@gmail.com>
for pointing it out.

The new function wraps, realloc() and if the realloc() fails, it
free()s the old pointer.

This is an improvement on the potential realloc() memory leak that
was fixed in 15a90626.

Still needs fuzzing to validate it.

The american-fuzzy-lop fuzzer found a couple of instances of double
free() resulting from commit 15a90626.

The problematic free() were the ones associated with use of the
safe_realloc_mul_2op_() function which can call realloc(ptr,0) which
according to the realloc manpage is already an implicit free().

Ben Boeckel authored Aug 12, 2015 and Erik de Castro Lopo committed Aug 14, 2015

Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>

If the `realloc` function failed, memory would leak.

Patch-from: lvqcl <lvqcl.mail@gmail.com>

Shift by a negative value is undefined behaviour so there is no "right"
way of dealing with this.

Patch-from: lvqcl <lvqcl.mail@gmail.com>

The function get_utf8_argv() was calling LoadLibrary to load msvcrt.dll
but wasn't calling FreeLibrary() if GetProcAddress() fails.

Patch-from: lvqcl <lvqcl.mail@gmail.com>

Patch-from: lvqcl <lvqcl.mail@gmail.com>

According to MSDN, stricmp and strnicmp functions are deprecated
since MSVC 2005 and _stricmp/_strnicmp should be used instead.

Patch-from: lvqcl <lvqcl.mail@gmail.com>

Closes: https://sourceforge.net/p/flac/bugs/428

According to https://developer.android.com/ndk/guides/abis.html#x86
Android always support SSE, so there's no need to test SSE OS support.

Why both __ANDROID__ and ANDROID are tested:
http://stackoverflow.com/questions/15328751/android-macro-suddenly-not-defined
http://stackoverflow.com/questions/6374523/how-to-detect-compilation-by-android-ndk-in-a-c-c-file
https://groups.google.com/forum/#!topic/android-ndk/cf9_f1SLXls

Patch-from: lvqcl <lvqcl.mail@gmail.com>