For your consideration, here's a preview of some new seh_try_macros-type stuff...

[Gregory M. Turner]

On Wednesday 12 February 2003 01:44 pm, Alexandre Julliard wrote:
> "Gregory M. Turner" <gmturner007 at ameritech.net> writes:
> > Let me know what you think of these.  So far, I like them better
> > than the original versions, although in solving some limitations of the
> > old macros, I've created some new ones.
>
> Of course the main limitation is that this requires gcc, which means
> the macros can't be used in Wine itself. They might be useful for
> Winelib apps though.

actually, since I got rid of "({ })" in this revision, I'm not sure it's 
gcc-specfic at all... or did I miss something?

>
> > Otherwise, these are better macros.  They are slightly more easily
> > understood (although still pretty darn confusing, especially in
> > the debugger), probably more resiliant against compiler optimizations,
> > and have much less awful performance.  Best of all, they ought to
> > properly re-raise exceptions after executing finally clauses.
>
> You cannot re-raise exceptions after finally, the finally block has to
> run at unwind time, not from the exception filter. You should probably
> use the existing __FINALLY macro for that.

This, OTOH, sounds like a more significant issue... I'll look into it.

> > Sooo.... Anyone want to help me decide what's the best way to get a
> > thread-local global variable instantiated?  Probably, my previous attempt
> > with TlsAlloc was semantically correct, but that was /way/ too fat a
> > solution, I'd like something much quicker if its at all possible.
>
> IMO you shouldn't use a variable at all, you should do everything on
> the stack. Otherwise it won't work when an exception happens in the
> middle of the exception code.

Yup.  I'd prefer this myself... but unfortunately, I haven't found a way to 
achieve it.  The problem is that the finally clause provided by the user 
needs to be outside any lexical scope I can create (this is simply because I 
have no way to put some close-brackets after the finally clause like 
__ENDTRY).  So, if I'm going to use the approach of turning the user's 
finally clause into a function, there's no way to get at it without 
inheriting it from the "global" (relative to the place the macros are 
invoked) lexical scope...  which I can't do before I begin the scope because 
I don't know what __LINE__ will be when the user creates their finally clause 
during the __try....   Sorry, that's pretty unclear, but suffice it to say 
that there are some nasty issues at play :)

However, there is probably some creative solution that just hasn't come to me 
yet.  In fact I have a couple of ideas already.  I'll go back to the drawing 
board with these one more time and try to get this issue sorted out ... 
expect at least one more post to wine-devel before I submit a patch on this.

Thanks for looking these over,

-- 
gmt

"Once a nation becomes a democracy, the whole purpose of
government changes.  Instead of the government's goal being
that of guaranteeing liberty, equal justice, private property,
and voluntary exchange, the government embarks on the impossible
task of achieving economic equality, micromanaging the economy,
and protecting citizens from themselves and all their activities.
The destruction of the wealth-building process, which is inherent
in a free society, is never anticipated.  Once it's realized
that it has been undermined, it is too late to easily reverse the
attacks against limited government and personal liberty." 
 -- Ron Paul