cURL / Mailing Lists / curl-library / Single Mail



From: Julien Chaffraix <>
Date: Sat, 30 Jul 2011 11:55:54 -0700

> The 0/1/2 approach was already being used by CURLOPT_SSL_VERIFYHOST and
> CURLOPT_FTP_CREATE_MISSING_DIRS, so I just grabbed it from there.

Indeed, however I usually prefer named constant as it makes the code
more readable. This is likely something we will want to change someday
for those 2 options.

>> #define NO_DELEGATION 0L
>> would make the API, documentation and code more readable.
> Considering all the code that includes <curl/curl.h>, I do not think
> NO_DELEGATION is a suitable name of macro to be used at global scope.
> What about the following defines?
> #define CURLGSSAPI_DELEGATION_FLAG         (1<<1)
> It would be consistent with the CURLSSH_AUTH_* options.  Moreover, it allows
> to combine both flags.  Some web pages suggest that such a combination could
> be useful:

I just mentioned some nits without thinking about the better way to
implement it (you've also seen lately how good I was at naming
stuff...). Your names are better and won't clash with anything else!

>> Maybe it could be a new feature as this is determined at compile time.
> What would be the use case?  We are running out of bits on CURL_VERSION_*.

I just thought it was an easy way to expose whether your library
supports GSS_C_DELEG_POLICY_FLAG or not instead of having to look into
your GSS API headers (with which you compiled the lib). There may be a
way to expose the information using some of our generated headers. It
is valuable IMHO to have a simple way of knowing that.


List admin:
Received on 2011-07-30