https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |jsm28 at gcc dot gnu.org
Resolution|INVALID |---
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #8)
> The code in comment #0 is undefined. It's not valid to advance a pointer to
> A to point to B and dereference the pointer. It doesn't matter if the
> pointer points to the outermost object or to one of its subobjects. This is
> true for hand-rolled loops as much as for functions like strlen that take
> strings as arguments. Likewise, the test case in comment #5 is undefined
> for the same reason (a char array of size one can only hold the empty
> string).
I am not convinced. You say that
struct { int a; int b; } s, s2;
memcpy (&s2.a, &s.a, sizeof (s));
is invalid, aka not copying the whole structure since you pass in a
pointer to s2.a rather than s2? Alternatively
struct { int x; int a; int b; } s, s2;
memcpy (&s2.a, &s.a, sizeof (s) - sizeof (int));
is similarly invalid, not copying the last two elements?
I don't see how str* are in anyway less special than mem* here in case you
come up with an exception for mem*.
At least from a QOI perspective (and GIMPLE representation perspective!)
claiming the above are invoking undefined behavior is plain wrong.
