From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-09-30 04:16:46
> > -----Original Message-----
> > From: Alexander Terekhov [mailto:terekhov_at_[hidden]]
> > Sent: 26 September 2003 18:23
> > SEH doesn't "violate" sequence points, AFAIK.
> I *think* I've seen it happen - but it has been a while since I've been
> spelunking in this technology and it may be that I've either misremembered
> or jumped to an incorrect conclusion. But it seems implausible: SEH can
> arise from fetch or store which are often resequenced - so this would
> restrict the available optimisations.
Raising SEH exception (or signal) is clearly a *side effect* (that
isn't "covered" by the C/C++ standard... unless it comes "on top"
of accessing an object designated by a volatile lvalue or modifying
an object, "calling a library I/O function, or calling a function
that does any of those operations" aside for a moment). As such,
implementations are indeed kinda constrained in what they can do
with respect to reordering of operations that can raise SEH or
synchronous signals (unless they can prove that reordering doesn't
> Anyway, I've never seen any MS documentation that would support this belief.
> (And a quick search of MSDN doesn't return any promising hits.) Do you have
> a reference?
Nope. But I'd consider it simply "a bug" if they don't do it right.
> > > What advantage does that bring?
> > Long story. Sorry. I can drop some links. Interested?
(Subject: __attribute__((cleanup(function)) versus try/finally)
(Subject: Exception handling... it's time to fix the standard)
(Subject: Re: std0X::expected_exception<T>() [repost])
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk