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