On Apr 13, 2008, at 10:32 AM, Michal Marek wrote:
> David Shaw napsal(a):
>> I think the recent changes to curl_easy_setopt may have had some
>> fallout. GPG does stuff like this:
>>
>> 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".
>>
>> It's arguable what the right thing to do here is. Certainly I can
>> just
>> cast that bitfield item to an int, but there may be other code out
>> there
>> that does similar things. Plus, there is a reasonable expectation
>> that
>> a bitfield item can be used as an int (it is, after all, an unsigned
>> int, albeit a very small one).
>
> 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.

The issue is the bit-field, not whether the bits are int or long.
This fails in the same way:

struct
{
        long myflag:1;
        long myotherflag:1;
        long verify_peer:1;
} flags;

curl_easy_setopt( curl, CURLOPT_SSL_VERIFYPEER, flags.verify_peer );

In that case, I am indeed passing a long.

> BTW, can you point me to the code doing this? gnupg-2.0.9 builds fine
> here...

See http://bugs.sourcemage.org/show_bug.cgi?id=14446

David
Received on 2008-04-13