On 9/4/06, Michael Jerris <[EMAIL PROTECTED]> wrote: > Patch attached that does the double casting, as long as you are sure > this is safe, works fine for me.
No warning? I applied your patch to the main repository. I have now added types called isize_t, usize_t, and issize_t. When maintaining binary compatibility, they are int, unsigned int and int, respectively. On WIN64 or if configuring with --disable-size-compat, they are defined as size_t, size_t or ssize_t, respectively. I think we are now also using su_socket_t (nee SOCKET on win32/64) all the places where sockets are handled. I have tried to use size_t when it makes sense and I think I now use size_t on all the places that your earlier patch addressed. There are some things that I did not catch in your patch, however. Does _snprintf return a ssize_t on WIN64? The prototype on the web page uses int as return value: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt__snprintf.2c_._snwprintf.asp Could you please check if win64 compiler still complains about size_t truncation? Unfortunately, my 64-bit boxes have so old gcc that it does not give very constructive warnings. Could you also try to compile all the test programs and run the win32/check.cmd, preferably under some kind of memcheck tool? --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 ------------------------------------------------------------------------- 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
