On 9/7/06, Pekka Pessi <[EMAIL PROTECTED]> wrote: > Could you please check if win64 compiler still complains about size_t > truncation?
I forgot to tell about ai_addrlen. ai_addrlen or tp_addrlen are not yet casted explicitly to socklen_t, so you get warnings there. --Pekka > > > -----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 > > -- > Pekka.Pessi mail at nokia.com > -- Pekka.Pessi mail at nokia.com ------------------------------------------------------------------------- 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
