https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #28 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 20 May 2015, gil.hur at sf dot snu.ac.kr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 > > --- Comment #27 from Chung-Kil Hur <gil.hur at sf dot snu.ac.kr> --- > (In reply to Chung-Kil Hur from comment #26) > > Thanks for the detailed explanations. > > > > > The C standard only guarantees that you can convert a pointer to uintptr_t > > > and back, it doesn't guarantee that you can convert a modified uintptr_t > > > back to > > > a pointer that is valid. > > > > > > Thus, doing (int *)((xp + i) - j) is invoking undefined behavior. > > > > > > > I didn't know about this rule. > > I thought this cast is valid because "(xp+i)-j" is even "safely-derived". > > > > Could you give a reference for that rule in the standard? > > > > Thanks! > > It seems that the following rule might be the one. > > ================================= > 7.20.1.4 Integer types capable of holding object pointers > > The following type designates a signed integer type with the property that any > valid pointer to void can be converted to this type, then converted back to > pointer to void, and the result will compare equal to the original pointer: > intptr_t > > The following type designates an unsigned integer type with the property that > any valid pointer to void can be converted to this type, then converted back > to > pointer to void, and the result will compare equal to the original pointer: > uintptr_t > These types are optional. > ================================= Yes, that's the one I remember. > Right. This does not say that we are allowed to cast a modified integer back > to > a pointer. > > What I remember might be from the C++ standard, where "safely derived" > integers > are allowed to be cast back to pointers. > Umm. This might also be implementation-defined. Yeah, what is "safely derived" is the question here (you might not break the dependency chain in any (non-)obvious way).
