GSS IOV flags

[Luke Howard]

Fixed in r21489.

typedef struct gss_iov_buffer_desc_struct {
     OM_uint32 type;
     gss_buffer_desc buffer;
} gss_iov_buffer_desc, *gss_iov_buffer_t;

#define GSS_IOV_BUFFER_TYPE_EMPTY           0
#define GSS_IOV_BUFFER_TYPE_DATA            1   /* Packet data */
#define GSS_IOV_BUFFER_TYPE_HEADER          2   /* Mechanism header */
#define GSS_IOV_BUFFER_TYPE_MECH_PARAMS     3   /* Mechanism specific  
parameters */
#define GSS_IOV_BUFFER_TYPE_TRAILER         7   /* Mechanism trailer */
#define GSS_IOV_BUFFER_TYPE_PADDING         9   /* Padding */
#define GSS_IOV_BUFFER_TYPE_STREAM          10  /* Complete wrap token  
*/
#define GSS_IOV_BUFFER_TYPE_SIGN_ONLY       11  /* Sign only packet  
data */

#define GSS_IOV_BUFFER_FLAG_MASK            0xFFFF0000
#define GSS_IOV_BUFFER_FLAG_ALLOCATE        0x00010000  /* indicates  
GSS can allocate */
#define GSS_IOV_BUFFER_FLAG_ALLOCATED       0x00020000  /* indicates  
caller should free */

#define GSS_IOV_BUFFER_TYPE(_type)          ((_type) &  
~(GSS_IOV_BUFFER_FLAG_MASK))
#define GSS_IOV_BUFFER_FLAGS(_type)         ((_type) &  
GSS_IOV_BUFFER_FLAG_MASK)

-- Luke

On 17/12/2008, at 3:59 AM, Tom Yu wrote:

> Love expressed a desire to combine the flag and type fields of
> gss_iov_buffer_desc_struct, but said he was willing to live without
> it.  Looking at SSPI, the flag and type fields are combined.  Does
> this change anybody's mind in favor of Love's proposed change?
>
> If there is an existing API out there (SSPI), and we can make our
> implementation look more like SSPI without causing problems for us, I
> think we should.  Does anyone believe that making this change to align
> more closely with SSPI will cause problems?
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>

--
www.padl.com | www.fghr.net