struct Foo { int x; float y; }; int main() { struct Foo data = Foo { 0 }; return (&data.x)[1]; }
-
-
-
I'd be willing to believe this is UB according to a different rule, though.
-
I'd guess that it's UB to access memory beyond the end of (&x[0]) because there could be padding there.
-
Eh yeah I didn't want to work too hard to avoid padding issues. I assume you can avoid that with newtypes of int?
-
struct X{ a: int; } struct Y{ b: int }; struct Foo { struct X x; struct Y y; }; Can't possibly have padding?
-
I'm not so sure about that. Regardless, I think it makes sense to add a qualifier "assuming common-sense pointer math & indexing."
End of conversation
New conversation -
-
-
if you have a criterion to prevent you from doing what's below you should be safe void *p = malloc(…); int *q = p; float *r = p;
-
Such a rule would be "the result of malloc is immediately assigned to a pointer-to-T where T is a non-void type", maybe?
-
“a complete type”, otherwise: int (*p)[] = malloc(…); int (*q)[5] = p; int (*r)[6] = p; See http://stackoverflow.com/questions/40606989/gcc-and-strict-aliasing-between-arrays-of-a-same-type …
-
although when this was pointed out GCC devs changed the behavior: https://gcc.gnu.org/ml/gcc/2016-11/msg00111.html …
End of conversation
New conversation -
-
-
If you never use functions like malloc/mmap returning void pointers to start with and -Werror=incompatible-pointer-types, maybe.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.