[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] Curb the scaling
From: |
Werner LEMBERG |
Subject: |
Re: [ft-devel] Curb the scaling |
Date: |
Wed, 04 Oct 2017 06:16:45 +0200 (CEST) |
> As per our discussion I propose the following patch to limit the
> outline scaling so that ppem values do not exceed 65535. As far as
> I can see, no such limits are currently in place, ppem values are
> simply truncated while the scaling factors are not limited.
Looks good.
> My secret goal is to limit those integer addition/subtraction
> overflows in the future and, perhaps, revisit the old ones. To that
> effect, if this is accepted, I propose turning the ADD_ and SUB_
> macros back to normal arithmetic and see how many overflows truly
> survive. I hope to see some of the macros gone if they are
> triggered by crazy scaling.
Kostya, is there a possibility to make the fuzzer temporarily watch a
branch of FreeType also, using the already created set of malformed
files of master? Then Alexei's suggestion could be tested quite
easily.
Or to ask differently: Where can we download the complete set of
malformed files that are currently in use by the fuzzer? Then Alexei
could easily run a clang binary by himself.
Werner
- [ft-devel] Curb the scaling, Alexei Podtelezhnikov, 2017/10/03
- Re: [ft-devel] Curb the scaling,
Werner LEMBERG <=
- Re: [ft-devel] Curb the scaling, Alexei Podtelezhnikov, 2017/10/12
- Re: [ft-devel] Curb the scaling, Werner LEMBERG, 2017/10/12
- Re: [ft-devel] Curb the scaling, Alexei Podtelezhnikov, 2017/10/12
- Re: [ft-devel] Curb the scaling, Werner LEMBERG, 2017/10/13
- Re: [ft-devel] Curb the scaling, Alexei Podtelezhnikov, 2017/10/13
- Re: [ft-devel] Curb the scaling, Kostya Serebryany, 2017/10/13
- Re: [ft-devel] Curb the scaling, Alexei Podtelezhnikov, 2017/10/13
- Re: [ft-devel] Curb the scaling, Werner LEMBERG, 2017/10/13