[17244] in Kerberos_V5_Development
Re: GSS memory allocation initial cut for review
daemon@ATHENA.MIT.EDU (Nico Williams)
Mon Oct 3 14:55:01 2011
MIME-Version: 1.0
In-Reply-To: <1317239459-13699-1-git-send-email-hartmans@painless-security.com>
Date: Mon, 3 Oct 2011 13:54:55 -0500
Message-ID: <CAK3OfOgxX-2x23+hAjX4ygQ=DSoPZ-aJb4b6YxDE8MouQWvVnA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Sam Hartman <hartmans@painless-security.com>
Cc: 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
Sam, Kevin,
I've been meaning to comment on this...
I'm perfectly fine with a mechglue requiring that it's providers do
something in particular for memory allocation. The mechglue specifies
its own SPI, since no standard SPI exists, and memory allocation can
be part of the SPI.
Can we require *all* mechglues and providers in a process to do the
same? Well, on Unix it'd certainly work. Jeff explains that on
Windows this means losing the ability to use advanced memory debugging
libraries, which, to me, seems like a big deal.
At first glance I'm tempted to conclude that the problem is that one
mechglue cannot impose these sorts of requirements on other mechglues.
It seems like a matter of principle.
However, I wonder if we couldn't have an agreed convention that on
Windows mechglues must use a memory allocator provided by a specific
DLL, and let that DLL select an actual allocator via configuration.
Would this solve Jeff's issue? I think it should, but then, I'm not a
Windows expert.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
