------- Comment #16 from mrs at apple dot com 2006-10-02 09:32 ------- The dynamic type of the object at &i is indeed float and has the value 7.0 (iff align and sizes work out). We permitted this so that can can do:
class C { ... }; char buf[1024]; new (&buf[n]) C and have the dynamic type of the storage be C. You can know the dynamic type is C, by doing a virtual dispatch, or by asking for the name of the type with rtti. Likewise, you can do: new (&i) float(7.0) with the same effects. The dynamic type is float, and the value is 7.0, and this is in all ways the same as: *(float*)&i = 7.0 Thinking about this some more, it would appear that it is unsafe to reorder writes of otherwise non-conflicting types past each other as type based analysis alone isn't enough to ensure they don't conflict. It might be reasonable to add the C rules that the dynamic type _must_ match the static (declared) type, if there is one for types other than pointer or pointer to member the the language standard and to clarify the dynamic type of an object when a bitwise copy of the object is made to better match the C rules. Reads should be fine as they are required to be the same type as the write (or character). In practice, if the optimizer can't see the placement new, it can't reorder things so this is safe; if it can see it, then it should do value based analysis in addition to type analysis and conclude they conflict (or can conflict) and still avoid doing the wrong thing. I do agree, that for now, this isn't a bug in the library. It could be made a bug in the library by requring a placement new operator as the only way in which storage can be reused as a different dynamic type. -- mrs at apple dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286