This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
RE: stack overflow bug in ofstream::operator<<
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin-developers at cygwin dot com>
- Date: Tue, 28 Jun 2005 18:41:09 +0100
- Subject: 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....