On Sunday 18 May 2003 12:04 pm, Steven Edwards wrote:
There is some discussion on mingw-developer about merging Capsers SEH patches but there are patent issues as borland owns the patent on C++ Style EH in C. The patent is BS as it even sights prior art but still I dont know who wants to take the risk on going to court for this. Now that M$ owns a large chunck of borland this might happen.
Regarding this, I think we all know where Borland can stick this patent to get the best ROI ;)
I mean, it would be suicidal for them to take some poor schmuck like me to court over this... their shareholders (including me) would probably fire the board before they'd tolerate the fallout from such an act. And what damages are they going to recover? The best they could hope for would be a crapload of bad press and some kind of cease-and-decist order... they sure ain't gonna get much out of me, I'm broke ;) Anyhow, this is a discussion for another forum, to which I do not subscribe.
Well, I don't think I have the time for this. It was quite a battle to get the fastcall patch into gcc, and this was only a (IIRC) ~10 or ~20 KB patch. Compare that to the SEH patch which is ~370 KB (and not even complete yet) and which may even violate Borland's patent. The patch is also written by me when I was a gcc newbie and I have probably made some mistakes. It would be nice if an experienced gcc hacker would review and improve the patch.
I will however help in any way I can integrating the patch into gcc 3.4 if needed.
Finally, a gcc with only __try/__finally is only marginally better than a gcc without any SEH at all.
Well, it is the lower-hanging fruit. With __except, you are looking at interactions with C++ exceptions, which could get interesting, and hard. Asking for __finally is just to say "hey, can't we run some code if the bloody stack is going to unwind so we don't have memory leaks?" So it'd be better than nothing, perhaps there is even a good way to create __except macros once you have language support for __finally, I've never thought about that.
What concerns me more is that judging from what I see floating around out there, the gcc devs just plain aren't interested. Some of them are saying "let's be flexible" but the majority seem to be saying "Do it in C++, C should not absorb any new fancy features unless they are standardized by ANSI" or some other discouraging thing.
Alexandre Julliard wrote:
For Winelib apps, the solution is to add support to the compiler. For IDL-generated code, the solution is to make our IDL compiler generate code that uses the existing __TRY macros (or even generates the C code directly without using the macros if this allows more optimizations).
I'm not sure I'm sold on this... I mean, I realize maybe I should be the one selling you if I want to get a patch in, but could you elaborate on the "why" of this a little bit? I like the idea of generating __TRY from widl instead of RpcTryExcept, that's a consistiency issue basically... but expecting compiler support to materialize for seh seems a bit optimistic, frankly.
Why /not/ a pre-pre-processor? It would allow us to implement this properly and portably... I'm sure the performance impact at compile time could be managed, perhaps by only running it against the code that needs it... such files could be marked or discovered at build-time in any number of ways.
Also, I was hoping to hear how everbody feels about -fexceptions? It would seem that without it, g++ exceptions are going to break in winelib... or can those somehow route themselves through the CxxExcept stuff (I presume no, since those rely on compiler-generated unwind-tables that AFAIK gcc doesn't support).