[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Blender 2.37, spec and srpms

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:

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

  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 &

Does anyone see a problem with this?


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]