https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119132
Kees Cook <kees at outflux dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |---
--- Comment #9 from Kees Cook <kees at outflux dot net> ---
(In reply to Andrew Pinski from comment #6)
> `&p->array[3];` is well defined in C/C++.
> Having fsanitizer=bounds erroring out for it will break 99% C++ code and a
> few C code.
>
> That is because you could have a loop which does:
> ```
> int *start = &p->array[0];
> const int *end = &p->array[size];
>
> for (; start != end; start++)
> {
> g(*start);
> }
> ```
>
> And that is well defined C code; and it is how most C++ code iterators are
> done.
Hmm, yeah. That is weird, and I can see why the exception was made if that's
all over the place. But why was it not implemented this way? No dependency on
array address, same loop structure:
```
int *start = &p->array[0];
const int *end = start + size;
for (; start != end; start++)
{
g(*start);
}
```
How about we just fix this for -fsanitize=bounds-strict?
Also, can we please stop marking this "resolved"? This is an ambiguous bounds
checking situation that leaves a gap in memory safety coverage that I'd like to
find a way to fix. Saying "that's how the spec is written" is good information
and I appreciate the help in understanding why things were intentionally made
ambiguous, but I still need to get this fixed in some way. :)
If not -fsanitize=bounds-strict perhaps some other new flag that would be
C-only?
