We were attempting to ensure a minimum spacing between granule
 positions when guessing the start of a link location.
However, we took a strictly-positive granule position, added a
 fixed increment with op_granpos_add(), and checked if
 op_granpos_add() failed.
op_granpos_add() only fails if the sum would have overflowed past
 zero, which can never happen when adding two strictly positive
 granule positions.
Instead, we need to check if the result becomes negative (which is
 a legal granule position, but violates our assumptions in the
 search).

Thanks to Felicia Lim for the report.

Prefer the secure protocol by default. We do not update schema
links since they're often standardized with protocol included.

Note that the link to the Windows certificate store patch
in the openssl.org bug tracker requires a login now.

Use a secure link by default. Drop the redundant www subdomain
to keep within the 70-column width of the header.

Replace broken link to jenkins build of the opus api docs
with the current release on the website.

Fix broken links into the vorbis spec.

Update other links to use https.

No interface changes.

Not harder to read in a editor, and looks better in the web
interface.

These make for a nicer landing page for people coming from
the gitlab repo interface on the web. They parallel github
in that we can't override the git snapshots labelled as
'source' but we can link to packages.

We keep checksums of the release packages in the repo as a
redundant and trustworthy reference.

Update the build environment container to use the gitlab.xiph.org
url instead of the no-longer-available git.xiph.org.

This is faster. We still don't have good dependency tracking
among the components, but roughly:

    make
    make opusfile-0.dll
    make package

Should automate the basics of putting together a win32 binary
package. It still doesn't include documentation. See the
mingw/README for additional steps there.

Also, don't copy dll.a files. They don't seem to be necessary.

Invoking ../configure from the mingw directory would clobber
the mingw-specific Makefile, which is confusing. Instead
have the `make opusfile` target invoke the autotools build
within a subdirectory.

Download the most recent working release of openssl.
- Enable asm, since it seems to work now.
- Link ssl and crypto libraries statically, since the
  dll target seems to be broken.

The 1.0.2 series of openssl releases is no longer supported.
However, 1.1.1 and later broke the hooks we were using to
reference the Windows certificate store, so this is also
the newest release where opusurl works.

As such, this shouldn't be used in production (unless you have a
support contract for openssl!) but it's a useful reference
configuration to have in the repository.

Hopefully a replacement api will be available in openssl 3 or 4
and we can port to that for future releases.

This seems to have changed to be more like the unix build.
We'll probably need libcrypto-1_1.dll too, but I haven't
gotten to the link step yet. This fails because of api
changes between (no longer supported) 1.0.x versions
and the current stable 1.1.

This was a reference from an older build script and it no longer
necessary. Having in the Makefile just confuses things.

We had a request for 64-bit Windows binaries at some point, but
win32 is more broadly compatible. Since everything's broken,
let's concentrate on that and add rules to generate a separate
opusfile-${version}-win64 package later.

Latest release versions and checksums.

This is the current release.

The gcc runtime dll filename has changed, so the package script
is also updated.

In theory `mingw/Makefile` can build a binary release, but
it doensn't quite works and omits some niceties, so we still
need the detailed build instructions to compare with.

However, the details aren't relevent to the general release
checklist, so pretend `make -C ming package` works at that
level.

Also convert the mingw README to markdown for better
display on hosting sites.

Documentation should be copied to the website as part of the
source release process, not building win32 binaries.

https://github.com/doxygen/doxygen/issues/6456 is fixed in
Doxygen 1.8.15. Update teh release checklist to reflect this

Thanks to derf for checking this.

Specify an explicit version of the base container image for more
repeatable results. Note that this will need to be bumped periodically.

Signed-off-by: Marvin Scholz <epirat07@gmail.com>

Verify the stand-along Makefile for formatting the API documentation.

We ship a default Makefile which can be used to invoke doxygen
to format the API documentation outside of the autotools build,
which requires implementing subsitition of the appropriate
variables in Doxyfile.in.

This commit adds a missing substitution, telling doxygen to
expect `dot` from the graphviz package to be available.

Ensure test coverage for the non-autotools makefile. This is
much faster than the autotools build, but doesn't currently
support tests or a `dist` target.

The syntax of the travis-ci.org build description file makes
it tedious to add alternate build types. It's much easier with
gitlab, so it's nice to have testing outside of jenkins.

Set up a basic autotools job to run on gitlab's continuous
integration runner, so we get some feedback on commits to
that repository.

The actual guarantees we are making in op_read_native() are:
- if _pcm == NULL, then _buf_sz <= 0 (requirement on the caller),
- op_get_packet_duration() will succeed and return a positive value
   no larger than 120*48 (guaranteed by op_collect_audio_packets()
   filtering out any packets with invalid TOC sequences), and
- nchannels is a small number greater than 0 (guaranteed by the
   validation in opus_parse_head()).
However, trying to assert these things is not enough to convince
 clang to take the nsamples*nchannels>_buf_sz or
 duration*nchannels>_buf_sz branches when _pcm==NULL, so instead
 we have to be a bit more direct.

There really isn't anything that guarantees we can find timestamps
 within the bounds of the link, or within 2 billion samples of the
 target, if people resort to nasty things like swapping out all of
 the underlying file data on us at the right moment.
Reported by clang's static analysis in
 https://github.com/xiph/opusfile/issues/16

Thanks to kcgen for filing the report.

Reported by clang's static analysis in
 https://github.com/xiph/opusfile/issues/16
This would have taken about 22 TB of junk data before the first
 decoded sample to trigger, so not very likely to occur in
 practice.

Thanks to kcgen for filing the report.

Bump the base image for macOS travis builds to XCode 11.3 on
macOS 10.14. This have more up-to-date software than the
default image, which is conservative.

The downside is that this version will need to be bumped periodically.

Use the declarative support for installing packages from
homebrew on the travis-ci.org continuous integration service
macOS images, rather than conditional shell.

This also removes the `brew update` step. There's support
for that as well with the `update: true` key-value pair,
but since travis doesn't update their images often, the
base set of homebrew packages is often very out of date,
and the corresponding update step can take a very long time.

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.