seh_try_macros2-00

[Gregory M. Turner]

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).

-- 
"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