This is the mail archive of the
mailing list for the Cygwin project.
RE: stack overflow bug in ofstream::operator<<
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: Dave Korn <dave dot korn at artimi dot com>
- Cc: cygwin-developers at cygwin dot com
- Date: Tue, 28 Jun 2005 13:25:33 -0400 (EDT)
- Subject: RE: stack overflow bug in ofstream::operator<<
- References: <SERRANOAEmZXWhVvBRb00000274@SERRANO.CAM.ARTIMI.COM>
- Reply-to: cygwin-developers at cygwin dot com
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....
> > 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. 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).
|\ _,,,---,,_ email@example.com
ZZZzz /,`.-'`' -. ;-;;,_ firstname.lastname@example.org
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT