This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC][Draft patch] Introduce IntegerSanitizer in GCC.
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Maxim Ostapenko <m dot ostapenko at samsung dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Yuri Gribov <tetra2005 at gmail dot com>, Marek Polacek <polacek at redhat dot com>, Kostya Serebryany <kcc at google dot com>, Jeff Law <law at redhat dot com>, Aldy Hernandez <aldyh at redhat dot com>
- Date: Mon, 11 Jul 2016 17:05:54 +0200
- Subject: Re: [RFC][Draft patch] Introduce IntegerSanitizer in GCC.
- Authentication-results: sourceware.org; auth=none
- References: <577A44B5.1000103@samsung.com> <577B6253.5050605@samsung.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jul 05, 2016 at 10:31:31AM +0300, Maxim Ostapenko wrote:
> CC'ing Jakub, Marek and Kostya, sanitizer maintainers in GCC.
I'm not convinced it is a good idea, that is why we've intentionally left it
out when adding UBSan support, IMHO such an option defines substantially
different languages.
The wrapping behavior of unsigned integer arithmetics is
integral part of the language, lots of code obviously relies on it.
E.g. in unsigned arithmetics, x - y and t = -y; x + t is the same thing,
while the patch would treat that differently. Or would it even allow
unary negation of non-zero unsigned values? On IRC I've mentioned e.g.
loops with unsigned iterator and bounds that can iterate forward or backward
at runtime, like:
void foo (unsigned start, unsigned end, unsigned step)
{
for (unsigned i = start; i != end; i += step)
...
}
would one have to rewrite this to do something like: "step_is_negative" ? i -= -step : i += step
instead? How would code portably say that for a given arithmetics it really
does assume wrapping behavior? Replacing x = y + z; with
(void) __builtin_add_overflow (y, z, &x);
is not sufficiently portable, trying x = (y + z) & ~(unsigned) 0;
I assume would still trigger, because the unsigned arithmetics still
"overflows".
I'm really surprised you didn't run into many more "issues" during your
tests.
Jakub