Wait, I think it's actually not allowed by the standard: it's allowed to access a size_t through a char* ("by an lvalue expression that has [...] a character type") but not the other way around. Though GCC might be smart enough to support it both ways, or maybe the aliasing tracker doesn't care about the "actual" type and just decides based on the access types if memory operations can alias, which means one type being char* is fine either way. But it shouldn't be aliased as another type ∉ {char, size_t} then. Best regards, Aaron Am 25.02.21 um 01:07 schrieb Aaron Puchert:
Uh, nevermind, just saw your conversation on the other post. I should probably read the remaining posts before replying the next time.
With char* it should of course be fine and the warning was just a bug.
Am 25.02.21 um 00:57 schrieb Aaron Puchert:
Am 24.02.21 um 10:39 schrieb Stefan Seyfried:
*((size_t *)&a->data[a->last])=a->lastsz;
Can you provide the types of the relevant members of *a? Especially "data" would be interesting. I have tried
struct { size_t last, lastsz; int* data; } a;
which would make it a strict aliasing violation in my reading of the standard ([1], 6.5p7, here we have a 64-bit system with 32-bit int), but I can't get the warning to trigger for any version of GCC in the compiler explorer (godbolt.org), even with -O2 (in case it's a middle end warning).
Though I remember that -Wstrict-aliasing used to be too strict in the past and was relaxed significantly, but I can't give you any details about that. The kind of aliasing we see here is (assuming the types are indeed as above) is technically illegal but no relevant compiler uses that for optimization since it's entirely local and the aliasing is transparent.
Best regards, Aaron
[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf