On Mon, 14 Apr 2008, Michal Marek wrote:

>> Yes, but the docs say that you should pass a long here, not int. For the
>> time being, the macro allows int, too, because insisting on long would
>> cause too much warnings almost everywhere. But I think in such a corner
>> case it's really the application that should be fixed.
>
> I mean, it's a pity that passing a bitfield to the curl_easy_setopt
> macro generates code that gcc doesn't accept, but I don't see a way to
> work around this.

Right, and I think we should add an #ifdef or similar on a define (that isn't
__CURL_TYPECHECK_GCC_H) to allow applications to specificly disable the type
check. I mean, this code probably still works fine built without the type
check and it seems silly to not provide a work-around for this problem then.

I say probably since it may very well have problems passing a zero bitfield on
a platform doing 64bit longs.

> And passing a bitfileld here was a bad idea in first place.

I am of the opinion that C bitfields in general are evil and are best avoided
in all code, for this and other reasons! AND, OR and and shifts are better
explicit. Not that this is particularly relevant here! ;-)

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html