This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
RE: Re[2]: Security hole in gnu-win32-gcc / GlobalAlloc
- To: "'David MAUGIS'" <david dot maugis at sonovision-itep dot fr>
- Subject: RE: Re[2]: Security hole in gnu-win32-gcc / GlobalAlloc
- From: "Boatwright, Charles" <Charles_Boatwright at cisnc dot canon dot com>
- Date: Wed, 17 Sep 1997 11:21:09 -0700
- Cc: "'gnu-win32 at cygnus dot com'" <gnu-win32 at cygnus dot com>
David,
Not that it matters, however I was comparing the NT global
alloc to a debug process global alloc. You point is well taken,
I *should* have dug through my lab books to find the data on
global vs virtual cross NT vs 95. It was an interesting test, but
in the end somewhat uncontrolled (someone with inside info
to the kernel group at M$ told me memory allocation performace
can only be measured with +/- 10% accuracy).
FWIW my $0.02
> ----------
> From: David MAUGIS[SMTP:david.maugis@sonovision-itep.fr]
> Sent: Friday, September 12, 1997 2:13 PM
> To: kroening@hit.handshake.de; Boatwright, Charles
> Cc: gnu-win32@cygnus.com
> Subject: Re[2]: Security hole in gnu-win32-gcc / GlobalAlloc
>
>
> I think GlobalAlloc is slower because, basicaly, when you allocate
> uninitialized
> memory (i.e. non zeroized ) you call a low level function :
> VirtualAlloc
> VirtualAlloc doesnt allocate any memory at first but only reserves
> address
> space. When you access this address space, the memory is then
> allocated.
>
> I suppose that if you try to allocate zeroized memory, GlobalAlloc has
> to map
> all memory at once ...
>
>
__SNIP SNIP__
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".