On Jun 5, 2008, at 11:26 AM, Graham Cox wrote:
OK, I found the culprit. As suspected, it has nothing to do with
sheets.
I'm using a sorting function with NSMutableArray:
static int cmpColorStops (DKColorStop* lh, DKColorStop* rh, void
*context)
In my original code, the sort function was declared:
static int cmpColorStops (id lh, id rh, void *context);
Which compiled just fine. Problem is that rp = [rh position]; was
returning some utterly bogus value, because the assumption was an
int(?) was being returned from the anonymous object type, not a
float. Specifically typing the parameters to the sort function
removes this ambiguity. As it turns out, the bogus values did sort
correctly, because their relative values were in the right order,
which is why I've never spotted this before. What I'm still not
clear about is how this can cause memory corruption, because a float
and an int are the same size. I'm also not sure why it was OK on
Tiger (though possibly just due to chance layout differences in
memory).
While float and int are the same size they are returned from functions
in different registers (on both ppc and intel). If the calling
function expects a float returned type but an int is returned instead
the calling function will certainly get a bogus value. In addition it
may save and restore the wrong registers and not save and restore a
register that needs to be preserved, resulting in memory corruption.
The 'may not respond to selector' warning might be expected in cases
like this.
Normally assigning a float to an int is perfectly legal so no warning
should be generated on that account. Perhaps if there were a warning
indicating that two different return types are possible it might help
in cases like this.
Further thought: could it be that in Tiger, no Cocoa objects declare
a method called -position, so it correctly picked up my private
object's method signature. In Leopard, both CALayer and
NSPositionalSpecifier declare a -position method, so the compiler is
assuming one of those for the anonymous objects. CALayer's version
returns a CGPoint, which being larger than a float could explain the
memory corruption?
I've actually run into almost the same bug before and it was equally
hard to track down. It would be useful if there was a compiler
warning for an implicit cast or mismatch of return type in cases
like this, because otherwise they are devilishly hard to spot. If
there is such a warning, please tell me, so I can spare myself
future hunts of this kind (this one has taken a solid 11 hours to
find and fix, primarily because cause and effect were completely
unrelated!)
Thanks to everyone who pitched in - very grateful.
cheers, Graham
--
Brian Stern
[EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
