Finally! Catches hard-to-find errors like this:
- const SortedArrayOf<SVGDocumentIndexEntry> docs = this+svgDocEntries;
+ const SortedArrayOf<SVGDocumentIndexEntry> &docs = this+svgDocEntries;
We implement this for our array types. This, in turn, trickles down
into all types that embed the arrays. So, as long as we define all
open-ended structs in terms of Array types (all can be done using
UnsizedArrayOf), this achieves the goal of making uncopyable all
structs that are variable-sized. Yay!
Doesn't work though, ouch :(. Need to figure out if it's unreasonable
to expect Null(T) inside hb_array_t<T> to see the later specialization
of Null for NameID.
COLR table has one function: return layers for a glyph, and we expose exactly
that, so should just wire it through. Also use sub_array() for verifiable
safety.
Also, BaseGlyphRecord's null object is enough. We don't need to special-case
the not-found.
Some clang versions define static_assert as a macro apparently, so we cannot
redefine it...
This reverts commit 94bfea0ce6.
This reverts commit 4e62627831.
...like UnsizedArrayOf<>.
This fixes a class of crasher bugs, mostly with color and AAT tables. We
cannot use nullable offsets to varsized data that does not declare min_size,
because it's nost safe to use our fixed-size null pool for types that have
their size external. So, use non_null'able offsets for these.
A further enhancement would be to make use of min_size in Null<> itself.
Will try that after.
Previously, ResourceForkHeader was defined as 30 bytes, having the typeCountM1 as last member.
There was a mysterious offset-by-2 in the code, derived from FontTools and JDK code this was
ported from.
In testing, I observed that typeListZ offset is actually 28. Suggesting that the typeCountM1
does NOT actually belong to ResourceForkHeader, but belongs to the array itself. Adjusting for
that resolves the mystery +2 offset hack, so everything is clean and good now.
This, concludes my dfont hacking. The code looks great now, and I'm happy to leave it.
Fuzzers might disagree though, we will see!
Behdad Esfahbod
Ebrahim Byagowi