• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Need localization-proof method of transporting dates.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Need localization-proof method of transporting dates.


  • Subject: Re: Need localization-proof method of transporting dates.
  • From: Michael Ash <email@hidden>
  • Date: Sun, 5 Apr 2009 14:30:37 -0400

On Sun, Apr 5, 2009 at 11:58 AM, Uli Kusterer
<email@hidden> wrote:
> On 05.04.2009, at 17:15, Michael Ash wrote:
>>
>> Note that, as far as I know, there is no guarantee that -hash will
>> return the same value for the same object across runs of your program.
>
>  Good point. It's not too likely that a hash would be different between
> launches (after all, a hash is of the value, there's no sense in including
> the pointer, because pointer comparisons are already fast and don't need a
> hash), but it's surely possible that the algorithm could change betwen OS
> releases or include some element unique to a particular machine to take
> advantage of hardware features or the like.

You can't include the pointer in the hash at all unless your only test
for equality is object identity. But the algorithm could change across
launches for other reasons. Maybe they dump in a random value just to
keep things interesting, after all.

As for changing across OSes, this definitely actually happens. For
example, NSAttributedString hashing changed on Tiger to hash more
attribute values. I also recall that NSString's hash method was
changed at one point, but I can't find any discussion of this.

>  Also, it's very likely the hash isn't the same between the 64-bit and
> 32-bit runtimes. After all, it's an NSUInteger, which is an unsigned long
> long on 64 bit, but an unsigned long on 32 bit. If you have twice as many
> bits available for storing your hash, the runtime is likely generating more
> widely distributed hashes to take advantage of that.
>
>  In fact, that sounds like a much more likely source of the bug than an
> issue with serializing NSDate. Is your app compiled for 64 bit? Is one of
> the Mac CPUs in question 32-bit and the other 64-bit?

It's also quite likely to be different between PPC and x86
architectures, since there's no need for the hash value to remain
constant between them, and plenty of opportunity for it to change.

Mike
_______________________________________________

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

References: 
 >Re: Need localization-proof method of transporting dates. (From: Greg Guerin <email@hidden>)
 >Re: Need localization-proof method of transporting dates. (From: Graham Cox <email@hidden>)
 >Re: Need localization-proof method of transporting dates. (From: Michael Ash <email@hidden>)
 >Re: Need localization-proof method of transporting dates. (From: Uli Kusterer <email@hidden>)

  • Prev by Date: Re: Beachball on Lengthy Task
  • Next by Date: Re: Automating reading classes with InterfaceBuilder
  • Previous by thread: Re: Need localization-proof method of transporting dates.
  • Next by thread: Re: Need localization-proof method of transporting dates.
  • Index(es):
    • Date
    • Thread