seh_try_macros2-00

[Gregory M. Turner]

On Wednesday 14 May 2003 11:08 pm, Alexandre Julliard wrote:
> "Gregory M. Turner" <gmturner007 at ameritech.net> writes:
> >   - include/wine/excpetion.h
> >   - memory/global.c
> >
> >   Implement gcc-specific "__TYPED_TRY" macro supposedly capable of
> >   intercepting return and running the finally clause.  If it compiles,
> >   it should work on x86...
>
> Cool! now you can start considering how to support continue, break,
> and goto ;-)
>
> (I don't want to discourage you, but I think you will eventually come
> to realize that the only way to make this work right is to do it in
> the compiler)

Don't worry, we are in agreement on this.  I have spent a fair amount of time 
trying to decide whether this problem is fixable without such a measure, and 
I suspect the answer is no, or, at least, not without doing an inordinate 
amount of work and writing lots of asm.

But, for the forseeable future, a majority of wine users & developers will not 
have such a thing.  So, in my view, it makes sense to improve the existing 
__TRY family of macros nevertheless, and to create a partial implementation 
of the __try syntax as well.

FWIW, I think break/continue can actually be implemented in this framework -- 
that was already on my TODO list -- I think I just have to put a "dummy" loop 
inside the try-block function, and have more labels for the various exit 
conditions.  Goto out of the try block is another story, and of course there 
are other limitations... but this would, at least, provide some coverage for 
the stuff that wine already relies on, despite the missing implementation.  
The alternative is to work around the bugs it will create in our RPC 
implementation not to have such support, which is going to get dicey.

When/if gcc does it, great, we just use the implementation of __TRY in terms 
of __try, we don't have to change a thing.  If, for example, after some 
research, the -fasync-unwind-tables thing pans out, that's fine too; we can 
add that in, but not all platforms support this, even for gcc, so we still 
need a pure-C portable alternative to be supported by wine to some reasonable 
extent.

The only way I could see them working /portably/ is to use our own 
preprocessor instead of, or in addition to, the C preprocessor, but that 
could slow down our already slightly onerous build process.

-- 
"There is no dignity quite so impressive, and no independence quite
so important, as living within your means." --Calvin Coolidge

gmt