As reported by Mark Warner opus_multistream_*_create were depending on
the behavior of malloc(0) in order to correctly report some kinds of
argument errors. Bad arguments could be incorrectly reported as
allocation failures. This changes multistream to explicitly check the
arguments like the single stream _create functions. The unit tests were
enough to catch this on systems where malloc(0) returns NULL but didn't
catch it on other systems because the later _init call would catch the
bad arguments and trigger the correct error if and only if the malloc
didn't return a null pointer.
In multistream_encoder_init failures of the internal non-multistream
init calls were not being caught and propagated. Decode didn't have
this problem. This propagates the errors and adds additional tests
(the multistream encoder api is sill under tested) that would have
detected this error.
Plus add some stronger tests for things like error==NULL for the _create
functions that take a pointer for error output.
The last commit changed some of the multistream tests to use a
dual-mono setup instead of a single-stereo setup. Some of the
accompanying explicit valgrind checks were still setup to
look for stereo streams.
In places where an ignored return or a null-arg is a sure indication
of a bug add the GCC warning attributes. The null arg annotation
is not enable for Opus itself because it will cause the compiler
to optimize out some null checks. I don't trust our callers
quite that much.
Multistream encode was failing to add the length of the extra length for
self-delimited packets causing corrupted output. Multistream decode was
not properly handling lost frames (and potentially reading out of bounds
as a result).
GET_FINAL_RANGE has been implemented as the xor of the final range of all
the streams in the packet.
test_opus_encode now does the mono narrowband tests using dual-mono
multistream.
We use the __GNUC_PREREQ macro from celt/arch.h to check
the required minimum gcc version. The previous check would
have failed for gcc 5.n with n from 0 to 5.
Thanks to pcgod for pointing out the problem and derf for
pointing out we had a macro for this.
This array is only used by the malloc failure test, and
defining it unconditionally creates an unused variable
warning on platforms where MALLOC_FAIL isn't set.
This test only works on glibc, but the important thing is support
for the __malloc_hook api, so that's what we should depend on,
especially since not all glibc versions have it.
The glibc 2.14 NEWS file says __malloc_hook will be removed
in the next release, so future-proof our use by checking
for this symbol at configure time and only compiling the
malloc failure tests if it is present.
