In Little Endian the vec_ld/vec_st operations work as
expected only for byte-vectors.

POWER 7 and POWER 8 support VSX and ldbrx.

POWER 8 supports additional extended VSX instructions introduced
with ISA 2.07.

Add POWER entries.

Should prevent trying to use altivec when it is disabled by the kernel.

The compiler is free to optimize such expressions in any sort of way.

OSX does not know MSG_NOSIGNAL. BSD (which OSX is based on) has got
the socket option SO_NOSIGPIPE (even if modern BSDs also support
MSG_NOSIGNAL).
Signed-off-by: Martin Storsjö <martin@martin.st>

Bug-Id: CVE-2015-3417
CC: libav-stable@libav.org

As done in msrle_decode_8_16_24_32.

Bug-Id: CVE-2015-3395
CC: libav-stable@libav.org

Don't use a PRNG for generating it; that defies the intended use
within the cryptograhic handshake.
Signed-off-by: Martin Storsjö <martin@martin.st>

There was a misunderstanding betewen bits and bytes for the parameter
value for generating random big numbers.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

This helps if these functions need to be implemented using another
crypto API.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

This was probably broken some time ago. The breakage is now part of the
ABI. For example, we have:

    AV_PIX_FMT_XYZ12BE
    AV_PIX_FMT_NV16
    AV_PIX_FMT_NV20LE

AV_PIX_FMT_NV20LE is wrong. It has the value 113, but as little-endian
format it should be even. This must have been quite obvious when these
formats were added (because of the AV_PIX_FMT_XYZ12BE entry), but
nobody cared or knew about this.

The future libavutil major bump will also break this additionally,
because disabling FF_API_VDPAU will remove an odd number of entries from
the middle of the enum.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Simplifies the code and makes it build on certain compilers
running out of registers on x86.

CC: libav-stable@libav.org
Reported-By: mudler

Such tables are not used anywhere currently, but that should change.

Code is small enough that there is no advantage in a separate function.

This fixes building with gcrypt-backed gnutls versions, broken
in 57cde2b1.
Signed-off-by: Martin Storsjö <martin@martin.st>

Silences warning(s) like:

    libavcodec/x86/fft.asm:93: warning: section flags ignored on
    section redeclaration

The cause of this warning is that because `struc` and `endstruc`
attempts to revert to the previous section state [1].

The section state is stored in the macro __SECT__, defined by
x86inc.asm to be `.note.GNU-stack ...`, through the `SECTION`
directive [2].

Thus, the `.note.GNU-stack` section is defined twice
(once in x86inc.asm, once during `endstruc`), causing the warning.

That is the first part of the commit: using the primitive `[section]` format
for .note.GNU-stack etc., which does not update `__SECT__` [2].

That fixes only half of the problem. Even without any `SECTION` directives,
`__SECT__` is predefined as `.text`, which conflicting with the later
`SECTION_TEXT` (which expands to `.text align=16`).

[1]: http://www.nasm.us/doc/nasmdoc6.html#section-6.4
[2]: http://www.nasm.us/doc/nasmdoc6.html#section-6.3Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

There is no need to have this mess in network.c.
Signed-off-by: Martin Storsjö <martin@martin.st>

Move the OpenSSL and GnuTLS implementations to their own files. Other
than the connection code (including options) and some boilerplate, no
code is actually shared.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Sebastian Ramacher <sramacher@debian.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This skips setting the memory to 0 but allows for reuse on different
contextes. Oracle did not report any unsual activity because of it.

The field is unused.

It is just a duplicate of an AVCodecContext member so use it instead.

They are just duplicates of AVCodecContext members so use those instead.

Signed-off-by: Martin Storsjö <martin@martin.st>

These aren't necessary any longer.
Signed-off-by: Martin Storsjö <martin@martin.st>