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
