On Wednesday 14 May 2003 11:08 pm, Alexandre Julliard wrote:
"Gregory M. Turner" gmturner007@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.