Erik Trulsson <ertr1013 <at> student.uu.se> writes: > > int i; > > unsigned int *pui = (unsigned int*)&i; > > unsigned int ui = *pui; > > (First I will assume that 'i' will be assigned some value, to make sure it > does not contain a trap-representation, or the assignment to 'ui' would have > undefined behaviour.) > > I think 6.2.5 clause 27 is very relevant for this. It says that 'pointer to > int' and 'pointer to union' do not need to have the same representation as > each other. It also seems that 'pointer to int' and 'pointer to unsigned > int' do not need to have the same representation requirements (at least I > cannot find anything that says that signed and unsigned variants are > compatible types.) (Which I must admit comes as a bit of a surprise to me.) > > So, yes, that example does technically seem to be undefined (but I don't > know of any real-world implementation where it would not work as expected.)
I am wondering how, under this interpretation, an "int" and "unsigned int" could ever alias each other, as 6.5p7 says they can. I believe now (especially after the notes Nick pointed us to) that your interpretation of 6.5p7 is the intended one. But if that is the case, then we should expect to find some legal way in which "int" and "unsigned int" could come to be aliased. With your interpretation about pointer conversions, I don't see how this could be. Josh
