Re: Side effect of r35304: "Use GSSelectorTypesMatch() for types comparison..."

[Ivan Vučica]

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 <ivucica@gmail.com> 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
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

-- 
Ivan Vučica - ivan@vucica.net