dereferencing null

[Don Clugston]

On 06/03/12 17:05, Sean Kelly wrote:
> On Mar 6, 2012, at 3:14 AM, Don Clugston<dac at nospam.com>  wrote:
>>
>> Responding to traps is one of the very few examples I know of, where Windows got it completely right,
>> and *nix got it absolutely completely wrong. Most notably, the hardware is *designed* for floating point traps to be fully recoverable. It makes perfect sense to catch them and continue.
>> But unfortunately the *nix operating systems are completely broken in this regard and there's nothing we can do to fix them.
>
> Does SEH allow recovery at the point of error like signals do?

Yes, it does. It really acts like an interrupt. You can, for example, 
modify registers or memory locations, then perform the equivalent of an 
asm { iret; }, so that you continue at the next instruction. Or, you can 
pass control to any function, after unwinding the stack by any number of 
frames you chose. And, you regain control if any other exception occurs 
during the unwinding, and you're given the chance to change strategy at 
that point.

An SEH handler behaves a bit like setjmp(), it's not a callback.
Most importantly, in comparison to Posix, there are NO LIMITATIONS about 
what you can do in an SEH exception handler. You can call any function 
you like.

The documentation is terrible, but it's really a beautiful design.

  Sometimes I think it would be enough if the Posix spec were worded in 
a way that allowed exceptions to be thrown from signal handlers.

I think that would be difficult to allow. Some of the restrictions seem 
to be quite fundamental. (Otherwise, I'm sure they would have got rid of 
them by now!)