This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
- From: "mmitchel at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 2 Oct 2006 17:48:09 -0000
- Subject: [Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
- References: <bug-29286-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #17 from mmitchel at gcc dot gnu dot org 2006-10-02 17:48 -------
I disagree with Mike's analysis. I certainly understand the goals of placement
new, but I don't think that anyone intended this code:
int i;
*(float *)&i = 7.0;
to be valid. I don't even think people intended this variant:
int i;
new (&i) float(7.0);
to be valid. Note that a consequence of allowing this is that:
int f() {
int i = 3;
new (&i) float(7.0);
return i;
}
is undefined -- not because of the overwriting of i, but because the return
statement reads memory of the wrong type. Mike's position is that accessing a
variable using its static type is not always safe; I find this bizarre.
My personal opinion is that the authors of the standard just didn't think of
all the possible interactions of the various aspects. I believe placement new
was intended to handle only arrays of characters, consistent with the special
dispensation given to character pointers.
However, I don't think my differences with Mike can be resolved without going
directly to the standards committee. Fortunately, from the compiler point of
view, I'm saying "punt" and Mike is saying "punt harder". So, it's probably
just a question of in how many cases we decide to disable type-based alias
analysis.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286