Making alloca more safe

[Sean Kelly]

Andrei Alexandrescu Wrote:

> Sean Kelly wrote:
> > Tomas Lindquist Olsen Wrote:
> > 
> >> On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright
> >> <newshound1 at digitalmars.com> wrote:
> >>> I suppose nobody much cares if it writes out a corrupted audio file. People
> >>> care very much if their airplane suddenly dives into the ground.
> >>>
> >>> Be that as it may, it is certainly possible to catch seg faults in an
> >>> exception handler and write files out. That would be an unacceptable
> >>> behavior, though, in a system that needs to be safe.
> >>>
> >> You spent quite a bit of effort explaining that segfaults never cause
> >> memory corruption, so it seems fairly reasonable to assume that some
> >> parts of the application state could still be valid and useful not to
> >> throw away.
> > 
> > At the moment the segfault occurs, sure.  But if the process eats the segfault and continues, what happens?  If an app is programmed in such a way that segfaults are a part of normal processing (I worked on a DB that performed dynamic loading this way) that's one thing.  But other apps are almost definitely going to try and write data near 0x00 after such an occurrence.
> 
> I think throwing an Error object instead of failing immediately would be 
> occasionally useful. (Same goes about other trapped errors such as 
> integral division by zero.) There are applications out there that want 
> to partially recover from a null pointer error. I wrote a few, so it's 
> difficult to convince me they don't exist.

I'd love to!  And this is how Windows works.  But throwing an exception from a signal handler invokes undefined behavior.  Last time I googled this I saw as many accounts of it failing horribly as working.