This is the mail archive of the
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<<
>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
>> 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....
>>> 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
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?
Can't think of a witty .sigline today....