> On Sep 15, 2023, at 12:53 PM, Xi Ruoyao <xry...@xry111.site> wrote:
>
> On Fri, 2023-09-15 at 15:37 +0000, Qing Zhao wrote:
>>
>>
>>> On Sep 15, 2023, at 11:29 AM, Richard Biener
>>> <richard.guent...@gmail.com> wrote:
>>>
>>>
>>>
>>>> Am 15.09.2023 um 17:25 schrieb Qing Zhao <qing.z...@oracle.com>:
>>>>
>>>>
>>>>
>>>>> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović <ar...@aarsen.me>
>>>>> wrote:
>>>>>
>>>>>
>>>>> Qing Zhao <qing.z...@oracle.com> writes:
>>>>>
>>>>>> Even though unsigned integer overflow is well defined, it
>>>>>> might be
>>>>>> unintentional, shall we warn user about this?
>>>>>
>>>>> This would be better addressed by providing operators or
>>>>> functions that
>>>>> do overflow checking in the language, so that they can be
>>>>> explicitly
>>>>> used where overflow is unexpected.
>>>>
>>>> Yes, that will be very helpful to prevent unexpected overflow in
>>>> the program in general.
>>>> However, this will mainly benefit new codes.
>>>>
>>>> For the existing C codes, especially large applications, we still
>>>> need to identify all the places
>>>> Where the overflow is unexpected, and fix them.
>>>>
>>>> One good example is linux kernel.
>>>>
>>>>> One could easily imagine a scenario
>>>>> where overflow is not expected in some region of code but is in
>>>>> the
>>>>> larger application.
>>>>
>>>> Yes, that’s exactly the same situation Linux kernel faces now, the
>>>> unexpected Overflow and
>>>> expected wrap-around are mixed together inside one module.
>>>> It’s hard to detect the unexpected overflow under such situation
>>>> based on the current GCC.
>>>
>>> But that’s hardly GCCs fault nor can GCC fix that in any way. Only
>>> the programmer can distinguish both cases.
>>
>> Right, compiler cannot fix this.
>> But can provide some tools to help the user to detect this more
>> conveniently.
>>
>> Right now, GCC provides two set of options for different types:
>>
>> A. Turn the overflow to expected wrap-around (remove UB);
>> B. Detect overflow;
>>
>> A B
>> remove UB -fsanitize=…
>> signed -fwrapv signed-integer-overflow
>> pointer -fwrapv-pointer pointer-overflow (broken in Clang)
>>
>> However, Options in A and B excluded with each other. They cannot mix
>> together for a single file.
>>
>> What’s requested from Kernel is:
>>
>> compiler needs to provide a functionality that can mix these two
>> together for a file.
>>
>> i.e, apply A (convert UB to defined behavior WRAP-AROUND) only to part
>> of the program. And then add -fsnaitize=*overflow to detect all other
>> Unexpected overflows in the program.
>>
>> This is currently missing from GCC, I guess?
>
> If overflow is really so rare, we should just enable -fsanitize=signed-
> integer-overflow globally and special case the code paths where we want
> wrapping. It's easy in 2023:
>
> /* b + c may wrap here because ... ... */
> ckd_add(&a, b, c);
>
> Or
>
> /* if b + c overflows, we have a severe issue, let's panic even if
> sanitizer disabled */
> if (chk_add(&a, b, c))
> panic("b + c overflows but it shouldn't (b = %d, c = %d)", b, c);
Yes, this might be exactly the situation that Linux kernel faces and asks for
help:
In some part of the program, it tried to detect the overflow itself and handled
specifically, therefore,
It want this part of the program to be excluded from automagical overflow
detection applied by
the -fsanitize=signed-integer-overflow.
Please see my reply to Richard’s email for more info on this.
Thanks.
Qing
>
> --
> Xi Ruoyao <xry...@xry111.site>
> School of Aerospace Science and Technology, Xidian University
