Re: CORRECTION Re: confused by exception handling in VC 2008

"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message
news:0vefk413mj2d6vvbimrl1lrqphsv6js5qs@xxxxxxxxxx
Since we've been discussing SEH throughout this thread, the issue of using
a
translator to convert asynchronous SEH exceptions into synchronous C++
exceptions naturally did come up. Specifically where one wants to receive
SEH info, and do everything humanly possible to reduce the probability of
encountering the kinds of hazards that typically arise as a result of
mixing
the two exception-handling mechanisms. So, following the MSDN
documentation
(which discourages use of SEH altogether) I simply reiterated that if
you're
going to combine SEH and C++ exception handling, you should at least do it
right. And the the safest way to mix the two is to set up a translator and
then let everything flow through the regular C++ exception handling
mechanism.

What do you think the "hazards" are?

1. Optimizer not preparing for object unwinding in sequences where an
exception (SEH or otherwise) is not anticipated ('s' or 'c' switch
extensions).

2. C++ "catch" blocks not being entered due to optimizations that do not
prepare for C++ exceptions (such as "throw obj;") where *only* extern C
functions are within visible scope.

And so on. Basically when mixing two exception types the optimizer may or
may not prepare code for either synchronous OR ansynchronous exceptions (or
both). This was all discussed long ago.

Presumably the underlying issues remain, so I don't really buy the
portability argument. It seems to me you can #define __try/__except away

I'm not selling it.

I think it would be much more difficult to #define away __try/__except than
to simply not ever write it down in the first place. Much better to use only
C++ exception handling keywords. You're not allowed to mix the two in the
same function as far as I know, so you'd have to make C wrappers wherever
you wanted to use __try/__except that is *if* you intended to use either C++
exception handling or C++ objects, which may or may not work / unwind if an
SEH happens to come along.

just as easily as try/catch. However, it's certain the former is more

Why would you want to get rid of C++ exception handling?

powerful (supports resumption), while the latter is more convenient
(allows
defining objects with dtors in the same function as try/catch; can use C++
types in catch instead of writing complicated filter expressions for
__except).

What's so complicated? It's like a 3 line function (as described by explicit
example in the MSDN).

Hehe. What you *originally* said was, "you won't require the robustness
that you can achieve by either avoiding SEH altogether or using a
translator". IOW, "You can achieve robustness by either (A) or (B)". I
guess I'm not clear how "using a translator" gains you "robustness" that
you would sacrifice if you were to use native SEH.

Because it allows you to not have to mix two exception mechanisms in the
same sources, which confuses the optimizer. That means program flow is much
more easily anticipated. Using a translator basically mashalls asyncronous
exceptions along with C++ exceptions which clearly means more robustness.

Aside: You made a glaring logical error in deducing that I was saying SEH
implies robustness when I stated only that "no SEH" or "SEH+translator" is
more robust than direct use of SEH in C++ code: A->B and A->C that does not
mean B->C (which was your deduction from translator->rubust and
translator->SEH to SEH->robust).

OK, so you are talking about using SEH to recover from bugs, which, by
definition, place the program in an unknown state. In order to use SEH via
_set_se_translator, you must use /EHa everywhere the SE you want to
translate can be thrown, everywhere you catch the translated SE, and if
you
want object destruction during stack unwinding, along all control paths
that can cause the exception. Since you are interested in bug recovery and

I would want to examine the exeption where the current state of objects
created preceeding a throw was known. If I call into some math lib and I
know that sometimes I get a divide by zero, or overflow error, I'd like to
know that the current state of objects in memory is not "random" before
proceeding to handle the error.

aren't targeting specific anticipated issues that can occur in correct
programs, it would seem you need to cast a wide net. This means using /EHa
throughout the program, which will increase its size, make it slower, and
subject catch(...) to catching all SEs you don't translate into C++

Yup, slower.

exceptions in addition to the ones you do translate. I don't think putting
flagrant bugs into catch(...) is a good idea, and I would not advise using
it at the same time as /EHa. This is another reason I don't buy the
"portability" argument, as portable programs certainly can use catch(...)
safely.

No, they can't actually. Not when async exception handling is in effect.
There are no gurantees that catch(...) will be entered or objects unwound.
This is all made very explicit in the MSDN.

I think this is all *very* complex and subtle, and it requires a great
deal
of thought and planning to use /EHa successfully on a wide scale. I've
only
used SEH in cut-and-dried ways, over small areas of code, e.g. (1) I used
native SEH to commit reserved memory and resume execution following an
anticipated access violation, and (2) I used _set_se_translator to
translate delay-load failure SEs into C++ exceptions for graceful error
reporting. I didn't use /EHa for the former, and I used it for the latter
on just the file that required it.

Well that's fine. Everyone has their own approach. I merely noted what the
MSDN has to say on the subject, so if you have a problem with it take it up
with MSOFT not me.

- Alan Carre


.

Relevant Pages

  • Re: initial lang spec: SXIL...
    ... Shouldn't some of that functionality be moved into the exception ... but, of course, natively using SEH requires compiler support. ... throws a fixed exception code in my case, and generic handlers are used. ... It took many years, and a language review, before I realized that my fond ...
    (comp.lang.misc)
  • Re: CORRECTION Re: confused by exception handling in VC 2008
    ... The use of SEH does not imply robustness. ... Did I misunderstand the bit about "using a translator"? ... going to combine SEH and C++ exception handling, you should at least do it ...
    (microsoft.public.vc.mfc)
  • [EXPL] Alphanumeric GetPC Code and Shellcode Encoder-Decoder
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... In addition attached is an uppercase alphanumeric shellcode ... new SEH. ... Then it causes an exception, passing execution to the new SEH. ...
    (Securiteam)
  • Re: Implementing Exception Handling in a VM
    ... Given that the implementing language has SEH, can ... I leverage this fact to add exception support in my Pascal-like ... handling system in your VM. ...
    (comp.compilers)
  • Re: Try Finally...
    ... Okay, so one big part of Delphi SEH requires conversions for system exceptions, ... assertions and other Delphi exceptions into Delphi SEH structures. ... In my tests no Finally code was executed, the call to @Assert actually ... I.e. SEH is not working at all when the various exception conditions do ...
    (comp.lang.pascal.delphi.misc)
Loading