Unlike OPUS_SET_INBAND_FEC(1), the encoder does not necessarily
switch to SILK if we have music.

clang -Wcast-align warnings with ambisonics enabled
clang -Wnull-pointer-arithmetic warnings in test_opus_api.c
gcc -Wimplicit-fallthrough warnings on arm
msvc warning C4244 in celt_encoder.c with fixed point

Felicia Lim authored 8 years ago and Jean-Marc Valin committed 8 years ago

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

We were previously returning OPUS_BAD_ARG because the failure was
only detected in opus_repacketizer_out_range_impl() rather than in
opus_repacketizer_cat(). Checking the return value from opus_repacketizer_cat()
also addresses the last outstanding Coverity defect.

In glib 2.17 the __malloc_ptr define was removed in favour
of using void* directly. Our declaration of mhook using this
type for the second argument therefore rightly generates a warning
on modern systems, since the type is assumed to be an int, which
is too narrow to hold a pointer on 64 bit architectures.

Since it was only ever a define we could use an #ifndef to define
__malloc_ptr ourselves. However we only use it once, so using void*
in the signature directly is cleaner. This should cause no problems
on older systems where it will match either the void* or the char*
(for non __STDC__ code) the define resolved to.

Also makes the CTL bad argument handling more consistent to avoid mistakes
 like that in the future.  Also updates the variable duration docs.

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.

Philip Jägenstedt authored 12 years ago and Gregory Maxwell committed 12 years ago

I stumbled upon the typo in README.draft, so took the opportunity to
grep for common misspellings using List_of_common_misspellings.txt for
hunspell.

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.

This CTL was requested by Nicolas George for FFmpeg.

Gregory Maxwell authored 12 years ago and Jean-Marc Valin committed 12 years ago

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.

This reverts commit 9f407afa.

Also added 3rd clause to "master" COPYING file

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.

Files are already compiled with -I./include, the relative
path in the #include line isn't necessary.

Our arch.h makes sure it's always defined. Thanks to derf
for the suggestion.

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.

These pragmas were adding in 4.6, and earlier versions warn
about them being undefined.

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.

This just works around the deprecation in glibc 2.14. I
do worry what will happen if they follow through and
remove it in 2.15.