Patch attached that does the double casting, as long as you are sure this is safe, works fine for me.
Mike > -----Original Message----- > From: Pekka Pessi [mailto:[EMAIL PROTECTED] > Sent: Monday, September 04, 2006 8:04 AM > To: Michael Jerris > Cc: [email protected]; Kai Vehmanen > Subject: Re: [Sofia-sip-devel] MSVC detected 64 bit issues. > > On 8/31/06, Michael Jerris <[EMAIL PROTECTED]> wrote: > > Attached is a patch that I think addresses the hash_value_t for msvc 64 > > without breaking anything else, for your review. The first ifdef may > > need to be changed to #if _MSC_VER >= 1400 depending on how VC 6 and/or > > mingw behaves on that block of code, unfortunately I don't have those to > > test against. > > I don't think we use hash_value_t to store pointers anywhere. It is > used, however, when converting a pointer to a hash value, like > > htable_hash(hash_value_t x) > { > return &table[x % size]; > } > > and then hashing function is used like > > htable_hash((hash_value_t)pointer) > > I suppose the WIN64 compiler issues a warning when htable_hash is > called because a pointer is casted to a narrower integer. The warning > is warranted, but the only problem here is hash table will be slightly > skewed (if we have, say, a hash table of 1 million entries, the first > slot is occupied with 0.002 % bigger probability than the last slot). > > I hope we can do away casting the pointer twice like > > htable_hash((hash_value_t)(uintptr_t)pointer) > > which will make the intention clear to the compiler and silence the > warning. > > I guess optimal fix would be to give hash_value_t as a part of > template instantation macros: if a wide hash_value_t is needed, we > could pass it, but otherwise, we could do with a narrow one. > > > Also, please let me know how you would like to proceed on > > the other part of the patch for addressing the other 64bit issues. On > > closer review, we may want to have some typedefs similar to this block > > and use that for the casting on the pointer math that I replaced with > > size_t in the previous patch. > > I'm going through your patch and trying to figure out if there are > some real problems (as opposed of an overflow if an URL is longer than > 2 GB). > > The only thing really breaking things is the socklen_t/size_t > mismatch, especially in struct addrinfo. Depending on the IPv6 support > flavor (RFC 2133 v. RFC 3493), struct addrinfo field ai_addrlen is > either size_t (potentially 64 bit) or socklen_t. > > Now we have the msg_addrlen() function - it was marked as deprecated, > but I never got around to remove it from the API - which actually > returns pointer to the ai_addrlen field inside msg_t object. So, on > 64-bit systems with RFC 2133 struct addrinfo we actually take a > pointer to size_t, a 64-bit int and treat it as a pointer to > socklen_t, 32-bit int. With little-endian processors, it works fine > unless you got a struct sockaddr longer than 4GB, butit does not work > at all if the 64-bit processor is big-endian. > > Kai, what about removing the msg_addr() and msg_addrlen() - they are > not used by anything inside library nor they are tested anymore, and > they have been marked as deprecated since 1.11.8... > > -- > Pekka.Pessi mail at nokia.com
msvchashvalue2.patch
Description: msvchashvalue2.patch
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Sofia-sip-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
