Gregory M. Turner
gmturner007 at ameritech.net
Thu May 15 20:46:06 CDT 2003
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
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
More information about the wine-devel