Blender 2.37, spec and srpms

[Toshio Kuratomi]

If you're seriously interested in blender, there are several open bugs
in bugzilla.redhat.com that you might want to check.

This one has logs for x86_64 failure against 2.36:
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156498

I've just added a patch that allows blender to compile with one area
that I'm uncertain of. There are two places in the code where blender
hashes pointers to make a key for a map.  Here's one from
blender/source/gameengine/Expressions/KX_HashedPtr.cpp:

  unsigned int KX_Hash(unsigned int inDWord)
  {
    unsigned int key = inDWord;
    key += ~(key << 16);
    key ^=  (key >>  5);
    key +=  (key <<  3);
    key ^=  (key >> 13);
    key += ~(key <<  9);
    key ^=  (key >> 17);
    return key;
  };
  unsigned int CHashedPtr::hash() const
  {
    return KX_Hash((unsigned int) m_valptr);
  }

The cast in CHashedPtr::hash() needs to be changed to (unsigned long) in
order to compile on x86_64.  The question is what to do with that value
when it enters KX_Hash().  Should the algorithm always return a 32bit
value or should it return a 64 bit value on 64 bit platforms?

It looks like the hash is only used to transform a pointer into a good
key for a map class.  So the hash function's purpose is to produce an
even distribution of keys from the pointers it's fed.

I've implemented the following fix:

  -       return KX_Hash((unsigned int) m_valptr);
  +       return KX_Hash((unsigned int)((unsigned long) m_valptr &
0x00000000FFFFFFFF));

Does anyone see a problem with this?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20050605/0d885e77/attachment.sig>