Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Wed, 10 Dec 2003 11:15:16 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Memory Management on AMD64 in 32-bit mode
Message-ID: <20031210101516.GH1941@cygbert.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <3ED686A715B54646AF1BC06C2BFBA4A00165F390@kita.basistech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3ED686A715B54646AF1BC06C2BFBA4A00165F390@kita.basistech.com>
User-Agent: Mutt/1.4.1i

On Dec  9 12:55, Benson Margulies wrote:
> I assume that there's a very strong reason why this code can't just
> allocate a stack any-old-place (calling VirtualAlloc with first arg 0)
> and use it. What I don't understand is the nature of the constraints. If
> the parent needs to know, why not have stack_base make a call to
> VirtualAlloc with first arg 0 to allocate a brand-new region, on the
> theory that such a region is a lot more likely to end up with a
> corresponding hole in the child process?

Just an example:

void foo()
{
  int x = 1;
  int *xp = &x;

  if (!fork())            /* Child */
    printf ("%d\n", *xp); 
}

What happens if the stack of the child has been allocated at another
address as the parent's stack?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/