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

[Jens Ayton]

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