[17272] in Kerberos_V5_Development
Re: [PATCH 2/4] Utility functions to move allocations
daemon@ATHENA.MIT.EDU (Kevin Wasserman)
Thu Oct 6 13:57:19 2011
Message-ID: <SNT101-DS12995C69F5ADC69DCC385AB5F90@phx.gbl>
From: "Kevin Wasserman" <krwasserman@hotmail.com>
To: "Greg Hudson" <ghudson@mit.edu>,
"Sam Hartman" <hartmans@painless-security.com>
In-Reply-To: <1317922934.1548.10.camel@t410>
Date: Thu, 6 Oct 2011 13:57:15 -0400
MIME-Version: 1.0
Cc: Kevin Wasserman <kevin.wasserman@painless-security.com>, krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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@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@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
