Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID:	<0b5501be9255$2fb0bd60$e63d2509@jonpryor.raleigh.ibm.com>
From:	"Jonathan Pryor" <jonpryor AT vt DOT edu>
To:	"cygwin" <cygwin AT sourceware DOT cygnus DOT com>
Subject:	Re: malloc and free mixing in VC++ and cygwin
Date:	Thu, 29 Apr 1999 11:29:46 -0400
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 4.72.3110.5
X-MimeOLE:	Produced By Microsoft MimeOLE V4.72.3110.3

I wasn't arguing that someone should call `malloc()', and then
use `GlobalFree()' to free the memory -- that's definately
a recipe for disaster, for precisely the reasons you specify.

I was stating that if you *don't* use malloc/free, and instead
go straight to the Win32 api (like you argue), that this should
work in mixed-library environments.

So, to be explicit:
 * malloc/free within a library (only MSVC or g++; it would
   likely need to be the same version of the library as well).
    -- Good.

 * malloc/free between libraries (MSVC alloc, g++ free or
   vice-versa).
    -- Bad.

 * malloc to allocate, Win32 API (GlobalFree, etc) to free.
    -- Bad.
    I'd never actually considered this as a possibility...

 * Win32 to allocate (GlobalAlloc, etc.), free() to free.
    -- Bad.
    Ditto.

 * Win32 to allocate (GlobalAlloc) and Free (GlobalFree).
    -- Good, as long as the api's match.  (e.g.
       GlobalAlloc --> GlobalFree, LocalAlloc --> LocalFree, etc.)
    This should work, as the OS is responsible for allocation
    in these functions, not another library (such as the C Run-time).

This should cover most bases.

 - Jon

-----Original Message-----
From: Chris Faylor <cgf AT cygnus DOT com>
To: cygwin <cygwin AT sourceware DOT cygnus DOT com>
Date: Thursday, April 29, 1999 10:57 AM
Subject: Re: malloc and free mixing in VC++ and cygwin


>On Thu, Apr 29, 1999 at 08:26:48AM -0400, Jonathan Pryor wrote:
>>Maybe. :)
>>
>>More precisly, can `malloc' be used to allocate memory in cygwin
>>and `free' be used in VC to free the cygwin-allocated memory?
>>No -- they use different memory schemes.
>>
>>However, that doesn't mean that you can't have one environment
>>allocate memory, and have the other free it -- you just can't
>>use the C runtime functions.
>>
>>The Win32 functions CoTaskMemAlloc() and CoTaskMemFree() can
>>be used to allocate/free memory between 2 otherwise incompatible
>>memory schemes.  I suspect that most of the other Win32 memory
>>functions (GlobalAlloc/GlobalFree, etc.) could also be used
>>to do this as well.
>
>You could use these routines to free the memory but you'd end
>up with a severely corrupted heap as far as cygwin is concerned.
>Cygwin's free() command does more than (potentially) return memory
>to the system.  In fact, it usually doesn't even return memory to
>the system.  It also keeps a list of all allocated memory for reuse
>by other malloc calls.  This is a pretty standard way of doing things.
>
>I'd suggest just using straight Windows routines for doing memory
>allocation and deallocation if you have this requirement.
>
>-chris



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -