🚀 go-pugleaf

ebiederm@cse.unl.edu (Eric Biederman) writes:

>eddy@clipper.robadome.com (eddy Gorsuch) writes:
>   Ummm, who throws an exception if you run out of stack? I thought that came
>   in as a signal (or other hardware error), not as a C++ exception.

The C standard and the draft C++ standard do not specify what happens
if you run out of stack space.  It is in the realm of undefined behaviour.

>[note: the useful way would for the signal to throw an exception.  It
>       is an error appropriate to an exception. ] 

The C standard and the draft C++ standard do not specify any asynchronous
signal-handling facilities.  The draft C++ standard does not specify what
happens if a signal handler throws an exception.

>A more realistic example happens if a signal handler is called
>asynchronously.  It just happens that that happened while the call to
>the autoptr's constructor or member reset was being formed upon the
>stack.  This ill timed call to the signal code then throws an
>exception.  Oops memory leak!
>
>On the other hand if the memory was continually in an autoptr it would
>be _safe_ from this (assuming the internal code for autoptr assignment
>was written carefully, to avoid these kinds of problems).

How can the internal code for autoptr assignment be written to
avoid these kinds of problems?

I think allowing asynchronous signal handlers to throw exceptions would
create formidable problems; solving them might require Herculean
feats.  I don't think the C++ standard can support such things, and I
don't think the auto_ptr class should try.  For anyone who is trying to
write safe code in an environment where exceptions may be thrown
asynchronously, auto_ptr will be the least of their problems.

For example, what happens if a signal handler throws an exception while
you were in the middle of throwing another exception?

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]