dereferencing null

[Sean Kelly]

On Mar 8, 2012, at 12:58 AM, Don Clugston <dac at nospam.com> wrote:

> 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.

Wow, sounds like paradise compared to signals. 


> 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!)

I'm sure it's too late now. And I imagine there was a good reason for it that I'm not aware of, just like the restrictions on kernel calls (which could have blocked signals during execution). Performance was probably part of it. Ah well. The last signal issue I ran into was a deadlock caused by a logger routine calling ctime_r inside a sigchild handler.  What a pain.