On Tue, Dec 15, 2009 at 2:11 AM, Csaba Halász <csaba.hal...@gmail.com> wrote: > > That may be the nasal bug Jacob is seeing. I could reproduce it and > also made a little test case that I am gonna submit as a gcc bug > report. It is clearly accessing the "double" member of the union > before it has been established as valid.
Even though there is a related gcc bug, we must realize that the current implementation of naRef is not standard C, it is relying on undefined behaviour: "With one exception, if the value of a member of a union object is used when the most recent store to the object was to a different member, the behavior is implementation-defined." That is, setting the "num" member of a naRef and then examining the "ref" member (which IS_NUM is doing) is undefined. I believe simply expecting the two members to overlay each other is also relying on undefined behaviour. The best way would be to make naRef bigger by adding a separate tag and not mess with nonstandard stuff. I have also tested making naRef a char[8] and memcpy-ing the relevant bytes out. That still relies on the actual memory layout of a double but should otherwise be standard compliant while keeping the current size. GCC optimized away the memcpy-s for me. Thoughts? -- Csaba/Jester ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
