Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
I'm not sure what exactly points of discussion are, but in HarfBuzz we do purposefully ignore position overflows. We use a macro like this for that: #define HB_NO_SANITIZE_SIGNED_INTEGER_OVERFLOW __attribute__((no_sanitize("signed-integer-overflow"))) If you want to copy the macro, please copy its surrounding conditions as well. b On Tue, Aug 13, 2019 at 3:04 PM wrote: > >> Whether with -wrapv or with the unsigned macros, we simply disable > >> some compiler optimizations, perhaps some good optimizations too. > > > > Most certainly, yes. But there are a lot more things that slow down the > > potential performance of FreeType -- C in itself is a trade-off between > > maintainability and performance. > > > >> Why? Is it because we got scared? There is absolutely no evidence of > >> real bugs in FreeType. It is reasonable to disable optimizations with > >> -wrapv, if scared, but macros are too rigid. Some compilers recognize > >> /* fall through */ comment to suppress particular warnings. I wish we > >> could just add a comment to silence these warnings after adjudication. > > > > It's not about being scared but about making sure we understand _what_ > the > > code within FT does. If we proactively mark operations that have a > certain > > behaviour we make those operations explicit to whomever reads that thing > in > > the future. `-wrapv' has two downsides IMO: (1) we lose track of what > it > > does and _where_ ... maybe, really covering up bugs (2) we rely on 3rd > parties > > to compile FT in a very specific way to avoid certain types of reports. > > For reference, find the patch attached (most code in that area is already > wrapped in `*_LONG' macros). > > @Werner: should I apply it? > > Armin > ___ > Freetype-devel mailing list > Freetype-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/freetype-devel > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
>> Whether with -wrapv or with the unsigned macros, we simply disable >> some compiler optimizations, perhaps some good optimizations too. > > Most certainly, yes. But there are a lot more things that slow down the > potential performance of FreeType -- C in itself is a trade-off between > maintainability and performance. > >> Why? Is it because we got scared? There is absolutely no evidence of >> real bugs in FreeType. It is reasonable to disable optimizations with >> -wrapv, if scared, but macros are too rigid. Some compilers recognize >> /* fall through */ comment to suppress particular warnings. I wish we >> could just add a comment to silence these warnings after adjudication. > > It's not about being scared but about making sure we understand _what_ the > code within FT does. If we proactively mark operations that have a certain > behaviour we make those operations explicit to whomever reads that thing in > the future. `-wrapv' has two downsides IMO: (1) we lose track of what it > does and _where_ ... maybe, really covering up bugs (2) we rely on 3rd parties > to compile FT in a very specific way to avoid certain types of reports. For reference, find the patch attached (most code in that area is already wrapped in `*_LONG' macros). @Werner: should I apply it? Armin 977845.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] WOFF2 Support Update
> Is this only useful for WOFF2? Or, can it be productively utilized by > TTC in general? Sorry I missed this mail. Right now this is only useful for WOFF2. In the future, if we have another sfnt-wrapper format that supports TTCs, this can be generalized. -- Nikhil ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics
> Whether with -wrapv or with the unsigned macros, we simply disable some > compiler optimizations, perhaps some good optimizations too. Most certainly, yes. But there are a lot more things that slow down the potential performance of FreeType -- C in itself is a trade-off between maintainability and performance. > Why? Is it because we got scared? There is absolutely no evidence of real bugs > in FreeType. It is reasonable to disable optimizations with -wrapv, if > scared, but macros are too rigid. Some compilers recognize /* fall through */ > comment to suppress particular warnings. I wish we could just add a comment to > silence these warnings after adjudication. It's not about being scared but about making sure we understand _what_ the code within FT does. If we proactively mark operations that have a certain behaviour we make those operations explicit to whomever reads that thing in the future. `-wrapv' has two downsides IMO: (1) we lose track of what it does and _where_ ... maybe, really covering up bugs (2) we rely on 3rd parties to compile FT in a very specific way to avoid certain types of reports. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel