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

From:

Ivan Vučica

Subject:

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

Date:

Mon, 20 Aug 2012 11:42:51 +0200

On Mon, Aug 20, 2012 at 10:06 AM, David Chisnall <theraven@sucs.org> wrote:

It sounds like you're spending a lot of effort working around obscure corner cases that almost certainly will never appear in the wild.

It wasn't a lot of time, actually, at least until this problem cropped up :-)

CGPoint and NSPoint are supposed to be identical and code is allowed to cast between them and, more importantly, lots of existing code casts between arrays of NSPoint and arrays of CGPoint.

That's great, but despite it being the same, I still haven't seen this guarantee in the docs. In fact, existence of NSPointFromCGPoint() and NSPointToCGPoint() means it shouldn't be relied upon.

I do concur that because casting between these types is widespread, this isn't much of a big deal. But, should we in the future go down the path of treating separate structs as the same type just because they have the same in-memory layout? Why would @encode even include the type name, then? Why would NSValue provide access to objCType? Am I forbidden from comparing these and making an informed decision on how to treat a data type based on that? What if NSSize was supposed to be animated or treated differently from NSPoint - should I lose the information that something was a NSSize just because it has the same in-memory layout?

I'd love to work around this, but since I'm dealing with KVC and KVO, I can't easily skip using NSValues to store structs and implement something of my own.

Plus, it worked correctly, and now it's broken. :-)

C structs are just blobs of memory. If they are structurally equivalent then, for all practical purposes, they are interchangeable.

In any case, there's still a bug, even if the original issue is about to be dismissed. (I still consider that if I put one thing into the NSValue, I should be getting the same thing out - even if the memory layout is the same. Otherwise, let's also patch @encode in clang and gcc.)

If 'from' contains a NSValue with a 'NSPoint' in it (or something that claims to be an NSPoint created through

from = [NSValue valueWithBytes: &fromPt objCType: @encode(CGPoint)];

the following still doesn't work and sets only the .x member:

CGPoint fromPt = { 0 }; [from getValue:&fromPt];

I'm sure it's a problem with getValue: since removing initialization of fromPt means I end up with junk in .y.

So, the problems: I have a NSValue with a CGPoint in there, I can't tell it's a CGPoint, and fetching it results in a failure. :-)