seh_try_macros2-00

Gregory M. Turner gmturner007 at ameritech.net
Fri May 16 01:21:42 CDT 2003


On Friday 16 May 2003 12:05 am, Dimitrie O. Paun wrote:
> On May 16, 2003 12:00 am, Gregory M. Turner wrote:
> > nope.  'cause it's illegal to have a break/continue hanging around
> > without something to break/continue out of.  But we could have to have
> > "__TYPED_TRY" "__ACHEY_BREAKEY_TYPED_TRY" macros :(
>
> Greg,
>
> I think we're barking up the wrong tree. Vast majority of Windows apps
> nowadays are C++. Of the few that are C-only, most will compile with a
> C++ compiler. In other words, if we find a C++ solution for the SEH
> problem, we would have covered probably more than 95% of apps. Not
> perfect, but good enough.
>
> If I understand you guys correctly, the problem should be solvable in
> C++. Let's go for the low hanging fruit first, it makes good sense.

unfortunately, this doesn't help with MIDL-generated code, which is my primary 
motivation here...

My concern, aside from that it won't work without all these gcc-isms, is that 
by creating a similar syntax to __try and friends, which only implement some 
of the real semantics of these constructs, we create a "false" sense of 
security.  Code utilizing these might compile, and then yield some horrible 
and confusing result (of course, that's kind of what we have now, anyhow, 
with dummy Rpc EH macros)...

goto is a good problem to mention, because unlike break/continue, if they did 
a goto out of a try-block, it would compile, but fail to pop the exception 
record or run finally... not sure if there is some way to prevent that.

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

gmt



More information about the wine-devel mailing list