David Shaw wrote:
> On Apr 14, 2008, at 3:30 AM, Michal Marek wrote:
>> Michal Marek wrote:
>> 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.
...

Note that I didn't say that _using_ bitfield in gpg was a bad idea, but
_passing_ it [to a variadic that expects a long] was.

> Never mind that though. If I need to cast, I'll cast. I think the
> real issue here is passing int vs long.

Yes. I agree that breaking gpg build isn't nice, but the code already
relied on undefined behavior. Therefore I think that this is a corner
case and the call should be fixed to pass a long. New libcurl version
will likely provide a define to skip the typechecking macro, but adding
a long cast or flags.someflag ? 1L : 0L is still the preferred solution
IMHO.

> 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.

Yes, this is a known issue...

Michal
Received on 2008-04-14