------- 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
