Fuzzer caught it:
==14==ERROR: AddressSanitizer: stack-use-after-return on address 0x7fca2ed7a3e0 at pc 0x0000006057aa bp 0x7ffc3290f1d0 sp 0x7ffc3290f1c8
READ of size 4 at 0x7fca2ed7a3e0 thread T0
SCARINESS: 55 (4-byte-read-stack-use-after-return)
#0 0x6057a9 in OT::SingleSubstFormat2::subset(hb_subset_context_t*) const /src/harfbuzz/src/./hb-ot-layout-gsub-table.hh:194:40
#1 0x5ff921 in hb_subset_context_t::return_t OT::SingleSubst::dispatch<hb_subset_context_t>(hb_subset_context_t*) const /src/harfbuzz/src/./hb-ot-layout-gsub-table.hh:256:13
I can't reproduce locally, but many of the bots are failing because of this
as well.
It's a pity that operator-> must return pointer. Ugh. Why?!
Not sure why I don't get it, but this warning:
warning: base class ‘struct hb_iter_fallback_mixin_t<hb_array_t<const OT::UVSMapping>, const OT::UVSMapping&>’ should be explicitly initialized in the copy constructor [-Wextra]
The mystery failure had to do with SFINAE failure because the template
function involved was accessing ::iter_t of a type that was also named iter_t.
In this context, apparently:
warning: ISO C++ specifies that qualified reference to 'iter_t' is a
constructor name rather than a type in this context, despite preceding 'typename' keyword
[-Winjected-class-name]
We use a new macro, also called hb_iter_t(), to get iterator type of
a type. This uses declval/hb_decltype, and has the added benefit
that it returns correct type for const vs non-const objects, if they
have different iterators.
It was only used for C++<11 which does not allow default parameters
in function templates. Looks like we cannot support <11 anyway, so,
start cleaning up.
Fix ambiguity of hb_sorted_array_t::item_t with gcc. No idea if that's a gcc bug
or what spec requires, but using aliasing using seems to fix it. It probably breaks
our non-C++11 bots, in which case I have to condition the change. Testing.
Behdad Esfahbod
Behdad Esfahbod