dereferencing null

Steven Schveighoffer schveiguy at yahoo.com
Thu Mar 8 03:32:40 PST 2012


On Thu, 08 Mar 2012 03:58:22 -0500, 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.
>
> 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!)

IIRC, SEH is patented...

-Steve


More information about the Digitalmars-d mailing list