seh_try_macros2-00

[Gregory M. Turner]

On Friday 16 May 2003 08:15 am, Dimitrie O. Paun wrote:
> On May 16, 2003 02:21 am, Gregory M. Turner wrote:
> > unfortunately, this doesn't help with MIDL-generated code, which is my
> > primary motivation here...
>
> I know, but I was hoping to use your hard earned knowladge to solve
> this big hole that we have in Winelib... :) Any chance you can look
> at it from the C++ angle? BTW, can't we compile the MIDL-generated
> code with a C++ compiler?

This is a possibility.  Another, which I never thought of until now, would be 
to define macros to support RpcTryExcept syntax, which have the useful 
advantage of a trailing __ENDTRY-type syntax.  

Also, I have learned that gcc 3.3 has a new preprocessing feature: directives 
may be embedded in macros; I think this means we could do stuff like #define 
return something_else, within our macros.  This could maybe fix break, 
return, even goto... obviously it would be a while before it was widely 
available.  Just brainstorming here...

Dimi, here's an evident C++ angle, how does this strike you?  We use g++ to 
generate the exceptions, and then unwind them through our C code, using 
-fexceptions.  Probably easy, if inefficient, compared to the mess I've been 
proposing:

In wine's first C++ file, we implement the following C api:

  extern seh_te_outcome try_except_beastie( tryblk_fn_ptr, filter_fn_ptr,
                                            except_fn_ptr )
  extern seh_tf_outcome try_finally_beastie( tryblk_fn_ptr,finally_fn_ptr ).

The former uses catch(...) to handle exceptions; the latter uses a destructor 
to achieve unwind goodness.  Each calls through the function pointers it is 
provided by C macros, which still use gcc-specific nested functions as 
before.

We still have the lexical constraints of C to deal with, in C code, so we 
still lose break and continue, I guess, at least until gcc 3.3.  But these 
generate nice compile failures that will get fixed at design-time.  
Meanwhile, goto out of a tryblock should work, if I understand how gcc would 
implement this.

Pros:
  Actually sort of works, and actually somewhat portable.

  Presumably allows C++ winelib apps to work better; makes
  wine play nicer with C++ eh and other -fexceptions libs.

  Might be a good "excuse" to start allowing portions of wine which
  are C++-specific.

Cons:

  Wine binaries are much bloated, and maybe less optimised.  -fexceptions is
  known to cause huge size increases, I'm afraid.

  If we call through libs compiled without -fexceptions, bad things will
  happen.

  Depending on how much we want to rely on this, we now need g++ for a working
  wine.  Perhaps, this is inevitable and we shouldn't worry about it.  
  Presumably, there are some known caveats to mixing C++ and wine?

  Might be a good "excuse" to start allowing portions of wine which
  are C++-specific.

  Not sure this is workable with "return"... ?

Any of the above ideas strike anyone's fancy?

I guess the first question to ask, before all of the above is: which is a 
worse sacrifice for wine?  Requiring compiler support for this, or an extra 
parsing phase?  Or just having a broken dummy implementation like we do now?  
OK, sorry to harp on this subject, I will shut up now, as I am sure you are 
all sick of this ;)

-- 
"A just security to property is not afforded by that government,
under which unequal taxes oppress one species of property and
reward another species." --James Madison

gmt