Making alloca more safe

[Andrei Alexandrescu]

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.

Andrei