https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608
Kees Cook <kees at outflux dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kees at outflux dot net
--- Comment #5 from Kees Cook <kees at outflux dot net> ---
I think this behavior may, unfortunately, be "as expected", due to how the
memcpy overflow checks are working (they're checking surrounding object, yes,
like bos(0) would)? The constant-expression bos() calculations do appear to
understand the base pointer object, but when faced with "i", it can't know for
sure -- it might have room (if "i" is < 3), or not. So it must return -1 as it
lacks any other context (like memcpy's "size" argument).
There may, however, be a missing opportunity for tightening the memcpy checker?
For example:
...
volatile unsigned i;
struct weird {
char a[4];
char b[8];
};
int main (void)
{
{
struct weird instance;
char d [3];
P (d + i);
memcpy (d + i, "abcdef", 5); // always overflows d (the entire object)
i = 7;
P (instance.a + i); // can't see into "i"
P (instance.a + 7); // room left in instance (5), but not "a" (0)
memcpy (instance.a + i, "abcdef", 5); // misses a, doesn't overflow
instance. should this warn?
__builtin_printf ("%.0s", d);
}
}
-1 -1 0 0
-1 -1 0 0
5 0 5 5
