strict-aliasing

问题 I'm currently using aligned_storage to implement an 'Optional' type similar to that of boost::optional. To accomplish this I have a class member like so: typename std::aligned_storage<sizeof(T), std::alignment_of<T>::value>::type t_; I use placement new to create the object, however I don't store the pointer returned anywhere. Instead, I access the underlying type of the object in all my member functions like this (obviously with checks to ensure the object is valid via a boolean flag also

问题 I used the following piece of code to read data from files as part of a larger program. double data_read(FILE *stream,int code) { char data[8]; switch(code) { case 0x08: return (unsigned char)fgetc(stream); case 0x09: return (signed char)fgetc(stream); case 0x0b: data[1] = fgetc(stream); data[0] = fgetc(stream); return *(short*)data; case 0x0c: for(int i=3;i>=0;i--) data[i] = fgetc(stream); return *(int*)data; case 0x0d: for(int i=3;i>=0;i--) data[i] = fgetc(stream); return *(float*)data;

问题 I am trying to extract the bits from a float without invoking undefined behavior. Here is my first attempt: unsigned foo(float x) { unsigned* u = (unsigned*)&x; return *u; } As I understand it, this is not guaranteed to work due to strict aliasing rules, right? Does it work if a take an intermediate step with a character pointer? unsigned bar(float x) { char* c = (char*)&x; unsigned* u = (unsigned*)c; return *u; } Or do I have to extract the individual bytes myself? unsigned baz(float x) {

问题 When I compile this sample code using g++, I get this warning: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] The code: #include <iostream> int main() { alignas(int) char data[sizeof(int)]; int *myInt = new (data) int; *myInt = 34; std::cout << *reinterpret_cast<int*>(data); } In this case, doesn't data alias an int, and therefore casting it back to an int would not violate strict aliasing rules? Or am I missing something here? Edit: Strange,

问题 When I compile this sample code using g++, I get this warning: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] The code: #include <iostream> int main() { alignas(int) char data[sizeof(int)]; int *myInt = new (data) int; *myInt = 34; std::cout << *reinterpret_cast<int*>(data); } In this case, doesn't data alias an int, and therefore casting it back to an int would not violate strict aliasing rules? Or am I missing something here? Edit: Strange,

问题 Question about type punning: why does this code break strict aliasing rules: int main() { int a = 1; short j; printf("%i\n", j = *((short*)&a)); return 0; } and this is not: int main() { int a = 1; short j; int *p; p=&a; printf("%i\n", j = *((short*)p)); return 0; } Build by gcc -fstrict-aliasing . Thank you! 回答1: They both violate the strict aliasing rule, I am going to quote my answer here which says ( emphasis mine going forward ): code violates the strict aliasing rules which makes it

问题 Question about type punning: why does this code break strict aliasing rules: int main() { int a = 1; short j; printf("%i\n", j = *((short*)&a)); return 0; } and this is not: int main() { int a = 1; short j; int *p; p=&a; printf("%i\n", j = *((short*)p)); return 0; } Build by gcc -fstrict-aliasing . Thank you! 回答1: They both violate the strict aliasing rule, I am going to quote my answer here which says ( emphasis mine going forward ): code violates the strict aliasing rules which makes it

问题 I use a code where I cast an enum* to int*. Something like this: enum foo { ... } ... foo foobar; int *pi = reinterpret_cast<int*>(&foobar); When compiling the code (g++ 4.1.2), I get the following warning message: dereferencing type-punned pointer will break strict-aliasing rules I googled this message, and found that it happens only when strict aliasing optimization is on. I have the following questions: If I leave the code with this warning, will it generate potentially wrong code? Is

问题 According to N1570 6.5/6: If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. That would suggest that even on a system where "long" and some other integer type have the same representation, the following would invoke

问题 3.10/10 If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined: the dynamic type of the object, a cv-qualified version of the dynamic type of the object, a type similar (as defined in 4.4) to the dynamic type of the object, a type that is the signed or unsigned type corresponding to the dynamic type of the object, a type that is the signed or unsigned type corresponding to a cv-qualified version of the