Re: Correct use of CFArraySortValues context parameter
Re: Correct use of CFArraySortValues context parameter
- Subject: Re: Correct use of CFArraySortValues context parameter
- From: Ken Thomases <email@hidden>
- Date: Sat, 07 Dec 2013 08:35:05 -0600
On Dec 7, 2013, at 7:49 AM, Markus Spoettl wrote:
> This was the invocation:
>
> int context = kCFCompareCaseInsensitive;
> CFArraySortValues(keyArray,
> CFRangeMake(0, count),
> (CFComparatorFunction)CFStringCompare, &context);
>
> After reading through CFArraySortValues and CFStringCompare documentation it's clear (to me anyway) that the context is used incorrectly. The documentation doesn't imply it will dereference the context pointer at any point. That means that CFStringCompare will be called with the pointer value instead of the contents of that address.
>
> Changing it to
>
> CFArraySortValues(keyArray,
> CFRangeMake(0, count),
> (CFComparatorFunction)CFStringCompare,
> (void*)kCFCompareCaseInsensitive);
>
> made the leak go away. I can only assume that the author never realized the array wasn't going to be sorted the way he intended.
>
> Can anyone tell me if the latter use of CFArraySortValues() is correct?
It is. Your analysis is correct.
> It doesn't feel right to cast an int option to (void *) but the documentation simply doesn't say it will pass on a dereferenced value.
The docs for CFArraySortValues() describes the context parameter as "[a] pointer-sized program-defined value". It is declared as a pointer only to guarantee that it's large enough to hold a pointer even on architectures where a pointer is larger than, say, an int. But semantically, it's just a "value". It may have been better for Apple to have used uintptr_t.
> The fact that the leak went away tells me I'm on the right track.
Well, I can't explain why passing the pointer to the context variable would have caused a leak. In theory, CFStringCompare() would simply have interpreted it as a option bit mask with an arbitrary variety of options set. I wouldn't expect any such options to cause a leak.
But you're right that the original call was incorrect.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden