When two tests share a temporary filename they can cause ctest to fail
when run in parallel mode since both would attempt to operate on the
same file if scheduled to run at the same time.
To fix this, filenames in the smaller tests have been individually
renamed, and for the bigger tests a prefix has been added to make them
unique.
The complete list of conflicting filenames (which were then manually
inspected) was generated by running the following command in 'tests':
for file in $(grep -hoER \"\\w+\\.\\w+\" | sort | uniq -d)
do echo $file
grep -Rn $file
echo
done | less
'blockalign' is the size of a block, and each block contains 7 samples
per channel as part of the preamble, so check against 'samplesperblock'
rather than 'blockalign'. Also add an additional check that the block
is big enough to hold the samples it claims to hold.
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26803
The SF_CART_INFO_16K struct has an additional 4 byte field to hold
the size of 'tag_text' which the file header doesn't, so don't
include it as part of the check when looking for the max length.
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26026
This is an internal change to unify and simplify the handling of file
paths.
On the Windows platform, the file path is always converted to UTF-8 and
converted to UTF-16 only for calls to WinAPI functions.
The behavior of the functions for opening files on non-Windows platforms
does not change.
Use standard `_WIN32` define instead. Any sane compiler on Windows
platfrom defines `_WIN32`.
The `wpath` parameter type has been changed to an equivalent type that
does not require the inclusion of the `windows.h` header.
Improve granule position calculation, centralising logic in one
function, adding warning messages for malformed data conditions and
commenting about corner and degenerate cases.
Previously the vorbis_seek function did not take the lapped nature of
Vorbis block into account when using the bisection search.
Also, introduce vorbis_skip(), which can skip through packets without
having to decode all the way to samples.
Without this the client gets the message "Not a valid error number
(666)" printed to stdout, which doesn't explain what the issue is.
These were found via fuzzing where the fuzzer was spamming these
messages.
This was causing an infinite loop on malformed input generated by
fuzzing.
Note that jumping backwards to the previous 4 byte aligned offset also
resulted in the same infinite loop since psf_ftell() was returning an
offset ending in 0xf.
The loop in wavlike_ima_decode_block() that pulls apart the nibbles
assumes that there's 8 nibbles worth of data for every channel, so
rather than adding a branch in the hot path I've opted for allocating
slightly more than we might need.
This was a blocker caught by fuzzing locally.
This also appears to be the same crash as
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25530.
1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
3. Do not end the subject line with a period
4. Use the imperative mood in the subject line
5. Wrap the body at 72 characters
6. Use the body to explain what and why vs. how
* Fix warnings about incorrect format specifiers.
GCC only wants to see void pointers for %p formatters, so cast as appropriate.
* Fix a warning about an invalid enum value.
The following warning was observed when compiling with -pedantic:
warning: ISO C restricts enumerator values to range of 'int' (2147483648 is too large)
The values of these enums don't escape wav_read_header() and are only used to set bits in a bitmask, so simply use the next bit rather than jumping to a huge number.
* Give anonymous unions a name.
This fixes the 'anonymous unions are a C11 extension' warning when compiling with -pedantic.
* Use flexible array members rather than zero sized arrays.
This flagged up the following warning when compiling with -pedantic:
warning: zero size arrays are an extension [-Wzero-length-array]
* Safely return the smallest value of a short.
GCC gives the following warning when compiling with -pedantic:
warning: overflow in conversion from 'int' to 'short int' changes value from '32768' to '-32768' [-Woverflow]
This looks intentional from the surrounding code, so return -32768 in a legal way rather than depending on undefined behaviour.
* Use the same min/max approach with all compilers.
The GCC specific code gives the following warning from GCC when compiled with -pedantic:
warning: ISO C forbids braced-groups within expressions [-pedantic]
This code was also a fundamentally different way of calculating min/max since it didn't evaluate the inputs more than once, which meant there was potentially a difference in behaviour when the library was built with different compilers if the evaluation of 'a' or 'b' had side effects.
* Use the correct scale when normalising an integer read on the fallback floating point path.
Without this the values were only being scaled to a short's max value.
* Add a second pass over the floating point tests that enables the replacement read functionality.
These cover the issue fixed by the previous commit.
* Add an entry to CHANGELOG.md for #702.
