This prepares the headers for exporting symbols using visibility
attributes or __declspec(dllexport), so that we do not need to maintain
symbols listing files, as this is what was and is done in GLib and GTK+.

Add braces for subobject initializer in _hb_font_funcs_nil

The generic template operator overloading was causing more problems than it
solved.  Eg:

https://github.com/behdad/harfbuzz/pull/163
https://github.com/behdad/harfbuzz/issues/175

So, just use macros.

Fixes https://github.com/behdad/harfbuzz/issues/175
Fixes https://github.com/behdad/harfbuzz/pull/178

To avoid triggering -Wmissing-braces; see https://bugzilla.mozilla.org/show_bug.cgi?id=1226175#c8

This is just to make it harder to be extremely slow.  There definitely
are ways still, just harder.  Oh well... how do we tame this problem
without solving halting problem?!

Fixes https://github.com/behdad/harfbuzz/issues/174

This reverts commit f0599db7.

Commit abadc171 provides a better
fix for this.

This reverts commit 68b507a3.

Commit abadc171 provides a better
fix for this.

This essentially disables coverity-scan right now, until we find
a pattern to continuously submit branches there.

For background reasoning, see:
Fixes https://github.com/behdad/harfbuzz/issues/171

To fully test what these are supposed to test, they should be run
against libharfbuzz-fuzzing.la instead of libharfbuzz.la, but for
now just record the files.

If buf->idx is at end, don't set end past it...

Fixes https://github.com/behdad/harfbuzz/issues/173

Fixes assert fail in https://github.com/behdad/harfbuzz/issues/161
with libharfbuzz-fuzzing.

test/fuzzing/hb-fuzzer links against libharfbuzz-fuzzing.so now.

Update the sources so they will compile under Visual Studio

Use the DEFINE_ENUM_FLAG_OPERATORS macro in winnt.h on Visual Studio,
which defines the bitwise operators for the enumerations that we want to
mark as hb_mark_as_flags_t, which will take care of the situation on newer
Visual Studio (>= 2012), where the build breaks with C2057 errors as the
underlying types of the enumerations is not clear to the compiler when we
do a bitwise op within the declaration of the enumerations themselves.

Also disable the C4200 (nonstandard extension used : zero-sized array in
struct/union) and C4800 ('type' : forcing value to bool 'true' or 'false'
(performance warning)) warnings as the C4200 is the intended scenario and
C4800 is harmless but is so far an unavoidable side effect of using
DEFINE_ENUM_FLAG_OPERATORS.

Visual Studio does not like declaring a enum variable within a for
statement, so fix the build by declaring the enum before doing the for
loop.

Pre-2013 MSVC does not have scalbn() and scalbnf(), which are used in the
utility programs.  Add  fallback implementations for these, which can be
used when necessary.

Use the fallback implementation for lround() only on pre-2013 Visual
Studio, and ensure we are clear about the types of the parameters for
lround() and scalbnf(), since Visual Studio can be quite picky on
ambiguous parameter types.  Also, use g_ascii_strcasecmp() rather than
strcasecmp() as we are already using GLib for this code and we are
assured that g_ascii_strcasemp() is available.

For scalbnf() on pre-2013 Visaul Studio, a fallback implementation is
needed, but use another forced-included header for those compilers, which
will be added later.

Also use (char)27 on Visual Studio builds as '\e' is not a recognized
escape sequence, which will do the same thing.

Micro optimizations to UTF-16 and UTF-32 codecs

Err on the side of being too short, than too wide.  Reduces chance
of overlaps with neighboring glyphs.

Addresses
https://github.com/behdad/harfbuzz/commit/6e6f82b6f3dde0fc6c3c7d991d9ec6cfff57823d#commitcomment-14248516

This reverts commit f92bd86c.

We don't want to be like cairo, where as soon as there's an error,
nothing works anymore.  So, lets process lookups as long as there's
no new memory needed.  That's also a model that hides fewer bugs.

Implement reverse lookup instead of re-using next()

From https://github.com/behdad/harfbuzz/issues/161

Fixes https://github.com/behdad/harfbuzz/issues/161

https://github.com/behdad/harfbuzz/issues/161

https://github.com/behdad/harfbuzz/issues/139#issuecomment-154202645

The feature is enabled for any character in the Arabic shaper.
We should experiment with using it for Arabic subtending marks.
Though, that has a directionality problem as well, since those
are used with digits...

Fixes https://github.com/behdad/harfbuzz/issues/141