Re: [ft-devel] Fwd: Issue 977845 in chromium: pdf_font_fuzzer: Integer-overflow in compute_glyph_metrics

[Behdad Esfahbod]

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 <address@hidden> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype-devel

--

behdad
http://behdad.org/