Theoretically, when a rice parameter of 0, 24-bit samples, fixed
predictor with order 0, no rice escaping and a blocksize of 65536
is chosen, a subframe could be up to 2^24*65536 = 1 terabyte in
size. While this obviously should never happen, the analyse
function should be able to debug such a case.
A bug beginning in gcc version 9.2 causes strings to get incorrectly
stripped when passed directly to memcmp with a zero first byte (1).
This bug causes flac -t to fail on any .flac file with a md5 checksum
beginning in 00. To work around this bug, the FLAC__byte type is used
for an empty md5 sum to prevent a string from being stripped, which
is backwards compatible and avoids compile-time checks. This was
initially reported back in March 2020, but has seen more light since
Ubuntu 19.10 and up ship with gcc 9.2 as the default compiler. A
patch has been merged into the master gcc branch (2), but has not
been included in any versions as of this commit date.
The initial reporter provided a patch in their bug report (3), which
is included in this PR with authorship attributed to the reporter.
(1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
(2) https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d5803b9876b3d11c93d1a10fabb3fbb1c4a14bd6
(3) https://sourceforge.net/p/flac/bugs/478/Closes#192.
There is a small typo in oss-fuzz/fuzzing/datasource/datasource.hpp.
Should read `operator` rather than `opertator`.
Signed-off-by: Ralph Giles <giles@thaumas.net>
* Improve CPU features detection
CMAKE_SYSTEM_PROCESSOR is pretty useless (e.g. when compiling with
MSVC ARM64 toolchain and Ninja still returns system processor).
* Don't build src/utils targets by default
Fix compilation for UWP platform.
* Add more Visual studio Git ignore patterns
* Autogenerate Doxygen docs
> if the partition order is zero, n = frame's blocksize - predictor order
> else if this is not the first partition of the subframe,
> n = (frame's blocksize / (2^partition order))
> else n = (frame's blocksize / (2^partition order)) - predictor order
if the partition order is zero, then partition_number can only be zero
if the partition order is zero, then
(frame's blocksize / (2^partition order))
is (frame's blocksize / 1) == frame's blocksize
This commit contains the following changes:
- Drops -fstack-protector in favor of -fstack-protector-strong.
Consequently, the ssp-buffer-size parameter has been removed as
-fstack-protector-strong ignores array size.
- Add new global opt-out for stack smash protection. This is enabled
by default for both autotools and CMake builds. Users can opt out
of stack smash protection by passing -DWITH_STACK_PROTECTOR=OFF to
CMake or --disable-stack-smash-protection when running ./configure.
- Renames HAVE_SSP_FLAG to HAVE_STACK_PROTECTOR_FLAG in
CMakeLists.txt to be more readable.
We work in deterministic mode by default, so timestamps are zeroed,
thus it is impossible to check timestamps and insert only newer
members. Silences the following autotools warning:
ar: `u' modifier ignored since `D' is the default (see `U')
https://sourceware.org/binutils/docs/binutils/ar-cmdline.html
Doxygen sees '#' as a cross-reference, which this is not in this case. This will silence the following warning that pops up frequently when building with docs:
warning: explicit link request to 'defines' could not be resolved
The code shorthand tag was removed in include\FLAC\all.h to remain synonymous with other mentions of #define.
This will bring our doxyfile closer to the modern world and clean up some warnings in the doxygen output during a regular build. I believe it is pretty fair to use 1.7.6.1 given it released in 2011, with the 1.7.x branch a year prior. The current branch is 1.8, which released 2012, but I believe 1.7.6.1 is sufficient.
Updated by running doxygen -u doc/Doxygen.in with Doxygen 1.7.6.1. The only manual change was adding 'Free Lossless Audio Codec' to PROJECT_BRIEF.
These fuzzing targets were originally from:
https://github.com/guidovranken/flac-fuzzers.git
but having them in a separate repo was a huge pain in the neck when
working on fixing any problems found.
These includes header files were taken from:
https://github.com/guidovranken/fuzzing-headers.git
with some minor changes required to make them compile cleanly
with the extra compiler warning flags used by the FLAC build
system.
- document version requirements in the top-level file.
- remove incorrect version requirements from sub-dirs.
- set min. required version to 3.5 in top-level file.
- set minimun required version to 3.9 under docs/ .
- make documents building an option (on by default.)
so, the tree can be built using cmake-3.5 using
-DBUILD_DOCS=0 on the command line.
flac_snprintf() is used everywhere else in there. that single instance
of plain snprintf() was added in commit 04974d27. fixes flac.exe build
with older msvc versions.
When building in the same directory as the source, it works, but not in
a separate directory. The trailing slash is important with nasm. Note
that include_directories("${CMAKE_CURRENT_SOURCE_DIR}/") does not work
because cmake seems to strip the trailing slash.
Also relax the cmake version requirement from 3.12 to 3.9 as everywhere
else in the tree: it works just fine.
The flac configury marked clang as 'not being gcc' and excluded
a lot of compiler switches, most importantly the visibility flags,
from being used with it. This was done possibly after a problem
reported at: https://github.com/erikd/libsndfile/issues/49 .
This patch does the following:
- m4/gcc_version.m4 (XIPH_GCC_VERSION): set GCC_MAJOR_VERSION and
GCC_MINOR_VERSION to 0 for non-gcc. Previously, they were left
unset.
- configure: the gcc version checks are, naturally, against non-
zero values, so, allow many compiler switches to be used with
clang without affecting real-gcc cases.
- configure: When setting CFLAGS="-O3 -funroll-loops", also set
CXXFLAGS="-O3". Prevents g++ warnings with _FORTIFY_SOURCE, i.e.:
'_FORTIFY_SOURCE requires compiling with optimization (-O)'
Tested compilation using gcc-7.3.1 and clang-5.0.2 on x86_64-linux,
and gcc-4.4.7 and clang-3.4.2 on an i686-linux. Also tested cross-
compiling for Mac OS X using clang-5.0.2.
the issue is, flac and metaflac exes rely on flac_internal_???_utf8()
procedures from windows_unicode_filenames.c and there is no easy way
to exclude them from exports without breaking things. So export them
explicitly (they are exported anyway w/o this patch), but add a FIXME
note about the kludge in windows_unicode_filenames.c.
Martijn van Beurden