https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78772
--- Comment #11 from Jim Wilson <wilson at gcc dot gnu.org> --- This language has been in the standard since ANSI C 89/ISO C 90. >extern char buf[32]; >int *a = (int *)&(buf[16]); >int result = *a; //is this ok? or we have to use memcpy(&result, &buf[16], >>sizeof(int))? This isn't conforming. You can cast any pointer to char * and dereference it. You can't cast a char * pointer to any unrelated type and expect that to work. This is likely to work anyways, as the aliasing is obvious. The compiler should detect the aliasing and handle it correctly. The problematic cases are where you have complex control flow or pass an address into a subroutine. The compiler may not be able to detect that two pointers alias based on address, and then decides that they don't alias based on addresses. This example may generate an unaligned memory access on some machines because int requires more alignment than char. This unaligned access may be emulated in a trap handler (i.e. very slow) or may generate a signal causing the program to fail. If you have code with a lot of pointer casts, you should probably be compiling with -fno-strict-aliasing and/or -Wstrict-aliasing. The handling of these options was decided a while ago, and we won't be making any changes here.
