This is the mail archive of the libstdc++@sources.redhat.com mailing list for the libstdc++ project.

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

Re: gen-num-limits.cc & signal handling

To: Mark Kettenis <kettenis at wins dot uva dot nl>
Subject: Re: gen-num-limits.cc & signal handling
From: Daniel Berlin <dberlin at redhat dot com>
Date: 16 Dec 2000 13:22:26 -0500
Cc: Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr, libstdc++ at gcc dot gnu dot org, khan at xraylith dot wisc dot edu
References: <200012042359.eB4NxDx01550@delius.kettenis.local><flofyrh9lc.fsf@sel.cmla.ens-cachan.fr><200012052105.eB5L5SV00529@delius.kettenis.local>

Mark Kettenis <kettenis@wins.uva.nl> writes:

>    That is possible -- out of curiosity, I'm interested in knowing if
>    that is actually what is happing on BeOS and Cygwin.
> 
> Me too :-).

Sorry it took so long to answer, it's been finals time.

The patch below does *not* fix the BeOS problem.
*however*, if i put back the CYGWIN part, and change it to #ifdef
__BEOS__, it works fine.
With both sigsetjmp, and setjmp (IE with and without the patch below).

This would mean i could remove all the other cruft i had been adding
to gen-num-limits.cc in my patches for BeOS, and just have the
#ifdef__CYGWIN__ part changed to #ifdef __BEOS__.

Personally I think this is better than what I had to do before, by a
large factor.

Is this acceptable? If so, i'll modify the beos patch to do that.

Follow-Ups:
- Re: gen-num-limits.cc & signal handling
  - From: Benjamin Kosnik

References:
- gen-num-limits.cc & signal handling
  - From: Mark Kettenis
- Re: gen-num-limits.cc & signal handling
  - From: Gabriel Dos Reis
- Re: gen-num-limits.cc & signal handling
  - From: Mark Kettenis

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