Regarding casting between dissimilar types: > c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. > -O2 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 > -Wall -DBSD=1 MatroskaFileParser.cpp > MatroskaFileParser.cpp: In member function Boolean > MatroskaFileParser::parseEBMLVal_float(EBMLDataSize&, float&): > MatroskaFileParser.cpp:1138:26: warning: dereferencing type-punned pointer > will break strict-aliasing rules [-Wstrict-aliasing] > MatroskaFileParser.cpp:1145:34: warning: dereferencing type-punned pointer > will break strict-aliasing rules [-Wstrict-aliasing] > > ... > No, this compiler warning message does not indicate a bug in the code. > "resultAsUnsigned" is a 4-byte value that stores a 'float'; it is not an > unsigned value that gets converted to a float. > > ... > > If you can suggest an alternative coding that eliminates your compiler > warning, then that would be great. But the code - as it stands - is not > in error.
I've researched this, and it seems the right thing to do for this 'non-bug' is to add a compiler switch to tell it to be a little less aggressive in it's optimization so it doesn't generate incorrect code. The compiler flag is -fno-strict-aliasing. And yes, it will (not silently) generate incorrect code for certain uses of the construct. Here are a couple of cogent discussions on the issue: Linus dissing gcc: https://lkml.org/lkml/2003/2/26/158 A very thorough analysis of the issue: http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html A careful review of the above analysis: http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing/ // Wally _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
