[PATCH 2/4] Utility functions to move allocations fromk5buf/krb5_data to gss_buffer_t
krwasserman at hotmail.com
Thu Oct 6 13:57:15 EDT 2011
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.
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
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
More information about the krbdev