On Tue, 17 Apr 2012, Yang Tse wrote:

> CURLAUTH_ONLY was introduced Nov 11 2010 with commit 86367422 defined as
> (1<<31) in curl.h
>
> When building curl with Sun compiler it generates following compiler
> warning...
>
> "src/tool_setopt.c", line 63: warning: integer overflow detected: op "<<"
>
> Compiler warning is relevant. Current CURLAUTH_ONLY definition is not
> a valid 32bit signed integer.

Right. It needs to be forcibly told to be unsigned to work properly...

> Additionally CURLAUTH_ONLY is not used at all in libcurl's code base. So
> unless libcurl's code is checking somewhere that an 'auth' variable is
> negative, I believe that CURLAUTH_ONLY it is not even working.

CURLAUTH_ONLY is - if I may say so - rather cleverly added in that it simply
needs to be an additional bit that is never checked. The point being that it
would be used by applications like:

   CURLAUTH_BASIC | CURLAUTH_ONLY

It would cause libcurl to try without auth and then only allow Basic to be
used. Therefore, the CURLAUTH_ONLY bit is never explicitly checked for or used
by libcurl code.

> Another fact is that libcurl 'auth' variables holding CURLAUTH_*
> bitmasks have a 'long' data type. This may alleviate the situation on
> systems on which sizeof(long) > sizeof(int) in case CURLAUTH_ONLY were
> to be used inside libcurl's code. But there are a bunch of platforms
> on which 'int' and 'long' have the same size.

I'm not sure that is in fact a problem...

> Do we get rid of CURLAUTH_ONLY, do we type cast to 'unsigned int' all
> CURLAUTH_* definitions in curl.h, do we modify CURLAUTH_ONLY definition to
> (1<<30), or we do something different?

We should probably assume that there by now is an application or two that use
it, so we should try to fix it in a way that is least likely to break existing
apps.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html