Re: Secure C library
- From: Niklas Matthies <usenet-nospam@xxxxxxxx>
- Date: 4 Oct 2005 17:19:13 GMT
On 2005-10-04 15:49, Douglas A. Gwyn wrote:
> Niklas Matthies wrote:
>> Who said anything about jumping back into the interrupted processing?
>
> That's the only real advantage in maintaining the current call stack.
No. For one, having the current call stack available for diagnostic
purposes (e.g. as part of a core dump) is a real advantage.
>> ... If the callback returns, then the
>> default handling will occur, which again will typically either be to
>> terminate the process or to throw an exception.
>
> Termination is not appropriate, since that is a high-level strategy
> being imposed by low-level code which is not aware of the whole
> context.
The strategy is imposed by the code that registers the callback, which
generally will be high-level code. More generally, the callback can be
registered anylevel an exception handler can be placed; the respective
level is then equally appropriate or inappropriate for both.
Furthermore, by your reasoning, usage of assert() would never be
appropriate.
> Having to code two levels of error recovery everywhere that an
> exceptional condition could occur is a disadvantage.
The callback is not about error recovery. It's about selecting the
handling mechanism.
Also note that with nested exception handlers, you have multiple
potential levels of error recovery pretty much the same. Just as
exception handlers generally have no problem with the fact that
there might be some inner nested exception handler that catches the
exception first, they won't have a problem with the callback handling
the situation first.
>> .... But, as seen above, there other ways to react (including the
>> possibility to just throw a different, application-specific
>> exception).
>
> Any reasonable nested exception handler system also aupports that.
For that you have to catch the original exception first, possibly in a
multitude of places (before the exception reaches code that expects
the application-specific exception). The purpose of having the
application-specific exception thrown in the first place is exactly to
avoid having to riddle the code with exception-converting handlers.
>> A callback allows client programmers to choose what is appropriate
>> for their application.
>
> Ditto.
Not true. For one, there are applications for which exceptions are not
appropriate, for example if the exceptions would pass through legacy
code that don't expect them and therefore would leak resources.
>> By "stack unwinding" I mean to include a) the process of tracing the
>> chain of exception handlers up the stack (which might be corrupted)
>> and b) all cleanup work done by intermediate exception handlers.
>
> Yes, I know what it means. It's not necessary.
You'll have to explain this. Certainly the next (matching) exception
handler has to be determined somehow for it to be executed, and
certainly there will be exception handlers for releasing resources
that were acquired in local scopes by intermediate code.
-- Niklas Matthies
.
- References:
- Re: Secure C library
- From: Douglas A. Gwyn
- Re: Secure C library
- From: Douglas A. Gwyn
- Re: Secure C library
- Prev by Date: Re: va_end and longjmp
- Next by Date: Re: va_end and longjmp
- Previous by thread: Re: Secure C library
- Next by thread: va_end and longjmp
- Index(es):
Relevant Pages
|
