We already read the chunk type so bytesread is always > 0, and
(chunk_size >= chunk_length) will thus always have been covered by
(bytesread + chunk_size > chunk_length) just above.
Most every read api I've ever worked with return no error and positive
byte counts, or zero bytes and an end or error condition. When the end
of stream is reached, the last read will contain the last bytes, and the
next call to read returns an error indicating that end has been reached.
But not mpg123, no, when reaching the last bytes, it returns the last
bytes AND sets the error condition to done.
Assumptions make and ass of you an mumptions.
Using exact comparison ("a == b") when comparing expected with computed
test data fails the test-suite on many architectures (including, but not
limited to armhf and arm64).
Instead, use epsilon(for now, FLT_EPSILON and DBL_EPSILON) to compare
floating point numbers for equality.
Closes: https://github.com/libsndfile/libsndfile/issues/866
Signed-off-by: IOhannes m zmölnig <zmoelnig@iem.at>
When reading a FLAC file, the internal function flac_read_loop is used
to read a block of samples and copy them to the application-provided
output buffer. The 'len' argument to flac_read_loop is the total
number of samples to read (i.e., duration times number of channels.)
Various fields in the FLAC_PRIVATE structure, as well as local
variables in various internal functions, are 'unsigned', which means
that trying to read into a buffer larger than UINT_MAX will cause
problems. To avoid these problems, each function that calls
flac_read_loop breaks up the operation into buffers of at most
0x1000000 (2^24) total samples.
However, flac_read_loop will also fail (due to the condition at line
224) if the requested 'len' is not a multiple of the number of
channels. Consequently, if an application tried to read:
- more than 5592405 frames at once from a three-channel FLAC file
- more than 3355443 frames at once from a five-channel FLAC file
- more than 2796202 frames at once from a six-channel FLAC file
- more than 2396745 frames at once from a seven-channel FLAC file
then sf_read_* or sf_readf_* would incorrectly fail and return zero.
As a simple fix, change the internal size limit from 0x1000000 to
0x690000 (2^16 * 3 * 5 * 7). This is still quite arbitrary, but is
guaranteed to be divisible by the number of channels (which must be
between 1 and 8); it also ought to be large enough to avoid any
performance overhead, and small enough to be easy to test.
Some wav files can have rather large chunks with chunk types that are
not supported by libsndfile at all. For those, header_seek will just
skip the whole chunk.
This commit makes skipping the chunk work even if the input is stdin
(which doesn't support psf_fseek), by reading over the header using
psf_fread in that case.
The function ogg_stream_seek_page_search() is a reimplementation of
op_pcm_seek_page from libopusfile. This original function contained a
bug a bug caused by a non-braced if body followed by two statements that
should be conditional. Being non-braced, only the first statement was
conditional.
The bug caused previous-page buffering always to be on. Previous page
buffering is an efficiency gain for seeking to positions that are part
of a continued packet. Erroneously always turning it on prevents the
loading of the correct page at the end of the search in some conditions.
This manifested as seek-search working for some positions and not
others, depending on the order of found pages near the final target.
