On Apr 14, 2008, at 3:30 AM, Michal Marek wrote:
> Michal Marek wrote:
>> David Shaw napsal(a):
>>> struct
>>> {
>>> unsigned int myflag:1;
>>> unsigned int myotherflag:1;
>>> unsigned int verify_peer:1;
>>> } flags;
>>>
>>> curl_easy_setopt( curl, CURLOPT_SSL_VERIFYPEER, flags.verify_peer );
>>>
>>> That worked in the past, but now fails with "error: 'typeof'
>>> applied to
>>> a bit-field".
>>>
>> 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. And passing a bitfileld here was a bad idea in first
> place.

Not at all. I think this is one of the (few) good uses for a
bitfield. GPG has a bazillion on/off options. Bitfields let us store
them in a single bit (which they are), rather than burning 32 or 64
bits for each. They promote to int on function calls, so from the
outside perspective, how is it any different than using ints? They're
not as fast to access as a full int or long on some platforms, but
that's not usually a factor for on/off options. The main issue with
bitfields is that the "typeof" gcc builtin doesn't work with it, so it
breaks the type-checking macro that curl is using.

Never mind that though. If I need to cast, I'll cast. I think the
real issue here is passing int vs long. I know the documentation says
long, but there is a bundle of sample code that says otherwise,
including (amusingly enough) the curl command line program itself.
There is likely a large amount of code using libcurl out there that is
wrong.

It sounds like there is a hidden gotcha awaiting these people.

David
Received on 2008-04-14