On Sep 5, 2009, at 19:59, Adam R. Maxwell wrote:
>
> On Sep 5, 2009, at 10:43 AM, Christiaan Hofman wrote:
>
>> And now I know why PDFKit doesn't work on 64 bits. They are really
>> messing up writing to ivars. Remember they use weird private classes
>> to hide the ivars. This means they must be using runtime functions to
>> read/write to these ivars, because these private classes don't have
>> accessors.
>
> Is it really using runtime functions? I've done this by
>
> @class PublicClassIvars;
>
> @interface PublicClass : NSObject
> {
> @private
> PublicClassIvars *_ivars;
> }
> @end
>
> /// In the implementation of PublicClass, declare the ivars
>
> @interface PublicClassIvars : NSObject
> {
> @public
> id _representedObject;
> NSInteger _type;
> }
> @end
>
> and you can access it in PublicClass by
>
> NSInteger t = _ivars->_type;
> id obj = _ivars->_representedObject;
>
> Basically this is the Pimpl idiom, using an object instead of an
> opaque pointer, and it's pretty easy unless you have object types
> and need to manage memory. It would be interesting to set a
> breakpoint on the objc runtime functions and see if PDF Kit is
> calling them. If so, that's really the hard way of doing it; you
> might as well use indexed ivars!
>
That sounds very dangerous, especially in view of Objective-C 2.0 and
64 bits. Moreover, the compiler complains very hard, and the docs say
not to use @defs in 64-bits. Remember they're making objects more and
more opaque. Anyway, PDFKit for sure does it the hard way by adding
all those private ivar wrapping objects.
>> However, they're doing it wrong: they're writing the values
>> for the ivars to the /addresses/ of the ivars rather than the ivars
>> itself! So when they write or read something like an integer, they
>> get
>> into problems on 64-bits because they're not pointer-size anymore.
>> This is absolutely incredible. Bug filed.
>
> Wow. It sounds like you're on the right track, anyway, if you have
> a workaround for it. So the problem occurs with types like unsigned
> int or int, not NS(U)Integer, right? Can you tell if it's trashing
> nearby variables when writing?
Actually I was wrong. A problem is that object_getInstanceVariable is
extremely confusing (and not just to me). It assumes an ivar has type
void*, which means it can only be used for id-typed ivars. For non-id
ivars you need to get to the ivar using ivar_getOffset, which I think
is really lame.
However, at least in this case, I really get the impression that this
is indeed the mistake PDFKit is making. Because when I do it wrong, I
get exactly the same crash log. And indeed, my workaround does work.
And when I use ivar_getOffset with the proper type of "unsigned int"
the workaround also works. So also part of the problem is that they
forgot to change the type of dashCount to NSUInteger, lame.
Christiaan
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
