This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/82802] New: Potential UBSAN error with pointer difference (32-bits mode)
- From: "yann.collet.73 at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 01 Nov 2017 23:37:48 +0000
- Subject: [Bug c/82802] New: Potential UBSAN error with pointer difference (32-bits mode)
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82802
Bug ID: 82802
Summary: Potential UBSAN error with pointer difference (32-bits
mode)
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann.collet.73 at gmail dot com
Target Milestone: ---
As part of our CI test suite,
we compile and run fuzzer tests every day.
The UBSAN test has been failing for some time now.
I suspect it's related to our provider having updated at some point the gcc
version.
The failure happens in this situation :
presuming we have 2 pointers : highPtr > lowPtr,
if I request the distance in 32-bits mode,
both pointers being associated to the same object
(one is the upper limit, another is a cursor into the object)
`highPtr - lowPtr` generates this UBSAN error :
runtime error: signed integer overflow: -2147452928 - 1879078921 cannot be
represented in type 'int'
The values of these pointers are :
highPtr : 0x80007800
lowPtr : 0x70018AAB
As can be seen, there is no overflow : highPtr is > lowPtr, and the distance is
~256 MB, well within the limits of ptrdiff_t in 32-bits.
Nonetheless, UBSAN consider it an error, likely because it crosses the
0x80000000 threshold.
I suspect the pointer addresses are converted into `int` type *before* the
substraction, which leads to UBSAN conclusion.
The same code on clang doesn't trigger any error.