Unbreaks test builds on this service.

The Visual Studio build of the ogg library was changed
recently to build static libraries by default, and the
`_static` name suffix was removed. Reference this target
when building the ogg library debpendency from a git
checkout on the Appveyor continuous integration service.

Signed-off-by: Mark Harris <mark.hsj@gmail.com>

Recently the ogg reference library Visual Studio build was
updated to produce static libraries by default and the
`_static` filename suffix was removed.

This makes the corresponding change to the dependency
in opusfile's Visual Studio project files for the
example client executables. Linking against a new-style
ogg build is now required.

Signed-off-by: Mark Harris <mark.hsj@gmail.com>

 src/opusfile.c:3242:18: warning: implicit conversion from 'unsigned
       int' to 'float' changes value from 4294967295 to 4294967296
       [-Wimplicit-int-float-conversion]
           r=seed*OP_PRNG_GAIN;
                  ^~~~~~~~~~~~
 src/opusfile.c:3179:29: note: expanded from macro 'OP_PRNG_GAIN'
 # define OP_PRNG_GAIN (1.0F/0xFFFFFFFF)
                            ~^~~~~~~~~~

The ftime() function, introduced in V7 Unix (1979), gets the current
time in seconds and milliseconds, and time zone information.  It was
marked as a legacy interface in POSIX.1-2001, and removed altogether
from POSIX.1-2008.  The gettimeofday() function, originally from
4.1 BSD, gets the current time in seconds and microseconds, and optional
time zone information, and was marked as obsolete in POSIX.1-2008
although it was kept in the standard.  The POSIX recommended function
for getting time with sub-second resolution is clock_gettime(), which
was introduced in POSIX.1b-1993 and is now part of the base POSIX
standard; it supports multiple clocks and nanosecond resolution.
Additionally the function timespec_get() was introduced in C11 and also
supports nanosecond resolution.

