Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com X-Authentication-Warning: hp2.xraylith.wisc.edu: khan owned process doing -bs Date: Tue, 21 Dec 1999 18:44:47 -0600 (CST) From: Mumit Khan To: Chris Faylor cc: cygwin AT sourceware DOT cygnus DOT com Subject: Re: SUMMARY: Known issues with gnuwin32 development tools of year 1999 In-Reply-To: <19991221165152.A11739@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 21 Dec 1999, Chris Faylor wrote: > Actually, it might be but I don't really know. The specific problem > manifests during fork. Since fork overwrites the heap, you can't > rely on mallocing anything until after fork returns. > > In the case of dynamic loading we probably are ok but since this has > bitten me once, I'm assuming that with a small tweak here or there > it could bite us again and then we'd be scratching our heads over > this again in a few months. I do understand your hesitation on this. However, fork will never work for dynamic loads -- the loading app will get very confused at this, and I suspect the same for exec and popen as well, so the problem is moot for dynamic loads. My proposal still stands since it won't modify the behavior of cygwin linked apps in any way, only change it for dynamic loads. Regards, Mumit -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com