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

[Ove Kaaven]

ons, 2003-02-12 kl. 23:41 skrev 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?

I was under the impression that you were still using nested functions,
which is kind of a gcc-ism. So getting rid of ({ }) doesn't seem to buy
anything, unless you *know* of a different compiler that has one but not
the other. So you may as well keep ({ }) if it makes the macros more
manageable or flexible.

> > 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...

Nested functions in gcc can access any of the parent function's local
variables, would that work? (Or would this exception stuff break gcc's
mechanism for this? not sure what it does)


By the way, it seems to me that the particular installer I'm working on
doesn't need NdrClientCall2 after all. Which installer was it that
needed it?