This is the mail archive of the cygwin-developers@cygwin.com 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: Igor Pechtchanski
>Sent: 28 June 2005 18:26

> On Tue, 28 Jun 2005, Dave Korn wrote:
> 
>> ----Original Message----
>>> From: Igor Pechtchanski
>>> Sent: 28 June 2005 18:13
>> 
>>> On Tue, 28 Jun 2005, Dave Korn wrote:
>> 
>>>>   Hmm.  Can't we tell how much space there is on the stack from the
>>>> pointers to the stack limits in the NT_TIB (or whatever lives at %fs on
>>>> 9x), where we get the tls pointers from?
>>> 
>>> I wonder -- would temporarily installing a signal handler be too much
>>> overhead?
>> 
>>   I would have thought it's a lot more work than reading a word from
>> offset(%fs), subtracting it from the current %esp value, and comparing
>> it to the size we need....
> 
> Ok.
> 
>>> Or is it a thread safety issue (global vars, etc)?
>> 
>>   Is *what* a thread safety issue?
> 
> There's a need for communication between a signal handler and the writeev
> function.

  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.  

>  This is usually done either via global storage (with the
> obvious drawbacks) or thread-local storage (requiring synchronization,
> unless a pointer to thread-local data is readily available).
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Isn't that *exactly* what cygtls is?

    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]