For some reason, i386 ASAN does not copy a pointer somewhere in the
code. Using gdb I get a mention of a synthetic pointer, so perhaps
the compiler instrumented with ASAN thinks this pointer isn't
used. Anyway, commit adds a check for that null pointer which
isn't necessary otherwise and is only activated for i386 ASAN.
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58524
The seed corpus had a file that was supposed to cover replaygain
synthesis, but didn't have any replaygain tags. Because of the
fixed format of these tags, they aren't reasonbly reachable by
fuzzing without help
When stderr (flac) or stdout (metaflac) is redirected to a file,
output of non-ASCII characters fails. This commit should fix that.
Fixes https://github.com/xiph/flac/issues/713
NOTE: To enable this change, metaflac no longer outputs
application block data as binary directly, because that would
potentially result in incorrect UTF-8 codepoint. Instead, all
bytes that cannot be represented as printable ASCII are
replaced with the Unicode replacement character
`which` is an external command which isn't required by POSIX.
Debian and other distributions (like Gentoo!) are looking
to drop it from their base set of packages.
Switch to `command -v` which is, however, POSIX. See https://lwn.net/Articles/874049/.
Commit d4daa86167 ("Check for bps% 8 != 0 if no streaminfo is present")
breaks fallback to frame header bps as it tests decoder_session->bps at
a point where it is guaranteed to be 0 as this is the else case of the
if(decoder_session->bps) block.
Some corrupted FLAC files that used to play before the above mentioned
commit no longer can be played.
Move decoder_session->bps = bps to before the decoder_session->bps
validation to restore functionality more similar to before.
It can be linked in the NDK so check_function_exists detects it. But it's only supporting _FILE_OFFSET_BITS=64
since Android API 24 [1].
With NDK 26 it's no longer possible to build assuming the API is always available.
[1] https://android.googlesource.com/platform/bionic/+/main/docs/32-bit-abi.md
In case of encoder failure within a thread, asserts were false
and a locked mutex would be destroyed. This fix leaves in a race
condition: encoder->protected_->state is written without a lock.
Credit: Oss-Fuzz
Issue: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62650
Martijn van Beurden