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<<


----Original Message----
>From: Corinna Vinschen
>Sent: 30 June 2005 12:16

> However, I think I found a way to test if enough space is available on the
> stack.  ld stores the size of the maximum available stack in an absolut
> symbol called __size_of_stack_reserve__.  This is the default stack size
> for the main thread and threads started with no explicit stacksize.  So,
> what I did is to create the following inline function:
> 
> inline bool
> check_alloca (size_t size)
> {
>   extern unsigned long _size_of_stack_reserve__;
>   register char *_curstack __asm__ ("%esp");
>   register size_t stacksize = pthread_self ()->attr.stacksize
>                               ?: (size_t) &_size_of_stack_reserve__;
>   return (size_t) ((_curstack - (_tlsbase - stacksize)) / 65536) * 65536
> > size; }

  Isn't (_tlsbase - stacksize) just going to be the same thing as _tlsstop?
We have pointers to both ends of the stack in there, don't we?  Have I
misunderstood the meaning of StackBase/StackLimit?

> and then something similar to what you proposed in writev:

> Does that sound feasable?

  Looks good to me, but I'm still curious why we can't get the *actual*
stack limits rather than trying to deduce them from the initially-allocated
size.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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