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
-------------------------------------------------------------------------
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
