Hi Kevin,
A couple of comments before I digest this when I get home.
On 7/6/07, Kevin O'Connor wrote:
> > Kevin O'Connor wrote:
> >
>
> > struct eh_data {
> > jmp_buf env;
> > __seh_filter filter;
> > };
>
> This should probably include a "struct eh_data *old_handler", so that
> nested try blocks work.
>
Ah, right, nested blocks. That's for v2. :)
I just realized that probably we can use gcc's preprocessor varargs
for the __except filter, making us 99% source compatible with MSVC.
__EXCEPT(...)
{
int res = __VA_ARGS__;
Will have to give it a try later. (pun intended.)
>
> A couple of comments:
>
> 1 - the generated assembly under -O doesn't look too bad.
>
> 2 - you call setjmp after start_ehandling. It would be better to
> arrange for setjmp to always occur before registering the handler.
> (To guard against exceptions occurring before setjmp.)
>
> 3 - you call end_ehandling on the exception path in normal code. I
> would think calling end_ehandling in the exception handler is more
> appropriate - if the filter func raises an exception itself..
>
> 4 - I don't think your __finally is correct. Should an exception be
> raised in a __try / __finally block, the finally clause should be
> run and then the exception should be re-raised. (The macro should
> probably take a func like __except_filt - just have it always
> return EXCEPTION_CONTINUE_SEARCH.)
>
You're right on the re-raise part. I'm not sure on the extra parameter.
I don't think finally's ever take one.
http://msdn2.microsoft.com/en-us/library/s58ftw19(VS.80).aspx
Cheers,
Pedro Alves
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Cegcc-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
