On Sat, 24 Jul 2010, Adam Light wrote:

> So SOCKET is a 64 bit type in 64 bit windows.

Ouch. I've started out now by documenting this properly where this most
notably might hurt users. I'll have to ponder a bit on how we adapt to this
fact the best way, and if we may have other bugs internally due to this
anomaly.

> Yes, changing line 154 of curl_addrinfo.c from
> ca->ai_addrlen = ai->ai_addrlen;
> to
> ca->ai_addrlen = (curl_socklen_t)ai->ai_addrlen;
> does eliminate the warning.
>
> It looks like ai->ai_addrlen shouldn't ever be very big, so this should be
> ok.

Yes, and thanks. I'll be silencing the warning that way.

>> Is your read() returning anything else but ssize_t ? If not, what exactly
>> does your ssize_t get typedef'ed to in the libcurl headers? If it does,
>> what _does_ your read() return?
>>
> Actually I think the problem is with the last parameter to the read()
> function. bytestoread is a size_t, which on Win64 is an unsigned __int64.
> However the last parameter of read() is an unsigned int type (see
> <http://msdn.microsoft.com/en-us/library/wyssk1bs(VS.90).aspx>).

I see. The problem is of course that we don't have a proper define for what
type read() wants so we can't typecast to anything sensible... And we can't
seem to be using the RECV_TYPE_ARG3 either as for some reason the Windows
recv() function doesn't use the same type for the length argument as read()
(signed int vs unsigned int).

I don't have a good fix for this warning just now. :-/

> Though it's possible that someone would #define CURL_MAX_WRITE_SIZE to
> something much larger.

It's not really likely to be very big, and if needed we could just document it
to not work if made larger than N bytes where N would be suitably insanely
large.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html