[17234] in Kerberos_V5_Development
Re: GSS memory allocation initial cut for review
daemon@ATHENA.MIT.EDU (Kevin Wasserman)
Thu Sep 29 10:23:54 2011
Message-ID: <SNT101-DS25402C68BA343D5D122654B5F60@phx.gbl>
From: "Kevin Wasserman" <krwasserman@hotmail.com>
To: <krbdev@mit.edu>
In-Reply-To: <SNT101-DS122B8B481F23FBF4704EE7B5F10@phx.gbl>
Date: Thu, 29 Sep 2011 10:23:50 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Thanks Jeff for taking the time to respond. I appreciate your feedback.
You are correct that we were imagining that a mechanism library might
be loaded as a plugin for more than one mechglue and that would
make it difficult for the mechanism to determine which mechglue's
allocator to invoke. It sounds like you would prefer that mechanisms
be built to target a particular mechglue. The current problem
is that mechanisms have a tendency to do the following for buffers
they hand back to the glue:
buffer->value = malloc(size);
I think we all agree that has the potential to be very bad on windows.
We just want that to change to
buffer->value = gssalloc_malloc(size);
If you actually need to recompile for every mechglue you want to
target, then you can pretty easily change gssalloc_malloc() to do
whatever is appropriate for that mechglue, so I don't see that what
we're proposing for MIT would force anyone else to do anything in
particular.
-Kevin Wasserman
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
