Ok, so I imagine the internal implementation would be something like a STACK_OF(ERR_STATE) instead of a simple ERR_STATE, and the thread would be working on the ERR_STATE positionned at 0 in the stack, right ?
When ERR_mark() is called we malloc a new ERR_STATE and we insert it at position 0 it in the thread's STACK_OF(ERR_STATE), when we call ERR_pop_to_mark() we simply pop the entry (which would be position 0). This would allow the handle more than on level of errors. In any event I think that functions ERR_disable() and ERR_enable() are still necessary, In my case I really don't care what errors the child functions generate since I'm in an post-error cleaning function, I see no point in wasting some CPU and RAM, since I'm not interrested in displaying the cleaning function's errors. We can still implement the ERR_disable/ERR_enable on top of the new stack code, it would only mean adding a "int disabled" member to ERR_STATE and test it in ERR_put_error, ERR_clear_error, get_error_values and ERR_set_error_data. If I recall those are the functions that modifiy the error list. Fr�d�ric Giudicelli http://www.newpki.org ----- Original Message ----- From: "Richard Levitte - VMS Whacker" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, May 28, 2003 5:16 AM Subject: Re: Custom error handling > In message <[EMAIL PROTECTED]> on Tue, 27 May 2003 22:52:54 -0400 (EDT), Rich Salz <[EMAIL PROTECTED]> said: > > rsalz> > ERR_mark() Puts a mark in the error stack > rsalz> > ERR_pop_to_mark() Pops off errors from the error stack until a > rsalz> > mark is found. The mark itself is popped as > rsalz> > well. > rsalz> > rsalz> Do they nest? Perhaps this is cleaner: > rsalz> int depth = ERR_get_depth(); > rsalz> void ERR_pop_to(int depth); > > I was thinking that several marks in the stack would be possible, so > yes, the would nest. Your idea has the benefit of needing less code, > since it would be up to the application to keep track of the marks > rather than OpenSSL :-). I can foresee only one problem: if depth is > registered, then errors are popped the old way (with the get_error > functions), and then more errors are added (enough that the stack is > at least as deep as when the depth was registered), and ERR_pop_to() > is run, the result would be quite unexpected, and probably quite hard > to debug. > > Of course, that case is a big-time user error, but one to be prepared > for. > > -- > Richard Levitte \ Tunnlandsv�gen 3 \ [EMAIL PROTECTED] > [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 > \ SWEDEN \ or +46-708-26 53 44 > Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED] > Member of the OpenSSL development team: http://www.openssl.org/ > > Unsolicited commercial email is subject to an archival fee of $400. > See <http://www.stacken.kth.se/~levitte/mail/> for more info. > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
