The orignal code had `unsigned long` inside `#ifdef MSVC`. It was then changed
to `uint64_t` which was incorrect because on Windows `sizze long == 4`.
Change it now to `uint32_t` which is always correct regardless of OS, compiler
or architecture.
* HTML files should be installed to $(htmldir), and $(docdir) should
not be changed, as this is a user flag in the GNU conventions.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
These fixes are in the public API, but FLAC would have been extremely
unlikely to work in any system where `unsigned` was not 32 bits.
Therefore we do not treat this as an API change.
As pointed out by Ozkan Sezer, on some platforms `int32_t` is actually
a typedef for `long` so `unsigned` cannot be used interchangably with
`FLAC__uint32`. Fix is to switch from `unsigned` to explicit sized ISO
C types defined in <stdint.h>.
Not all linux hosts match the *-pc-linux-gnu wildcard, causing build
failures for older glibc versions where we need to link with -lrt for
clock_gettime - E.G.:
- arm-unknown-linux-musleabihf
- powerpc-unknown-linux-gnuspe
- bfin-linux-linux-uclibc
..
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
We've been working on a draft spec for encapsulation of FLAC
in the ISO Base Media File Format (mp4). This is the initial
draft created by Monty Montgomery based on Yusuke Nakamura's
Opus-in-mp4 draft.
More details at https://bugzilla.mozilla.org/show_bug.cgi?id=1286097
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
If a seek table has already been read successfully, then the
has_seek_table flag is true. Now imagine the file comes with another
seek table, which doesn't make sense, but libFLAC accepts it happily.
If reading this second seek table fails (for example allocation
failure), read_metadata_seektable_() returns false, but the
has_seek_table flag is still true. If the calling application happens
to ignore this failure, and at some point tries to seek, the process
will crash due to NULL pointer dereference. This would sure be an
application bug that needs to be fixed, but libFLAC's internal state
is inconsistent, so let's fix this up.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
When read_metadata_seektable_() fails, the has_seek_table flag is
never set to true, and thus free() is never called.
Example valgrind output:
11,185,464 bytes in 1 blocks are definitely lost in loss record 62 of 62
at 0x4C2BC0F: malloc (vg_replace_malloc.c:299)
by 0x4C2DE6F: realloc (vg_replace_malloc.c:785)
by 0x40A7880: safe_realloc_ (alloc.h:159)
by 0x40A7911: safe_realloc_mul_2op_ (alloc.h:205)
by 0x40AB6B5: read_metadata_seektable_ (stream_decoder.c:1654)
by 0x40AAB2D: read_metadata_ (stream_decoder.c:1422)
by 0x40A9C79: FLAC__stream_decoder_process_until_end_of_metadata (stream_decoder.c:1055)
It is easy to craft a FLAC file which leaks megabytes of memory on
every attempt to open the file.
This patch fixes the problem by removing checks which are unnecessary
(and harmful). Checking the has_seek_table flag is not enough, as
described above. The NULL check is not harmful, but is not helpful
either, because free(NULL) is documented to be legal.
After running this code block, we're in a well-known safe state, no
matter how inconsistent pointer and flag may have been before, for
whatever reasons.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
