[Gllug] My and my malloc() problems....

[Christian Smith]

On Sun, 30 Dec 2001 tet at accucard.com wrote:

>
>>This is likely only the case if longjmp() is being used, and that little
>>horror should be used as little as possible, IMHO.
>
>I've seen this said many times. Can someone explain:
>
>1. why setjmp()/longjmp() are so frowned upon

I think because of the whole 'goto is bad'.

>2. what can be used to replace them

Depends what they're being used for.

>
>I've used them in the past for RPC programming where not all the calls
>had timeouts. So I manually hacked together a timeout using setjmp(),
>longjmp() and interval timers. If the interval timer fires, then rewind
>the stack using longjmp(), and handle the error. Lo and behold, a homemade
>timeout on the call.
>
>I can see that it makes the code harder to follow, and also more prone
>to error (for example, memory allocation has to be tracked and released
>where necessary, which some people are bound to forget), but nothing
>that's actually *bad*. So why the poor reputation?

I think it's precisely for the what CAN go wrong (resource leakage etc.) I
wrote some generic exception handling macros for C using setjmp/longjmp,
but couldn't come up with a fool-proof way of correctly unwinding the
stack (like C++ does,) so they have lingered unused.

FWIW, the setjmp/longjmp wrapped in TRY/CATCH macros do improve
readability somewhat. If anyone fancies having a look at them, give me a
shout.

One possibility I've been thinking about is attaching destructors to TRY
blocks, which will do the necassary resource release when an exception is
thrown. I guess this is how C++ does it.

>
>Tet
>

Christian

-- 
    /"\
    \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
     X                           - AGAINST MS ATTACHMENTS
    / \


-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug