[PATCH] Fix C++ strict-aliasing issues with memcpy folding

[Michael Matz]

Hi,

On Mon, 25 Jan 2010, Mark Mitchell wrote:

> > So, let's assume you meant a read-access above, then you say this better 
> > not be invalid, if the declared type is 'int', but you're fine if it were 
> > an char[]?  But then you need to say how //something looks like, because 
> > some examples will be invalid also in your definition, for instance if 
> 
> My claim is that no value of "//something" should render this code
> invalid.

But clearly, for some values of //something the whole fragment will be 
invalid, because some constructs in there will be invalid, ref. my try to 
use placement new with your reading.

> > Our interpretations
> 
> (Whose interpretation is this?  Is it some segment of the ISO committee,
> or some segment of the GCC developers, or some segment of SuSE, or
> something else?

(Room 3.2.9, SuSE office, Nuernberg == richi+me ;-) )

> Your further discussion involves GCC internals and limitations on what
> we do or do not know at various points in the compiler.  That's clearly
> important for practical purposes, but the first priority should be to
> decide what we want the language to mean.

Well, to me it goes in lockstep, it doesn't make sense to put requirements 
into the language which can't ever be made use of in either the compiler 
or at least makes life easier for people.  So in your stance, "an int is 
an int", how makes it life easier for people or compiler?  Note that for 
this promise to hold you need to declare certain constructs in //something 
invalid.

> Of course, it's likely that the compiler will have to be conservative 
> (i.e., assume some worst-case situations when it cannot prove 
> otherwise).  But, I think it's still valuable to understand on the 
> language.

Oh, yes, I fully agree.  Some of these discussion reveal quite interesting 
deep truths (or ommissions) in the language standards :)


Ciao,
Michael.