[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Side effect of r35304: "Use GSSelectorTypesMatch() for types compari
From: |
Jens Ayton |
Subject: |
Re: Side effect of r35304: "Use GSSelectorTypesMatch() for types comparison..." |
Date: |
Sun, 19 Aug 2012 23:59:41 +0200 |
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