The check `src > dst' in the form `&c->out[-back] > c->out' invokes
pointer overflow, which is undefined behavior in C.
Remove the check. Also replace `&c->out[-back] < c->out_start' with
a safe form `c->out - c->out_start < back' to avoid overflow.
CC: libav-stable@libav.org
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit ca6c3f2c53)
On recent android versions, /proc/self/auxw is unreadable
(unless the process is running running under the shell uid or
in debuggable mode, which makes it hard to notice). See
http://b.android.com/43055 and
https://android-review.googlesource.com/51271 for more information
about the issue.
This makes sure e.g. neon optimizations are enabled at runtime in
android apps even when built in release mode, if configured to
use the runtime detection.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit ab8f1a6989)
Signed-off-by: Martin Storsjö <martin@martin.st>
Use this in VP8/H264-8bit loopfilter functions so they can be used if
there is no aligned stack (e.g. MSVC 32bit or ICC 10.x).
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This allows compiling optimised functions for features not enabled
in the core build and selecting these at runtime if the system has
the necessary support.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This is consistent with usual ARM nomenclature as well as with the
VFPV3 and NEON symbols which both lack the ARM prefix.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Not all versions of windows have the console color functions,
while io.h might be needed for isatty (which can be found in
unistd.h or io.h).
Signed-off-by: Martin Storsjö <martin@martin.st>
The existence of MapViewOfFile isn't linked to the existence of
io.h.
Not all versions of windows have MapViewOfFile (in particular,
Windows Phone 8 and the "metro" windows 8 API subset don't),
while they still have io.h (and need it for open/read/close).
Signed-off-by: Martin Storsjö <martin@martin.st>
Preventing the use of discouraged or 'insecure' external functions
through defines in an internal header is not a good solution. The
header is not guaranteed to be included universally which makes
overlooking bad use of said functions during review more likely.
There are cases were those functions either are the most straight
forward solution or even have to be used. Using malloc or free is
required if the allocation or release is done by other libraries.
- Add special cases for offsets of 2, 3, or 4 bytes. This means the
offset is always >4 in the generic case, allowing 32-bit copies to
be used there.
- Don't use memcpy() for sizes less than 16 bytes.
Signed-off-by: Mans Rullgard <mans@mansr.com>
