On 05/27/2015 06:24 PM, Martin Sebor wrote: > On 05/27/2015 05:09 AM, Florian Weimer wrote: >> Is there a way to check for strict aliasing mode in the preprocessor? >> >> I would like to add warnings to those glibc header files which define >> interfaces with inherent aliasing violations. > > I don't think there is such a macro but I'm curious about > the nature of the aliasing violations and where they occur. > For instance, do they occur in public headers (e.g., by > virtue of the interfaces being defined there as inline > functions or some such) or in the implementation of the > interfaces in library sources? Is fixing the aliasing > violations not feasible? I'm particularly worried about issues related to struct sockaddr. Apparently, some of the legacy interfaces used struct sockaddr where they should have used struct sockaddr_in (they are legacy because they cannot support IPv6 due to this oversight). We found a generic way to avoid the aliasing violation (copy to a union of struct sockaddr and struct sockaddr_in, to the former member, and access data via the latter), but I'm not 100% convinced it's absolutely future-proof because technically, I think it is still an aliasing violation (effective types do not match during the initial copying to the struct sockaddr member if it's actually an object of type struct sockaddr_in). -- Florian Weimer / Red Hat Product Security
