🚀 go-pugleaf

In article <47c7pe$722@eclipse.eng.sc.rolm.com> eddy@clipper.robadome.com
(eddy Gorsuch) writes:
   In article <47b1um$fvs@infoserv.rug.ac.be>,
   Stein Somers <uunet!PROBLEM_WITH_INEWS_GATEWAY_FILE!somers@ncar.UCAR.EDU>
   wrote:
   [...]
   >This has been mentioned earlier, of course.  So I'd like to repost
   >this recent uncountered reply:
   >
   >Eric Biederman (ebiederm@cse.unl.edu) wrote:
   >: The problem is that you are passing it as a standard pointer type.
   >: What happens if you were to run out of stack after the call to release
   >: and before the call to the constructor, or reset.  And an exception is
   >: thrown.
[ hiden cut ]

   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.

[note: the useful way would for the signal to throw an exception.  It
       is an error appropriate to an exception. ] 
[note: who throws exceptions, _now_? ] 

Sorry, that was a bad example so acknowledged in a part you cut out.
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).

   By the same token, what happens if you allocate some storage, then run
   out of stack space while trying to call the auto_ptr's constructor (or
   reset())? This leaves the same memory leak. I don't think these cases are
   (nor should they be) covered by the C++ standard. They are too machine/OS
   dependant.
[ ... ]

But that's transfering a pointer into an autoptr, the pointer makes no
guarantees of safety in that case.  But the __autoptr__ does!

Returning the autoptr to a normal pointer violates all gaurantes of
safety.  Assuming that you will still have safety is bad. It's as bad
as assuming all objects can be aligned on any address, or the bit
pattern of static_cast<void *>(0) is 0, or etc. 

Once your pointer is in autoptr it's _safe_.  While your pointer is in
autoptr it should remain _safe_.  

The issue of running out of stack space is not what I was arguing
about.  Simply my thought of a synchronous example that could cause
problems.  A very unrealistic example.

Eric
---
[ 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. ]