This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stack overflow bug in ofstream::operator<<


On Jun 30 09:42, Christopher Faylor wrote:
> On Thu, Jun 30, 2005 at 01:15:45PM +0200, Corinna Vinschen wrote:
> >On Jun 28 13:59, Christopher Faylor wrote:
> >> On Tue, Jun 28, 2005 at 06:41:09PM +0100, Dave Korn wrote:
> >> >Well, I was proposing testing how much space was available on the
> >> >stack, so that we never alloca past the bottom of it, and hence don't
> >> >*need* any kind of signal handler.
> >> 
> >> If we are going to check how much stack space is available, it might be
> >> nice to make a __alloca_which_returns_NULL which returns NULL when there
> >> isn't enough space available.  That could be used for other things.
> >
> >I'm not sure if we can substitute alloca by something which is able
> >to return NULL.  The gcc implementation of alloca is designed so that
> >it doesn't return but jumps back to the caller, and the caller itself
> >gets the address for the new stack area by calling
> >
> >  lea 12(%esp), %eax
> >  movl %eax, -> target pointer variable
> >
> >So alloca is designed in a way which disallows to return NULL at all.
> 
> I don't get this.  I was just saying that an *alternate* implementation
> of alloca which returned NULL when insufficient stack space was
> available might be useful, not that alloca itself be rewritten.  It is
> certainly possible to do that regardless of how alloca is written now.

Ok.  I take it then that you don't like the way I solved it.  Implementing
some alloca like function with exception handling is certainly more i386
assembler than I understand.


Corinna

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]