[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: |
Fri, 13 Oct 2017 07:48:02 +0200 (CEST) |
>> As mentioned earlier, there is no chance to ever catch cumulative
>> values without actively comparing against a maximum value. And
>> such a comparison is more expensive that using ADD_LONG and
>> friends.
>
> Largely, it comes down to taste.
The cumulative one is *not* a matter of taste.
> I love the vector algebra of rendering and want to preserve the
> algebraic look in the C code. These macros shred it to pieces and
> make it ugly.
Yes.
> I am glad that so far the rendering code was spared. That is my
> honest opinion.
:-)
> I said it before, these macros do not fix the overflows, they only
> silence the fuzzer.
Well, the macros mark the places where harmless overflows can
happen,[*] which is good. If you have ideas how to remove them
without introducing expensive guards, please tell!
Werner
[*] Actually, what's ugly is the macro syntax. I would like to have
compiler support like
foo = bar + baz __attribute__ ((allowed_overflow));
so that the mathematical operators are not hidden.
- [ft-devel] Curb the scaling, Alexei Podtelezhnikov, 2017/10/03
- Re: [ft-devel] Curb the scaling, Werner LEMBERG, 2017/10/04
- 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 <=
- 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