On Saturday 30 July 2011 20:55:54 Julien Chaffraix wrote:
> 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.

I completely agree. Another use case would be to abuse one of the new defines
to #ifdef the code that calls ..._setopt(..., CURLOPT_GSSAPI_DELEGATION, ...)
without adding a new autoconf check. We cannot use CURLOPT_GSSAPI_DELEGATION
directly as it is an enumeral constant, not a define. I have already used
the approach in the xmlrpc-c patch, which is now pending inclusion of the
libcurl patch:

http://sourceforge.net/mailarchive/message.php?msg_id=27867164

> > 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_NONE         0
> > #define CURLGSSAPI_DELEGATION_POLICY_FLAG  (1<<0)
> > #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:
> >
> > http://www.h5l.org/blog/index.php/page/2/
>
> 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!
>
> >
> > 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.

Well, my point was that the application did not have a choice anyway. If it
needs GSS_C_DELEG_POLICY_FLAG and the feature is not available, it simply has
to fail. A warning is produced so the user has some clue where to look for
a solution.

I am not against adding a feature for this, but do not think this should be
considered a blocker for upstream inclusion. It can be introduced anytime
later. We are currently under pressure since the security advisory has
broken some stuff that used to work before. So I would prefer to just fix
the regression now and then tweak all the details that do not directly affect
the proposed API extension.

Kamil

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-07-30