To support dates beyond the year 2038, glibc and other libraries are
being updated to support 64-bit time_t even on 32-bit architectures,
requiring new implementations of interfaces that work with time.  As
part of this effort, the ftime() function was deprecated in glibc 2.31
(released February 1, 2020), a warning is now issued when building code
that uses this function, and removal is planned for a future version of
glibc (https://sourceware.org/pipermail/libc-announce/2020/000025.html).

ftime() is used in http.c to measure time intervals with millisecond
resolution.  To avoid the glibc 2.31 deprecation warning and further
issues when the function is removed entirely from glibc, clock_gettime()
is now used instead when it is available in the C library, as it is on
current Linux systems.  Prior to glibc 2.17, clock_gettime() required
linking with librt; on such systems ftime() will continue to be used, to
avoid an additional library dependency.  macOS provides clock_gettime()
starting in macOS 10.12; earlier versions will continue to use ftime().
Windows provides ftime() but not clock_gettime(), so ftime() will
continue to be used on Windows.

ftime(), gettimeofday(), and clock_gettime() with the CLOCK_REALTIME
clock get the "real time", which is subject to jumps if set by an
administrator or time service.  The CLOCK_MONOTONIC clock does not have
this problem and is more suitable for measuring time intervals.  On
Linux, the CLOCK_BOOTTIME clock measures the time since last boot and is
the same as CLOCK_MONOTONIC except that the Linux CLOCK_MONOTONIC clock
does not advance when the system is suspended.  Because it is used to
measure time intervals, CLOCK_BOOTTIME or CLOCK_MONOTONIC are used when
available, when clock_gettime() is used.  However the only clock
required by POSIX.1-2008 is CLOCK_REALTIME, so that will be used if the
other clocks are not available.

Chris Lamb authored 7 years ago and Mark Harris committed 4 years ago

Fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881788

It is possible for us to buffer multiple out-of-sequence pages with no packets
 on them before getting one that does have packets.
In this case, libogg will report each hole in the page sequence numbers
 separately.
Since we were only checking for the actual packets once after encountering a
 hole, if the total number of holes was even, we could exit
 op_fetch_and_process_page() with valid packets still in the libogg buffer.
Then, if the next page had a lot of packets, we might wind up with a total of
 more than 255 of them, overflowing our stack buffer for their durations.
That's bad.

Instead, make sure we always drain all hole reports from libogg any time we
 encounter one, to ensure we get the actual packets behind it.

Thanks to Felicia Lim for the report.

The C standard says that calling library functions (including
 memcpy) with invalid arguments (including a NULL pointer) is
 undefined behavior unless otherwise noted (which memcpy doesn't).
op_filter_read_native() invokes op_read_native() with NULL for the
 _pcm buffer, which triggers such a memcpy invocation.
Even though it should be perfectly fine in practice to pass NULL to
 memcpy when copying zero bytes, don't do it.

Thanks to a person who did not wish to be credited for the report.

The seeking functions on Windows internally dispatch to
 SetFilePointer(), whose behavior is undefined if you do not call
 it on "a file stored on a seeking device".
Check the type of file when it is opened and manually force seeks
 to fail if we do not have such a file.

Thanks to L W Anhonen for the report and Mark Harris for pointing
 out the solution used by opus-tools to avoid this problem.

When seeking using SEEK_END, the win32-specific implementation of
 op_fseek() would add the offset to the file size to get the
 absolute seek position.
However, op_mem_seek() and op_http_stream_seek() would subtract the
 offset instead.
The documentation of fseek() is not at all clear which behavior is
 correct, but I believe that the op_fseek() behavior is.

This inconsistency didn't matter for opusfile in practice, because
 we only ever use SEEK_END with an offset of 0.
However, the user can also open files with our API and use the
 resulting callbacks for their own purposes, so it would be good to
 be consistent for them.

Thanks to a person who did not wish to be credited for the report.

Stefan Strogin authored 6 years ago and Ralph Giles committed 6 years ago

LibreSSL is not yet fully API compatible with OpenSSL 1.0.2 and later,
However many APIs from OpenSSL 1.0.2 and 1.1 are already implemented in
LibreSSL 2.7.0 and later. Old approach works in newer LibreSSL version
as well, but it's not nice to force deprecated functions on LibreSSL
users.

Add additional conditionals for new LibreSSL versions to use the
available new APIs.

Signed-off-by: Ralph Giles <giles@thaumas.net>

Stefan Strogin authored 6 years ago and Timothy B. Terriberry committed 6 years ago

LibreSSL defines OPENSSL_VERSION_NUMBER to 0x20000000L, but its API is
compatible with OpenSSL 1.0.1.
Therefore redefine OPENSSL_VERSION_NUMBER to 0x1000115fL (1.0.1u) if
LibreSSL is used.

Fixes: #2327

I'm sure we'll run into this again.

New upstream release (soon to be final).

Fleshed out/clarified some steps from the experience of making the
 0.11 release.

This is the current stable release. The fedora:25 image is no longer
receiving updates.

New upstream release.

New upstream release some time ago.

Mark Harris authored 6 years ago and Timothy B. Terriberry committed 6 years ago

The comment must be just before the label to suppress the warning.

Mark Harris authored 6 years ago and Timothy B. Terriberry committed 6 years ago

Silence warning: Value stored to 'comment_lengths' is never read

Ricardo Constantino authored 7 years ago and Timothy B. Terriberry committed 7 years ago

Will be useful for opus-tools

James Zern authored 7 years ago and Timothy B. Terriberry committed 7 years ago

Check for overflow with a negative diff.

Signed-off-by: Timothy B. Terriberry <tterribe@xiph.org>

James Zern authored 7 years ago and Timothy B. Terriberry committed 7 years ago

Calculate discard_count directly with op_granpos_diff. this works
because _pcm_offset == (target_gp - pcm_start) and diff == (gp -
pcm_start).

Signed-off-by: Timothy B. Terriberry <tterribe@xiph.org>

Pavel P authored 7 years ago and Ralph Giles committed 7 years ago

Signed-off-by: Ralph Giles <giles@thaumas.net>

Improve coverage by building more variants in integration
testing.

There's no equivalent of the apt addon for macOS builds, so
we put dependencies in Brewfile and call `brew bundle` to
install them. This works better than calling `brew install`
directly since the later will error if a package is already
installed, and even if the error is ignored it won't update
to the latest version available, resulting in binaried built
against e.g. vulnerable versions of openssl.

To avoid conflicts with Apple's deprecated openssl package,
homebrew doesn't install its openssl package in the default
search path, so we need to manually append the its location
to PKG_CONFIG_PATH. We cannot build against Apple's package
because while it provides libraries and an openssl.pc file,
no headers are available.

Signed-off-by: Ralph Giles <giles@thaumas.net>

Ubuntu 14.04 (trusty) is the current default, so we don't need to specify.

Using the apt addon means we no longer need sudo access.

Signed-off-by: Ralph Giles <giles@thaumas.net>

We very carefully ensured _cur_link + 1 was in bounds, and then
 dereferenced nlinks + 1 (guaranteed to be out of bounds) instead.
Introduced in commit f83675eb.

Thanks to the Google Autfuzz project for the report.

Fixes #2326

New release of the codec reference implementation.

op_fopen() and op_freopen() declare these arguments as non-NULL,
 so when building with mingw, the compiler reasonably complains
 when we check to see if they're NULL.
We could remove the OP_ARG_NONNULL tags, but the behavior of
 _wopen/_wfreopen appears to be to crash on NULL for either
 parameter.
On Linux, the behavior appears to be to handle a NULL path (fopen
 returns NULL with errno set to EFAULT, and freopen returns the
 passed FILE * with errno set to EFAULT), but crash on a NULL mode.
Keeping the OP_ARG_NONNULL tags promises that passing NULL results
 in undefined behavior, which is at least consistent with the
 behavior being different on different platforms.
It's also consistent with the ABI promises of previous releases,
 which compilers linking against libopusfile might have taken
 advantage of.

The return type of op_serialno changed from ogg_uint32
to opus_uint32, but those types should be abi compatible.

New release of the codec reference implementation.

downloads.xiph.org recently got https support.