I'm actually not sure that there is any code where they might be different... but they ARE different types and I wouldn't like to treat them otherwise :-)
Some further info on this bug. It's interesting to note that as I was patching the code simply pulling out the bytes from NSPoint-holding NSValue and storing them in a CGPoint produced a structure in which the y coordinate didn't get filled up! It contained either junk from the memory, or a zero if I properly initialized it. If I used -pointValue and NSPoints, everything worked. Hence, I left the workaround in the code, although previously it wasn't necessary. sizeof() doesn't seem to differ, meaning there doesn't seem to be any alignment bytes that would account for one struct having a different in-memory layout. All in all, I'm very confused right now. But, no matter what, this is (sadly) incorrect behavior on part of -base, since Foundation, if it obtains a CGPoint, simply keeps a CGPoint in there. To see the workaround, look at CABasicAnimation's -calculatedAnimationValue:onLayer: http://svn.gna.org/svn/gnustep/libs/quartzcore/trunk/Source/CAAnimation.m On Sunday, August 19, 2012, Jens Ayton wrote: > On Aug 19, 2012, at 23:25, Ivan Vučica <[email protected] <javascript:;>> > wrote: > > > > I'm currently considering this a bug, since the above behavior differs > from Cocoa's. Under Cocoa, if I request to store a CGPoint inside a NSValue > using @encode(CGPoint), that's exactly what I get out. However, with > GNUstep, if I store a CGPoint into a NSValue, I get a NSPoint out of it, > wreaking havoc with my current code that handles case when these structs > don't have equal members. > > I'm mildly curious as to when this might happen. In Cocoa, there are three > cases: > > * For 64-bit targets, NSPoint is a typedef for CGPoint, which uses doubles. > @encode(NSPoint) = {CGPoint=dd} > * For 32-bit targets with NS_BUILD_32_LIKE_64=1, and iOS, NSPoint is a > typedef > for CGPoint, which uses floats. @encode(NSPoint) = {CGPoint=ff} > * For 32-bit Mac targets without NS_BUILD_32_LIKE_64, NSPoint is a separate > struct which uses floats, and is structurally identical to CGPoint. > @encode(NSPoint) = {_NSPoint=ff}, @encode(CGPoint) = {CGPoint=ff} > > The equivalents hold for *Size and *Rect. > > > > who knows what other problems might this change trigger in third-party > code. > > You're pretty much in that territory already if you have cases where > CGPoint and NSPoint are structurally incompatible. Modern code will assume > they're the same type, while old code is quite likely to type-pun between > them. > > > -- > Jens Ayton > > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] <javascript:;> > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > -- Ivan Vučica - [email protected]
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
