[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] Curb the scaling
From: |
Alexei Podtelezhnikov |
Subject: |
Re: [ft-devel] Curb the scaling |
Date: |
Fri, 13 Oct 2017 15:48:54 -0400 |
On Fri, Oct 13, 2017 at 2:00 PM, Kostya Serebryany <address@hidden> wrote:
>
>
> On Fri, Oct 13, 2017 at 7:43 AM, Alexei Podtelezhnikov <address@hidden>
> wrote:
>>
>> > [*] 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.
>>
>> I would like to address this to Kostya. Please do tell us how to
>> inform ftfuzzer that the overflow is acceptable here. Perhaps, we can
>> add a special comment /* ftfuzzer overflow */ or something. GCC has a
>> special flag -fwrapv or make sure that the overflow wraps around.
>
> You may shut it down with an attribute on a function:
> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#disabling-instrumentation-with-attribute-no-sanitize-undefined
This __attribute__((no_sanitize("signed-integer-overflow"))) is
actually pretty close to what ADD_ and SUB_ macros achieve. This is
not as fine grained but the effect is mostly the same. We just declare
that the we accept the overflows in this function.
- [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, 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 <=
- Re: [ft-devel] Curb the scaling, Werner LEMBERG, 2017/10/13