On Mon, Jan 23, 2023 at 05:03:00PM +0100, Alejandro Colomar via Gcc wrote: > Hi Stefan, > > On 1/23/23 08:40, Stefan Puiu wrote: > > > > > According to strict aliasing rules, if you declare a variable of type 'struct > > > > > sockaddr_storage', that's what you get, and trying to access it later as some > > > > > other sockaddr_8 is simply not legal. The compiler may assume those accesses > > > > > can't happen, and optimize as it pleases. > > > > > > > > Can you detail the "is not legal" part? > > > > > > I mean that it's Undefined Behavior contraband. > > > > OK, next question. Is this theoretical or practical UB? > > > Since the functions using this type are not functions that should be > inlined, since the code is rather large, they are not visible to the > compiler, so many of the optimizations that this UB enables are not likely > to happen. Translation Unit (TU) boundaries are what keeps most UB > invokations not be really dangerous. > > Also, glibc seems to be using a GCC attribute (transparent_union) to make > the code avoid UB even if it were inlined, so if you use glibc, you're fine. > If you're using some smaller libc with a less capable compiler, or maybe > C++, you are less lucky, but TU boundaries will probably still save your > day. Please see transparent_union documentation in GCC documentation. E.g. https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Type-Attributes.html#index-transparent_005funion-type-attribute transparent_union doesn't change anything regarding type punning, it is solely about function arguments, how arguments of that type are passed (as first union member) and that no casts to the union are needed from the member types. And, with LTO TU boundaries are lost, inlining or other IPA optimizations (including say modref) work in between TUs. Jakub
