This is the mail archive of the 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 #22 from mark at codesourcery dot com  2006-10-04 05:39 -------
Subject: Re:  [4.0/4.1/4.2 Regression] placement new
 does not change the dynamic type as it should

ian at airs dot com wrote:
> ------- Comment #21 from ian at airs dot com  2006-10-03 23:44 -------
> In C a general allocation function should work with a char array.  A specific
> allocation function should use a union.  I don't think there are many existing
> exceptions to these guidelines.

> So I don't see a serious problem in C either.  Am I missing something/

I think there are two remaining issues:

   int i;
   *(float*)(&i) = 7.0;

IIUC, Mike's position is that this is valid -- and that, in fact, after 
this point "i" can no longer be accessed as an int.  Do you agree?  Or 
do you think that this is (should be?) undefined behavior?

I think you are saying that:

   int i;
   new (&i) float;

is valid, and that after this point accessing "i" as an int is invalid. 
  Is that correct?  If so, I assume that you conider the following C 
code valid as well:

   int i;
   float f;
   memcpy (&i, &f, sizeof (i));


Also, in C++, given:

   extern void f(int *);
   void g() {
     int i;
     /* HERE */

do you believe that at the point marked HERE the dynamic type of "i" is 
indeterminate?  I think that if we allow the examples above, we have to 
assume that something may have reset the dynamic type of "i" here, 
meaning that we cannot assume that future stores through "float *" in 
the function do not alias "i".


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