Previously we were setting refcount of freed objects to the inert value, which
was harmful because it caused further destroy()s of the freed object to NOT
call free() and hence hide the bug. Indeed, after eb0bf3ae66 test-object
was double-free'ing objects and this was never caught on Linux. It only was
caught as crashing on Mac.
Now we poison refcount upon freeing and check that it's valid whenever reading
it. Makes test-object fail now.
s/atomic_int/atomic_int_impl/ and s/atomic_ptr/atomic_ptr_impl/
to bring it in par with hb_mutex_impl_t, then re-introduce
hb_atomic_int_t as a wrapper around hb_atomic_int_impl_t.
In hb_reference_count_t, make it clear the non-atomic get and set
are intentional due to nature of the cases they are used in
(comparison to -1 and the debug output/tracing).
This was causing all object types to be non-POD and have static
initializers. We don't need that!
Now, most nil objects just moved from .bss to .data. Fixing for that
coming soon.
According to Tom Hacohen this was breaking build with some compilers.
In file included from hb-buffer-private.hh:35:0,
from hb-ot-map-private.hh:32,
from hb-ot-shape-private.hh:32,
from hb-ot-shape.cc:29:
hb-object-private.hh: In constructor '_hb_object_header_t::_hb_object_header_t()':
hb-object-private.hh:97:8: error: uninitialized const member in 'struct hb_reference_count_t'
hb-object-private.hh:51:25: note: 'hb_reference_count_t::ref_count' should be initialized
In file included from hb-ot-shape.cc:33:0:
hb-set-private.hh: In constructor '_hb_set_t::_hb_set_t()':
hb-set-private.hh:37:8: note: synthesized method '_hb_object_header_t::_hb_object_header_t()' first required here
hb-ot-shape.cc: In function 'void hb_ot_shape_glyphs_closure(hb_font_t*, hb_buffer_t*, const hb_feature_t*, unsigned int, hb_set_t*)':
hb-ot-shape.cc:521:12: note: synthesized method '_hb_set_t::_hb_set_t()' first required here
So, apparently there's no atomic int 'get' method on Apple. You have to
add(0) to get. And that's not const-friendly. So switch inert-object
checking to a non-atomic get. This, however, is safe, and a negligible
performance boost too.
The Win32 definitions for LONG, ULONG, etc conflicts with
hb-open-type.h. Avoid that by making sure hb-object-private.h
and hb-open-type.h are not included in the same compilation unit.
Behdad Esfahbod
Konstantin Ritt