This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]