This fixes compilation as C - while the source files are named
.cpp, they actually are compileable as pure C. Prior to this,
this table produced multiple definitions of the same symbol.
This was committed on the master branch of the opencore
repository in commit a803bd49a631317e0d52ff060cf1799f7741a47e,
based on AOSP contribution 10017.
Change-Id: Id76274964242b119ab61b8181e557477df1e1521
Some of these tables exist in both the amrnb and amrwb libraries,
but with different content.
This avoids some cases of multiple definitions of symbols, if
linking in both libraries statically into the same executable,
if the libraries are built as C. (As C++, the local symbols
get mangled so they don't conflict with the external C symbols
in amrnb, that are unmangled.)
Most of this was committed on the master branch of the opencore
repository in commit 0cd4b3ac412dd0a8370ce339e89cf346c6cfe395,
based on AOSP contribution 10016.
Change-Id: I5387e699ce54a56dc43fcfa0396dee5c99280fd9
This fixes compilation as C - while the source files are named
.cpp, they actually are compileable as pure C (except for this
cast).
This was committed on the master branch of the opencore
repository in commit ae27d9b2ef68c4e6fc383a8cab93d6baa235ff6b,
based on AOSP contribution 10014.
Change-Id: I4f533313be041ad3e0a03ffc5f4207480894ddd1
This avoids warnings about an empty body in an if statement.
mem_free does the same null check, so the accidental extra
semicolon was harmless, and the whole if statement actually
is needless. But if removing the if statements, all the
other ones should be removed too, for consistency.
(This could be done as a separate change).
Change-Id: I1b6064dedd15ffa949043bb5396148aaed9b43f6
The arm specific functions are implemented in .s files,
without any function declarations in headers.
This fixes compiler warnings about implicit declarations
of these functions.
Change-Id: I1512560b6740c1879f378886e05aaad2e3a6c869
Since the Length field is unsigned, the comparison will always
be false. The corresponding code in the aac encoder doesn't have
any check for Length.
This avoids a warning about comparison always being false.
Change-Id: I57c28ff9d09cb9ac4effeaeb40db608ab976acc6
* commit 'ea227787253e29da2d688399b097e05708d3bf73':
stagefright amrnb: Properly negate all values
stagefright amrnb: Fix a bug on architectures where long is 64 bit
normFactor is calculated using the saturating L_add function,
but if the value added (*psfbPeFactors) is negative, the sum
can end up negative.
*psfbPeFactors can end up negative if redThrExp is less than
*psfbNActiveLines.
In cases where *psfbPeFactors ended up negative, normFactor
became INT_MIN, causing division by zero later.
Change-Id: I00c852e457b22f7eef4d6ed1887629828057206b
In rare cases, the result of normFactor * (*psfbNActiveLines)
could be zero, leading to a division by zero in pow2_xy.
In these cases, normFactor was INT_MIN, and if *psfbNActiveLines
was 2, the product was zero.
normFactor being INT_MIN is a bug in itself though.
Change-Id: Ib31bf02889615a7be3bd1bc028da8a7651a8dbee
Previously, if bits above the lowest noBitsToWrite were
set, they would be ORed into the previous cache word,
setting unrelated bits erroneously.
This doesn't noticeably affect the performance of the
codec as a whole.
Change-Id: Ie9935533c4299b8f07cb14485f039a9be9c84016
For GCC, all of inline, __inline and __inline__ work fine.
For MSVC, only __inline works. (__inline should also be accepted
by RVCT.)
Change-Id: Ifbb1c848b200a8c4080624a3d3bd8b6ee498edb2
