From: Segher Boessenkool > Sent: 16 December 2021 18:56 ... > > The only remaining problem here is reinterpreting a char* pointer to a > > u32*, e.g., for accessing the IP address in an Ethernet frame when > > NET_IP_ALIGN == 2, which could suffer from the same UB problem again, > > as I understand it. > > The problem is never casting a pointer to pointer to character type, and > then later back to an appriopriate pointer type. > These things are both required to work. I think that is true of 'void *', not 'char *'. 'char' is special in that 'strict aliasing' doesn't apply to it. (Which is actually a pain sometimes.) > The problem always is accessing something as if it > was something of another type, which is not valid C. This however is > exactly what -fno-strict-aliasing allows, so that works as well. IIRC the C language only allows you to have pointers to valid data items. (Since they can only be generated by the & operator on a valid item.) Indirecting any other pointer is probably UB! This (sort of) allows the compiler to 'look through' casts to find what the actual type is (or might be). It can then use that information to make optimisation choices. This has caused grief with memcpy() calls that are trying to copy a structure that the coder knows is misaligned to an aligned buffer. So while *(unaligned_ptr *)char_ptr probably has to work. If the compiler can see *(unaligned_ptr *)(char *)int_ptr it can assume the alignment of the 'int_ptr' and do a single aligned access. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
