curl-library
Re: VC9 libcurl compiler warnings (64 bit only)
Date: Tue, 31 Aug 2010 17:01:25 +0200 (CEST)
On Mon, 30 Aug 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.
>
> Since this seems like it could cause a crash, it would be good to get it
> fixed. Is there anything I can do to help out here?
It can indeed cause a crash if you're unlucky. I don't know the exact changes
for that as it depends on how win64 actually uses the socket pointers.
What to do: We need to introduce a new CURLINFO_* type that can return a
socket portably. long or double good aren't enough. There needs to be an
explicit 64bit or curl_socket_t type to reutrn. Then we need to introduce a
CURLINFO_LASTSOCKET replacement and deprecate the old one with a large warning
in the docs.
64bit would make it slightly more generic as that might be useful for other
stuff in the future, curl_socket_t will be most accurate and lead to less
typecasting and warnings in the application.
> [Regarding .\file.c(556) : warning C4267: 'function' : conversion from
>> 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...
This warning will just have to remain until we introduce a set of defines for
the read argument types and can typecast them properly.
> The new warning is:
> .\gopher.c(144) : warning C4267: '=' : conversion from 'size_t' to
> 'int', possible loss of data. The code is:
> j = strlen(newp);
>
> We get this warning because strlen() returns a size_t, but j is an integer.
Right, that's a warning on many other platforms as well. We need to fix it.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.htmlReceived on 2010-08-31