Composite glyph collection was happening along side colrv0 glyph collection which meant it was possible to miss grabbing the component glyphs for a glyph added by colrv0.
If a struct had (because it's a union) sizeof that is larger than the null_size,
we were providing only null_size bytes for its Null object. We know we'd never
access beyond that, but is undefined-behavior nonetheless according to the
standard.
The alternative fix would have required use of flexible-arrays, which are not
standard and have their own issues in various compiler. We've discussed that
extensively in the follow Mozilla issue (currently locked; I've asked that it
be opened):
https://bugzilla.mozilla.org/show_bug.cgi?id=1577584
Part of
https://github.com/harfbuzz/harfbuzz/pull/2067
improve comments to reflect that:
ccc 18 includes both "flavors" of qamats: qamats [gadol] and qamats qatan
ccc 19 includes both "flavors" of holam: holam [not haser for vav] and holam haser for vav
This code and its comments may have been written before these code points were added to Unicode.
I.e. originally, these comments may have been complete, but they may have become incomplete in the meantime.
Refactor Anchor to have a subset method instead of copy. This also allows
use to use serialize_subset in several places which simplifies calculating
offset bases.
Counting bytes as the operations is likely to be a better proxy for how
much work processing the table will cost vs. the current approach of
counting the number of sub-objects.
This should allow checks for max features, max scripts, etc. to be removed.
I tested this change against the full collection of fonts at https://github.com/google/fonts
and a max ops factor of 3 was sufficient to successfully sanitize all of them.
Currently config-override.h is included at the end of this file. This caused a problem for me while undefing HB_DISABLE_DEPRECATED, namely HB_IF_NOT_DEPRECATED was defined before actual undef took place and broke the whole build. I believe it would break builds for some other defines, too. Moving config-override.h include right after predefined configs is more sane and fixes all potential problems with includes.
GCC doesn't let one turn off the warning using "(void) foo()".
People have introduced macros that do "unused << foo()" instead.
Until we do something similar, silence gcc.
Clang on the other hand understands "(void) foo()".
Previously, some bad font data was accidentally being interpretted as
legit if it happened to not fall out of memory bounds. The intention
of the code was what this commit does. I'm surprised we weren't getting
a "arithmetic between signed and unsigned values" warning / error
before.
- Rename enum type and enum members.
- in_errors() now returns true for any error having been set. hb-subset now looks for offset overflow only errors to divert to repacker.
- Added INT_OVERFLOW and ARRAY_OVERFLOW enum values.
Vertices can now be prioritized to force them to sort closer to their parent. The resolver will attempt to use this for overflows on non-shared vertices.
previously remove_redundant_sys () is missing in harfbuzz, after
redundant langsys removal, some features are removed as well in
prune_features() in fonttools. This change is trying to get the same
result between harfbuzz and fonttools.
optimize recurse_lookups in Context/ChainContext
glyph closure, only the glyphs that the parent lookup
can apply the recursion to can participate in recursing
the lookup.
Previous GSUB glyph closure is done by recursively visiting
all reachable lookup tables that apply to any glyphs in the
current/input glyph set, but actually only the glyphs that
the parent lookup can apply the recursion to can participate
in recursing the lookup. This is step 1 for glyph closure
optimization:
1. Add stack of currently active glyph set pointers into hb_closure_context_t
2. Update closure() method in simple GSUB tables to use
this stack in order not to change current glyph set at different stages
of recursion
3. Add function may_have_non_1to1() to GSUB tables
- subset class def 1 against the coverage table.
- Don't re-use class 0 in class def 2.
- Ignore class 0 glyphs for the purposes of determing format 1 vs format 2 encoding for ClassDef.
Add an additional test case which demonstrates these issues.
Sucks that has to be specified in this order. But that is what it is for now.
Was only exhibiting problem on C++>=17 since that's when the [[nodiscard]]
was introduced.
To my surprise, saves ~20kb in my build (non-size-optimized) build.
The output_glyph() method is never used in the fast paths, so doesn't
matter if is not fully optimized for the special case it is.
Previous error-handling philosophy was that user doesn't need to
immediately know whether operation failed. But as can be seen after
we added malloc-failing fuzzing, there's just so many places in the
code that a failure of these operations needs to be mitigated before
further operations. So I'm moving towards returning success here,
and possibly making it nodiscard.
I did a review; changed some "return"s to "break"s, which should be identical.
Removed one check just before "continue" because not necessary.
The added error check is the actual fix.
Should fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31755
We treat Class0 as "doesn't intersect". That's the only meaningful
interpretation. If one allos Class0 to mean "intersects", then the
intersects() result should be true iff glyphset is non-empty.
Related to https://github.com/harfbuzz/harfbuzz/issues/2703
Don’t replace Default_Ignorables with zero-width space if they are
substituted or multiplied, not just when ligated.
After this change, HarfBuzz output matches that of Uniscribe and
CoreText for the new tests.
Fixes https://github.com/harfbuzz/harfbuzz/issues/2883
I was getting check-symbols failure because my previous build was
without CoreText, and after reconfiguring with CoreText, the old
harfbuzz.defs file was not being regenerated.
Was producing non-monotonic cluster numbers because our faulty logic
was not merging clusters if something from before base and after base
had switched positions.
Fixes https://github.com/harfbuzz/harfbuzz/issues/2272
Previous commit didn't fix the bots. Putting it back now that I
understand why I initially did the "Wide" casts. But only doing
it for out-cast this time. This causes "narrowing" warnings
whenever we are converting signed/unsigned to smaller HBUINT16
etc. But those are valuable warnings. We should address those
separately instead of ignoring.
Maybe we should start using uint16_t more liberally in the
internal subsetter function signatures then.
My local clang12 is fine, but many bots are not:
../src/hb-ot-cff1-table.hh: In instantiation of ‘bool CFF::Charset1_2<TYPE>::sanitize(hb_sanitize_context_t*, unsigned int) const [with TYPE = OT::IntType<unsigned char>]’:
../src/hb-ot-cff1-table.hh:554:13: required from here
../src/hb-ot-cff1-table.hh:377:60: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (unlikely (!ranges[i].sanitize (c) || (num_glyphs < ranges[i].nLeft + 1)))
~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
Enabling the extra cast operator mentioned in previous commit to see if
that fixes this case.
Again, I'd be happy to say "use 1u instead of 1" if this was universally
erred on. But since some compilers happily compile this while others
err, it would be a huge headache. Let's see...
https://github.com/harfbuzz/harfbuzz/pull/2875
Say for USHORT, we were implementing casts from and to unsigned.
With this change, we cast from and to uint16_t only. This allows
compiler more opportunities to catch possible narrowing issues in
the code.
It needed a couple of fixes in the codebase though, because
previously, if a USHORT was participating in arithmetic with signed
numbers, eg. "u + 1", the result would have been unsigned. With
this change, it would be signed. The correct fix is to update the
code to read "u + 1u".
That said, I think about conditionally adding back the cast
out to signed/unsigned, to facilitate better type deduction.
But I couldn't think of a real situation where that would help
with anything. So I didn't add. Here's what it was:
template <typename Type2 = hb_conditional<hb_is_signed (Type), signed, unsigned>,
hb_enable_if (sizeof (Type) < sizeof (Type2))>
operator hb_type_identity_t<Type2> () const { return v; }
https://github.com/harfbuzz/harfbuzz/pull/2875
../src/hb-algs.hh:120:3: error: body of constexpr function ‘constexpr BEInt<Type, 2>::operator Type() const [with Type = short unsigned int]’ not a return-statement
The immutable objects are a concept only enforced by the C API.
So move checks only to that region.
This does assume that the rest of the code is careful not getting
into these internal methods on immutable objects, which something
we do, but have no way of enforcing (currently).
.
Some compilers don't like this:
../src/hb-aat-layout-common.hh:732:9: error: declaration of 'using StateTable = struct AAT::StateTable<Types, EntryData>' changes meaning of 'StateTable' [-fpermissive]
732 | using StateTable = StateTable<Types, EntryData>;
The state we are dealing with here is the previous state; so it should
cause unsafe_to_break before current glyph.
I'm surprised this wasn't caught by any tests. Guess we don't have any
fonts with fancy end-of-text forms.
There's no easy way to undo a "using namespace" in our sources, so by the time
we get to include hb-coretext.cc from harfbuzz.cc, we already have "using namespace OT"
active, which clashes with Mac headers.
Error was:
$ gcc -O3 -Wall -arch i386 -DHAVE_CORETEXT=1 -c harfbuzz.cc -o harfbuzz.o -std=c++11
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/TextUtils.h:288:3: error:
reference to 'OffsetTable' is ambiguous
OffsetTable offsets,
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/IntlResources.h:115:41: note:
candidate found by name lookup is 'OffsetTable'
typedef OffPair OffsetTable[3];
^
./hb-open-file.hh:81:16: note: candidate found by name lookup is 'OT::OffsetTable'
typedef struct OffsetTable
^
1 error generated.
As suggested by Ned, just ignoring it.
warning: 'CTGetCoreTextVersion' is deprecated: first deprecated in macOS 11.0 - Use
-[NSProcessInfo operatingSystemVersion] [-Wdeprecated-declarations]
- Lookup::closure_lookups also checks if the lookups visited and sets the lookup to visited. If we set visited in 'recurse' then Lookup::closure_lookups will fail to recurse into the children of the lookup.
- Also when copying ChainRule's skip LookupRecord's that point to lookups which aren't retained. This matches FontTool's behaviour.
Garret Rieger
Qunxin Liu
tstuefe
Khaled Hosny
Behdad Esfahbod
Ben Denckla
Andrzej Perczak
David Corbett
justvanrossum
josephshen
ckitagawa