Jamie Lokier wrote:
> David Shaw wrote:
>> $ gcc bar.c -m64
>> $ ./a.out
>> int is 4 bytes and long is 8 bytes
>> -1 == 4294967295
>> (long)-1 == -1
>
> And your example proves it... bet nobody took that seriously before!
>
>> There is probably a heck of a lot of code using libcurl that doesn't
>> cast constants to long...
>
> Fortunately, the new type checker would catch them if it complained
> about "int" arguments.

Jamie,

if you think that the typechecker really should warn about int and if
the others on this list agree, then let's do it for the next release.
I've never said that passing int in place of long to curl_easy_setopt()
was good practice, I just thought that for the first try, the
typechecker should perhaps be more relaxed.

And btw, if we want to warn about int, we should clean up the curl
application and the examples first.

> Or maybe it can even generate the cast?
>
> Portable way to do that might be:
>
> #define curl_easy_setopt(handle, cmd, arg) \
> curl_easy_setopt(handle, cmd, curl_easy_setopt_cast(cmd) (arg))
>
> #define curl_easy_setopt_cast(cmd) curl_easy_setopt_cast_2(cmd)
> #define curl_easy_setopt_cast_2(cmd) curl_easy_setopt_cast_##cmd
>
> #define curl_easy_setopt_cast_CURLOPT_MAXREDIRS (long)
> // ... one macro for each option

Uh, I'm not sure. First, "cmd" might not necessarily be the one of the
CURLOPT_ constants (i.e. it might not be good material for pasting),
second casting anything to long doesn't magically fix broken code (e.g.
string instead of integer, or so). And if we only do it as part of the
typechecker, then we would actually be silently working around broken
code for one particular platform (gcc >= 4.3), instead of making the
user fix the code for all platforms. In other words "if you're using new
gcc, then we know what you mean" is not the way to go IMHO.

Michal
Received on 2008-04-14