The fact that HB_AUTO_RETURN will return rvalue-references for rvalues
is very disturbing.
Even apart from that, I'm totally lost re any hb_move needs or
hb_forward'ing to functions/templates where the type is fixed by
explicitly specifying template parameters.
==1==ERROR: AddressSanitizer: stack-use-after-return on address 0x7f6ad65e51e0 at pc 0x0000005da240 bp 0x7ffc104ab670 sp 0x7ffc104ab668
READ of size 4 at 0x7f6ad65e51e0 thread T0
SCARINESS: 55 (4-byte-read-stack-use-after-return)
#0 0x5da23f in bool OT::Coverage::serialize<hb_map_iter_t<hb_map_iter_t<hb_filter_iter_t<OT::Coverage::iter_t, hb_set_t const&, $_7&, (void*)0>, OT::SingleSubstFormat1::subset(hb_subset_context_t*) const::'lambda'(unsigned int), (hb_function_sortedness_t)1, (void*)0>, $_20&, (hb_function_sortedness_t)1, (void*)0>, (void*)0>(hb_serialize_context_t*, hb_map_iter_t<hb_map_iter_t<hb_filter_iter_t<OT::Coverage::iter_t, hb_set_t const&, $_7&, (void*)0>, OT::SingleSubstFormat1::subset(hb_subset_context_t*) const::'lambda'(unsigned int), (hb_function_sortedness_t)1, (void*)0>, $_20&, (hb_function_sortedness_t)1, (void*)0>) harfbuzz/src/hb-ot-layout-common.hh:1055:16
#1 0x5d88f9 in bool OT::SingleSubstFormat1::serialize<hb_map_iter_t<hb_map_iter_t<hb_filter_iter_t<OT::Coverage::iter_t, hb_set_t const&, $_7&, (void*)0>, OT::SingleSubstFormat1::subset(hb_subset_context_t*) const::'lambda'(unsigned int), (hb_function_sortedness_t)1, (void*)0>, $_20&, (hb_function_sortedness_t)1, (void*)0>, (void*)0>(hb_serialize_context_t*, hb_map_iter_t<hb_map_iter_t<hb_filter_iter_t<OT::Coverage::iter_t, hb_set_t const&, $_7&, (void*)0>, OT::SingleSubstFormat1::subset(hb_subset_context_t*) const::'lambda'(unsigned int), (hb_function_sortedness_t)1, (void*)0>, $_20&, (hb_function_sortedness_t)1, (void*)0>, unsigned int) harfbuzz/src/hb-ot-layout-gsub-table.hh:98:9
Both to save ops, and also because lambdas don't implement operator!=,
so this was failing in range-based for loop if a lambda was passed to
hb_map() or hb_filter(). Just check end-condition assuming that we
are comparing to .end() or iterators that are otherwise derived from
current iterator. Ie. don't compare things that are expected to be
in common.
Apparently there's different overload resolution rules that apply, at
least with some (older?) version of gcc.
hb-ot-name-table.hh: In member function ‘void OT::name::accelerator_t::init(hb_face_t*)’:
hb-ot-name-table.hh:244:62: error: ambiguous overload for ‘operator+’ (operand types are ‘hb_blob_ptr_t<OT::name>’ and ‘OT::NNOffsetTo<OT::UnsizedArrayOf<OT::IntType<unsigned char, 1u> > > {aka const OT::OffsetTo<OT::UnsizedArrayOf<OT::IntType<unsigned char, 1u> >, OT::IntType<short unsigned int, 2u>, false>}’)
this->pool = (const char *) (const void *) (this->table+this->table->stringOffset);
^
hb-ot-name-table.hh:244:62: note: candidates are:
hb-ot-name-table.hh:244:62: note: operator+(const C*, long int) <built-in>
hb-ot-name-table.hh:244:62: note: operator+(const char*, long int) <built-in>
Behdad Esfahbod
Garret Rieger
David Corbett
Ebrahim Byagowi
Qunxin Liu
Dominik Röttsches