[PATCH 2/4] Utility functions to move allocations fromk5buf/krb5_data to gss_buffer_t

[Kevin Wasserman]

Thanks, I will make these fixes.  The inability to invalidate is
yet another reason to add a gss alloc type to k5buf.
Though I'd also argue that assuming code is smart is never
a good idea, no matter how smart the coder is.

-----Original Message----- 
From: Greg Hudson
Sent: Thursday, October 06, 2011 1:42 PM
To: Sam Hartman
Cc: Kevin Wasserman ; krbdev at mit.edu
Subject: Re: [PATCH 2/4] Utility functions to move allocations 
fromk5buf/krb5_data to gss_buffer_t

These helper names are much too long.  Since they have no external
linkage and aren't public, they don't need namespace prefixes.  I
suggest "k5buf_to_gss" and "data_to_gss".

Both helpers need explanatory comments to note that they invalidate the
source objects.

Don't muck with the internals of a k5buf in the k5buf helper.  There's
currently no API to invalidate a k5buf (it's assumed that the caller is
smart enough to stop using it if it takes ownership of the data
pointer), so just don't do that for now.

In the krb5_data helper, setting input_k5data = NULL does nothing.  Set
*input_k5data = empty_data().


_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev