On 2010-01-06 16:52:50 +0100, Erik Trulsson wrote: > On Wed, Jan 06, 2010 at 04:09:11AM +0000, Joshua Haberman wrote: > > I think this is a bit of a stretch. It is true that 6.5.3.2 says that > > dereferencing invalid values has undefined behavior. But if you are > > saying that the standard has to explicitly say that a pointer conversion > > will not result in an invalid value (even when suitably aligned), then > > the following is also undefined: > > > > int i; > > unsigned int *pui = (unsigned int*)&i; > > unsigned int ui = *pui; > > > > Andrew cited 6.3.2.3p2 as support for why this is defined, but that > > paragraph deals with qualifiers (const, volatile, and restrict). > > "unsigned" is not a qualifier. There is no part of the standard that > > guarantees that a pointer conversion from "int*" to "unsigned int*" will > > not result in an invalid value. > > (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.)
I don't see why representations of pointers would matter here. What's important is the representations of int and unsigned int (and unions, in other examples), not pointers. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
