Re: [openssl.org #629] Custom error handling
That's pretty much what I asked from the beginning, the possibility to use ERR_set_implementation and to have ERR_FNS public. But because of (if (!err_fns)) on ERR_set_implementation:304, that's just not possible. I just asked that for the next stable release :) NewPKI is only compatible with openssl 0.9.7b, so I guess it could become only compatible with openssl 0.9.8 (or wathever next release is). Thanks. Frédéric Giudicelli http://www.newpki.org OK, what stops you from creating your own implementation table and fill that with whatever you want, and give that as an argument to ERR_set_implementation(). I know, it means you have to look in crypto/err/err.c for each version to see if there's been a change to ERR_FNS. Guess what? It sounds like you must fiddle with that file eaither way... -- 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. In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 20:02:15 +0200 (METDST), Frédéric Giudicelli via RT [EMAIL PROTECTED] said: rt Because, I could stub the default implementation, and if the error rt handling has been disabled, then I just don't call the default rt implementation function. rt rt Frédéric Giudicelli rt http://www.newpki.org rt rt rt - Original Message - rt From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] rt To: [EMAIL PROTECTED]; [EMAIL PROTECTED] rt Cc: [EMAIL PROTECTED] rt Sent: Friday, July 04, 2003 1:52 PM rt Subject: Re: [openssl.org #629] Custom error handling rt rt rt In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 rt 00:12:24 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: rt rt groups The problem is the following, yes your code rt (ERR_pop_to_mark/ERR_set_mark) rt groups is fine when a child function is adding a new error, however, what rt happends rt groups when it calls ERR_clear_error ? In my implementation I need the rt error stack rt groups to be preserved even if a child function calls ERR_clear_error. rt groups rt groups That's why if you happended to remove the if (!err_fns) test in rt groups ERR_set_implementation, I would be more than happy. rt rt I'm sorry, but in what way does that prevent the error stack to be rt cleared? Maybe a better thing would be to have a flag that inhibits rt clearing the error stack... I'll ponder over this issue. rt rt -- rt Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] rt [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 rt \ SWEDEN \ or +46-708-26 53 44 rt Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] rt Member of the OpenSSL development team: http://www.openssl.org/ rt rt Unsolicited commercial email is subject to an archival fee of $400. rt See http://www.stacken.kth.se/~levitte/mail/ for more info. rt __ rt OpenSSL Project http://www.openssl.org rt Development Mailing List [EMAIL PROTECTED] rt Automated List Manager [EMAIL PROTECTED] rt rt rt __ rt OpenSSL Project http://www.openssl.org rt Development Mailing List [EMAIL PROTECTED] rt Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
That's pretty much what I asked from the beginning, the possibility to use ERR_set_implementation and to have ERR_FNS public. But because of (if (!err_fns)) on ERR_set_implementation:304, that's just not possible. I just asked that for the next stable release :) NewPKI is only compatible with openssl 0.9.7b, so I guess it could become only compatible with openssl 0.9.8 (or wathever next release is). Thanks. Frédéric Giudicelli http://www.newpki.org OK, what stops you from creating your own implementation table and fill that with whatever you want, and give that as an argument to ERR_set_implementation(). I know, it means you have to look in crypto/err/err.c for each version to see if there's been a change to ERR_FNS. Guess what? It sounds like you must fiddle with that file eaither way... -- 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. In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 20:02:15 +0200 (METDST), Frédéric Giudicelli via RT [EMAIL PROTECTED] said: rt Because, I could stub the default implementation, and if the error rt handling has been disabled, then I just don't call the default rt implementation function. rt rt Frédéric Giudicelli rt http://www.newpki.org rt rt rt - Original Message - rt From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] rt To: [EMAIL PROTECTED]; [EMAIL PROTECTED] rt Cc: [EMAIL PROTECTED] rt Sent: Friday, July 04, 2003 1:52 PM rt Subject: Re: [openssl.org #629] Custom error handling rt rt rt In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 rt 00:12:24 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: rt rt groups The problem is the following, yes your code rt (ERR_pop_to_mark/ERR_set_mark) rt groups is fine when a child function is adding a new error, however, what rt happends rt groups when it calls ERR_clear_error ? In my implementation I need the rt error stack rt groups to be preserved even if a child function calls ERR_clear_error. rt groups rt groups That's why if you happended to remove the if (!err_fns) test in rt groups ERR_set_implementation, I would be more than happy. rt rt I'm sorry, but in what way does that prevent the error stack to be rt cleared? Maybe a better thing would be to have a flag that inhibits rt clearing the error stack... I'll ponder over this issue. rt rt -- rt Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] rt [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 rt \ SWEDEN \ or +46-708-26 53 44 rt Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] rt Member of the OpenSSL development team: http://www.openssl.org/ rt rt Unsolicited commercial email is subject to an archival fee of $400. rt See http://www.stacken.kth.se/~levitte/mail/ for more info. rt __ rt OpenSSL Project http://www.openssl.org rt Development Mailing List [EMAIL PROTECTED] rt Automated List Manager [EMAIL PROTECTED] rt rt rt __ rt OpenSSL Project http://www.openssl.org rt Development Mailing List [EMAIL PROTECTED] rt Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
In message [EMAIL PROTECTED] on Sat, 5 Jul 2003 08:24:45 +0200 (CEST), Frédéric Giudicelli [EMAIL PROTECTED] said: groups That's pretty much what I asked from the beginning, the groups possibility to use ERR_set_implementation and to have ERR_FNS groups public. But because of (if (!err_fns)) on groups ERR_set_implementation:304, that's just not possible. I'm sorry, but how exactly does that conditional stop you from giving ERR_set_implementation() a non-NULL pointer and have that accepted? -- 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]
Re: [openssl.org #629] Custom error handling
In message [EMAIL PROTECTED] on Sat, 5 Jul 2003 08:24:45 +0200 (CEST), Frédéric Giudicelli [EMAIL PROTECTED] said: groups That's pretty much what I asked from the beginning, the groups possibility to use ERR_set_implementation and to have ERR_FNS groups public. But because of (if (!err_fns)) on groups ERR_set_implementation:304, that's just not possible. I'm sorry, but how exactly does that conditional stop you from giving ERR_set_implementation() a non-NULL pointer and have that accepted? -- 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]
Re: [openssl.org #629] Custom error handling
In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 00:12:24 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups The problem is the following, yes your code (ERR_pop_to_mark/ERR_set_mark) groups is fine when a child function is adding a new error, however, what happends groups when it calls ERR_clear_error ? In my implementation I need the error stack groups to be preserved even if a child function calls ERR_clear_error. groups groups That's why if you happended to remove the if (!err_fns) test in groups ERR_set_implementation, I would be more than happy. I'm sorry, but in what way does that prevent the error stack to be cleared? Maybe a better thing would be to have a flag that inhibits clearing the error stack... I'll ponder over this issue. -- 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]
Re: [openssl.org #629] Custom error handling
Because, I could stub the default implementation, and if the error handling has been disabled, then I just don't call the default implementation function. Frédéric Giudicelli http://www.newpki.org - Original Message - From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, July 04, 2003 1:52 PM Subject: Re: [openssl.org #629] Custom error handling In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 00:12:24 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups The problem is the following, yes your code (ERR_pop_to_mark/ERR_set_mark) groups is fine when a child function is adding a new error, however, what happends groups when it calls ERR_clear_error ? In my implementation I need the error stack groups to be preserved even if a child function calls ERR_clear_error. groups groups That's why if you happended to remove the if (!err_fns) test in groups ERR_set_implementation, I would be more than happy. I'm sorry, but in what way does that prevent the error stack to be cleared? Maybe a better thing would be to have a flag that inhibits clearing the error stack... I'll ponder over this issue. -- 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] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
Because, I could stub the default implementation, and if the error handling has been disabled, then I just don't call the default implementation function. Frédéric Giudicelli http://www.newpki.org - Original Message - From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, July 04, 2003 1:52 PM Subject: Re: [openssl.org #629] Custom error handling In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 00:12:24 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups The problem is the following, yes your code (ERR_pop_to_mark/ERR_set_mark) groups is fine when a child function is adding a new error, however, what happends groups when it calls ERR_clear_error ? In my implementation I need the error stack groups to be preserved even if a child function calls ERR_clear_error. groups groups That's why if you happended to remove the if (!err_fns) test in groups ERR_set_implementation, I would be more than happy. I'm sorry, but in what way does that prevent the error stack to be cleared? Maybe a better thing would be to have a flag that inhibits clearing the error stack... I'll ponder over this issue. -- 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] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
OK, what stops you from creating your own implementation table and fill that with whatever you want, and give that as an argument to ERR_set_implementation(). I know, it means you have to look in crypto/err/err.c for each version to see if there's been a change to ERR_FNS. Guess what? It sounds like you must fiddle with that file eaither way... -- 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. In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 20:02:15 +0200 (METDST), Frédéric Giudicelli via RT [EMAIL PROTECTED] said: rt Because, I could stub the default implementation, and if the error rt handling has been disabled, then I just don't call the default rt implementation function. rt rt Frédéric Giudicelli rt http://www.newpki.org rt rt rt - Original Message - rt From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] rt To: [EMAIL PROTECTED]; [EMAIL PROTECTED] rt Cc: [EMAIL PROTECTED] rt Sent: Friday, July 04, 2003 1:52 PM rt Subject: Re: [openssl.org #629] Custom error handling rt rt rt In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 rt 00:12:24 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: rt rt groups The problem is the following, yes your code rt (ERR_pop_to_mark/ERR_set_mark) rt groups is fine when a child function is adding a new error, however, what rt happends rt groups when it calls ERR_clear_error ? In my implementation I need the rt error stack rt groups to be preserved even if a child function calls ERR_clear_error. rt groups rt groups That's why if you happended to remove the if (!err_fns) test in rt groups ERR_set_implementation, I would be more than happy. rt rt I'm sorry, but in what way does that prevent the error stack to be rt cleared? Maybe a better thing would be to have a flag that inhibits rt clearing the error stack... I'll ponder over this issue. rt rt -- rt Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] rt [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 rt \ SWEDEN \ or +46-708-26 53 44 rt Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] rt Member of the OpenSSL development team: http://www.openssl.org/ rt rt Unsolicited commercial email is subject to an archival fee of $400. rt See http://www.stacken.kth.se/~levitte/mail/ for more info. rt __ rt OpenSSL Project http://www.openssl.org rt Development Mailing List [EMAIL PROTECTED] rt Automated List Manager [EMAIL PROTECTED] rt rt rt __ rt OpenSSL Project http://www.openssl.org rt Development Mailing List [EMAIL PROTECTED] rt Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
OK, what stops you from creating your own implementation table and fill that with whatever you want, and give that as an argument to ERR_set_implementation(). I know, it means you have to look in crypto/err/err.c for each version to see if there's been a change to ERR_FNS. Guess what? It sounds like you must fiddle with that file eaither way... -- 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. In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 20:02:15 +0200 (METDST), Frédéric Giudicelli via RT [EMAIL PROTECTED] said: rt Because, I could stub the default implementation, and if the error rt handling has been disabled, then I just don't call the default rt implementation function. rt rt Frédéric Giudicelli rt http://www.newpki.org rt rt rt - Original Message - rt From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] rt To: [EMAIL PROTECTED]; [EMAIL PROTECTED] rt Cc: [EMAIL PROTECTED] rt Sent: Friday, July 04, 2003 1:52 PM rt Subject: Re: [openssl.org #629] Custom error handling rt rt rt In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 rt 00:12:24 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: rt rt groups The problem is the following, yes your code rt (ERR_pop_to_mark/ERR_set_mark) rt groups is fine when a child function is adding a new error, however, what rt happends rt groups when it calls ERR_clear_error ? In my implementation I need the rt error stack rt groups to be preserved even if a child function calls ERR_clear_error. rt groups rt groups That's why if you happended to remove the if (!err_fns) test in rt groups ERR_set_implementation, I would be more than happy. rt rt I'm sorry, but in what way does that prevent the error stack to be rt cleared? Maybe a better thing would be to have a flag that inhibits rt clearing the error stack... I'll ponder over this issue. rt rt -- rt Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] rt [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 rt \ SWEDEN \ or +46-708-26 53 44 rt Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] rt Member of the OpenSSL development team: http://www.openssl.org/ rt rt Unsolicited commercial email is subject to an archival fee of $400. rt See http://www.stacken.kth.se/~levitte/mail/ for more info. rt __ rt OpenSSL Project http://www.openssl.org rt Development Mailing List [EMAIL PROTECTED] rt Automated List Manager [EMAIL PROTECTED] rt rt rt __ rt OpenSSL Project http://www.openssl.org rt Development Mailing List [EMAIL PROTECTED] rt Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #629] Custom error handling
I just made up my mind on this issue. I will not implement ERR_disable() or ERR_enable() for the reasons stated below. And that resolves this ticket. [levitte - Fri Jun 20 00:20:52 2003]: Just for the sake of keeping history with this ticket: I've concerns with ERR_disable() in relation to the OpenSSL code checking for certain errors in some places. If error setting is disabled, we might very well end up with unwanted problems. Sure, it can be fixed by temporarely re-enabling error setting, but that requires an extra effort from OpenSSL developpers, and this is easily forgotten. [levitte - Wed Jun 11 22:55:38 2003]: I've implemented ERR_set_mark() and ERR_pop_to_mark(), which can be used for similar functionality. I'll look into ERR_disable() and ERR_enable() as well, but that requires quite a lot more work. If the implemented functions are enough for you for now, I'll resolve this ticket. [EMAIL PROTECTED] - Mon May 26 09:16:48 2003]: Hi, I would like to implement some kind of error locking function: SYSerr(x,x); ERR_disable(); //We don't want anymore error feedback from this point //call to functions that can potentialy generate some more errors ERR_enable(); //Re-enable error feedback In this exemple the last error will be the one generated by SYSerr(x,x);. I tried to implement a custom error handling function, int_thread_get_item equivalent that would return NULL, if the thread error handling was locked, but any call to ERR_clear_error destroyed the SYSerr(x,x); error. The custom error handling doesn't seem to be really supported (ERR_FNS is opaque..., etc), altough the bases are there, could it be possible to either fully support custom error handling, or to add the ERR_enable/ERR_disable. Thanks, Frédéric Giudicelli http://www.newpki.org -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
Well, As I said earlier, you don't have to implement it, however that would be nice if you could make the cutsom error handling code work, which would allow me to implement it. Thanks, Frédéric Giudicelli http://www.newpki.org - Original Message - From: Richard Levitte via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 03, 2003 11:01 PM Subject: [openssl.org #629] Custom error handling I just made up my mind on this issue. I will not implement ERR_disable() or ERR_enable() for the reasons stated below. And that resolves this ticket. [levitte - Fri Jun 20 00:20:52 2003]: Just for the sake of keeping history with this ticket: I've concerns with ERR_disable() in relation to the OpenSSL code checking for certain errors in some places. If error setting is disabled, we might very well end up with unwanted problems. Sure, it can be fixed by temporarely re-enabling error setting, but that requires an extra effort from OpenSSL developpers, and this is easily forgotten. [levitte - Wed Jun 11 22:55:38 2003]: I've implemented ERR_set_mark() and ERR_pop_to_mark(), which can be used for similar functionality. I'll look into ERR_disable() and ERR_enable() as well, but that requires quite a lot more work. If the implemented functions are enough for you for now, I'll resolve this ticket. [EMAIL PROTECTED] - Mon May 26 09:16:48 2003]: Hi, I would like to implement some kind of error locking function: SYSerr(x,x); ERR_disable(); //We don't want anymore error feedback from this point //call to functions that can potentialy generate some more errors ERR_enable(); //Re-enable error feedback In this exemple the last error will be the one generated by SYSerr(x,x);. I tried to implement a custom error handling function, int_thread_get_item equivalent that would return NULL, if the thread error handling was locked, but any call to ERR_clear_error destroyed the SYSerr(x,x); error. The custom error handling doesn't seem to be really supported (ERR_FNS is opaque..., etc), altough the bases are there, could it be possible to either fully support custom error handling, or to add the ERR_enable/ERR_disable. Thanks, Frédéric Giudicelli http://www.newpki.org -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
Well, As I said earlier, you don't have to implement it, however that would be nice if you could make the cutsom error handling code work, which would allow me to implement it. Thanks, Frédéric Giudicelli http://www.newpki.org - Original Message - From: Richard Levitte via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 03, 2003 11:01 PM Subject: [openssl.org #629] Custom error handling I just made up my mind on this issue. I will not implement ERR_disable() or ERR_enable() for the reasons stated below. And that resolves this ticket. [levitte - Fri Jun 20 00:20:52 2003]: Just for the sake of keeping history with this ticket: I've concerns with ERR_disable() in relation to the OpenSSL code checking for certain errors in some places. If error setting is disabled, we might very well end up with unwanted problems. Sure, it can be fixed by temporarely re-enabling error setting, but that requires an extra effort from OpenSSL developpers, and this is easily forgotten. [levitte - Wed Jun 11 22:55:38 2003]: I've implemented ERR_set_mark() and ERR_pop_to_mark(), which can be used for similar functionality. I'll look into ERR_disable() and ERR_enable() as well, but that requires quite a lot more work. If the implemented functions are enough for you for now, I'll resolve this ticket. [EMAIL PROTECTED] - Mon May 26 09:16:48 2003]: Hi, I would like to implement some kind of error locking function: SYSerr(x,x); ERR_disable(); //We don't want anymore error feedback from this point //call to functions that can potentialy generate some more errors ERR_enable(); //Re-enable error feedback In this exemple the last error will be the one generated by SYSerr(x,x);. I tried to implement a custom error handling function, int_thread_get_item equivalent that would return NULL, if the thread error handling was locked, but any call to ERR_clear_error destroyed the SYSerr(x,x); error. The custom error handling doesn't seem to be really supported (ERR_FNS is opaque..., etc), altough the bases are there, could it be possible to either fully support custom error handling, or to add the ERR_enable/ERR_disable. Thanks, Frédéric Giudicelli http://www.newpki.org -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
In message [EMAIL PROTECTED] on Thu, 3 Jul 2003 23:09:05 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups As I said earlier, you don't have to implement it, however groups that would be nice if you could make the cutsom error handling groups code work, which would allow me to implement it. I must have missed something. Is there some error in what I implemented that hasn't been corrected yet? I may have missed some mail... -- 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]
Re: [openssl.org #629] Custom error handling
In message [EMAIL PROTECTED] on Thu, 3 Jul 2003 23:09:05 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups As I said earlier, you don't have to implement it, however groups that would be nice if you could make the cutsom error handling groups code work, which would allow me to implement it. I must have missed something. Is there some error in what I implemented that hasn't been corrected yet? I may have missed some mail... -- 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]
Re: [openssl.org #629] Custom error handling
The problem is the following, yes your code (ERR_pop_to_mark/ERR_set_mark) is fine when a child function is adding a new error, however, what happends when it calls ERR_clear_error ? In my implementation I need the error stack to be preserved even if a child function calls ERR_clear_error. That's why if you happended to remove the if (!err_fns) test in ERR_set_implementation, I would be more than happy. Frédéric Giudicelli http://www.newpki.org - Original Message - From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 03, 2003 11:46 PM Subject: Re: [openssl.org #629] Custom error handling In message [EMAIL PROTECTED] on Thu, 3 Jul 2003 23:09:05 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups As I said earlier, you don't have to implement it, however groups that would be nice if you could make the cutsom error handling groups code work, which would allow me to implement it. I must have missed something. Is there some error in what I implemented that hasn't been corrected yet? I may have missed some mail... -- 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] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
Sorry, I have been kind swanped latelly, I didn't have any time to reply to your previous email, although I read it. Why couldn't we just say that this function, is to use in some special cases, in my case I need because I don't want an error handling function being capable of calling ERR_clear_errors, et erase my error stack, before I had time to send it back to the user. However, the ERR_set_mark and ERR_pop_to_mark do not disable ERR_clear_errors, and it's something that I need to have in my project. If you don't feel like implementing it, why don't we really enable custom error handling functions? Since it's has been kind of implemented already, then I could do what I want without annoying everyone with my silly requests. Frédéric Giudicelli http://www.newpki.org - Original Message - From: Richard Levitte via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 20, 2003 12:20 AM Subject: [openssl.org #629] Custom error handling Just for the sake of keeping history with this ticket: I've concerns with ERR_disable() in relation to the OpenSSL code checking for certain errors in some places. If error setting is disabled, we might very well end up with unwanted problems. Sure, it can be fixed by temporarely re-enabling error setting, but that requires an extra effort from OpenSSL developpers, and this is easily forgotten. [levitte - Wed Jun 11 22:55:38 2003]: I've implemented ERR_set_mark() and ERR_pop_to_mark(), which can be used for similar functionality. I'll look into ERR_disable() and ERR_enable() as well, but that requires quite a lot more work. If the implemented functions are enough for you for now, I'll resolve this ticket. [EMAIL PROTECTED] - Mon May 26 09:16:48 2003]: Hi, I would like to implement some kind of error locking function: SYSerr(x,x); ERR_disable(); //We don't want anymore error feedback from this point //call to functions that can potentialy generate some more errors ERR_enable(); //Re-enable error feedback In this exemple the last error will be the one generated by SYSerr(x,x);. I tried to implement a custom error handling function, int_thread_get_item equivalent that would return NULL, if the thread error handling was locked, but any call to ERR_clear_error destroyed the SYSerr(x,x); error. The custom error handling doesn't seem to be really supported (ERR_FNS is opaque..., etc), altough the bases are there, could it be possible to either fully support custom error handling, or to add the ERR_enable/ERR_disable. Thanks, Frédéric Giudicelli http://www.newpki.org -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #629] Custom error handling
Just for the sake of keeping history with this ticket: I've concerns with ERR_disable() in relation to the OpenSSL code checking for certain errors in some places. If error setting is disabled, we might very well end up with unwanted problems. Sure, it can be fixed by temporarely re-enabling error setting, but that requires an extra effort from OpenSSL developpers, and this is easily forgotten. [levitte - Wed Jun 11 22:55:38 2003]: I've implemented ERR_set_mark() and ERR_pop_to_mark(), which can be used for similar functionality. I'll look into ERR_disable() and ERR_enable() as well, but that requires quite a lot more work. If the implemented functions are enough for you for now, I'll resolve this ticket. [EMAIL PROTECTED] - Mon May 26 09:16:48 2003]: Hi, I would like to implement some kind of error locking function: SYSerr(x,x); ERR_disable(); //We don't want anymore error feedback from this point //call to functions that can potentialy generate some more errors ERR_enable(); //Re-enable error feedback In this exemple the last error will be the one generated by SYSerr(x,x);. I tried to implement a custom error handling function, int_thread_get_item equivalent that would return NULL, if the thread error handling was locked, but any call to ERR_clear_error destroyed the SYSerr(x,x); error. The custom error handling doesn't seem to be really supported (ERR_FNS is opaque..., etc), altough the bases are there, could it be possible to either fully support custom error handling, or to add the ERR_enable/ERR_disable. Thanks, Frédéric Giudicelli http://www.newpki.org -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
In message [EMAIL PROTECTED] on Sat, 14 Jun 2003 05:08:50 +0200, Frédéric Giudicelli
[EMAIL PROTECTED] said:
groups Here are the patch (crypto/err), have been generated from
groups openssl-SNAP-20030612:
groups added: int disabled; to ERR_STATE and the following functions:
groups - ERR_disable
groups - ERR_enable
groups - ERR_force_enable (since I'm using a counter, it might be necessary)
groups - ERR_get_lock_status
groups - ERR_set_lock_status
groups
groups The functions ERR_force_enable, ERR_get_lock_status and
groups ERR_set_lock_status have been added for the following case of use:
groups
groups ...
groups ERR_disable();
groups foo1();
groups ERR_enable();
groups ...
groups
groups void foo1()
groups {
groups ...
groups ERR_disable();
groups foo2();
groups ERR_enable();
groups ...
groups }
groups
groups void foo2() //This function absolutely needs some error feedback
groups {
groups int err_status;
groups ...
groups err_status = ERR_get_lock_status();
groups ERR_force_enable();
groups ERR_print_errors_fp(stderr);
groups ERR_set_lock_status(err_status);
groups ...
groups }
I'm getting increasingly dubious about this kind of functionality.
Don't get me wrong here, the idea in itself is good. However, we need
to consider the consequences of such changes.
So, some consequences are that such changes may disturb the inner
workings of the OpenSSL code at all places where specific errors are
checked for. Granted, it would probably be quite easy to look for
ERR_peek_... function calls and wrap the necessary lines of code with
ERR_get_lock_status(), ERR_force_enable()...ERR_set_lock_status().
Now, consider new code being written, and a check for some potential
error being checked in that code, and *gasp* the wrapping code being
forgotten (and trust me, that's easily done). The code itself will
seem to work, and if the checked error appears seldom, the forgotten
wrapper won't be detected for quite a while, maybe over several
versions.
I think the above outlines the reason I'm a bit dubious about the
proposed enable/disable change.
--
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]
Re: [openssl.org #629] Custom error handling
In message [EMAIL PROTECTED] on Sat, 14 Jun 2003 05:08:50 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups Here are the patch (crypto/err), have been generated from groups openssl-SNAP-20030612: groups added: int disabled; to ERR_STATE and the following functions: groups - ERR_disable groups - ERR_enable groups - ERR_force_enable (since I'm using a counter, it might be necessary) groups - ERR_get_lock_status groups - ERR_set_lock_status I'll take a closer look in a few days, at the latest on thursday. -- 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]
Re: [openssl.org #629] Custom error handling
Here are the patch (crypto/err), have been generated from
openssl-SNAP-20030612:
added: int disabled; to ERR_STATE and the following functions:
- ERR_disable
- ERR_enable
- ERR_force_enable (since I'm using a counter, it might be necessary)
- ERR_get_lock_status
- ERR_set_lock_status
The functions ERR_force_enable, ERR_get_lock_status and
ERR_set_lock_status have been added for the following case of use:
...
ERR_disable();
foo1();
ERR_enable();
...
void foo1()
{
...
ERR_disable();
foo2();
ERR_enable();
...
}
void foo2() //This function absolutely needs some error feedback
{
int err_status;
...
err_status = ERR_get_lock_status();
ERR_force_enable();
ERR_print_errors_fp(stderr);
ERR_set_lock_status(err_status);
...
}
That's pretty much all I need for error disabling, nothing too fancy like
disabling errors handling for all threads contexts.
Frédéric Giudicelli
http://www.newpki.org
- Original Message -
From: Richard Levitte - VMS Whacker [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, June 12, 2003 12:33 AM
Subject: Re: [openssl.org #629] Custom error handling
In message [EMAIL PROTECTED] on Thu, 12 Jun 2003
00:22:28 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said:
groups Ok, I'll wait for you to tell me when the update on the error
groups handling will be done, I'll take it from there.
If you mean to ask for when the new functions ERR_set_mark() and
ERR_pop_to_mark() will be committed, they already are. They will be
visible in tomorrow's snapshot.
--
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.
err.h.patch
Description: Binary data
err.c.patch
Description: Binary data
[openssl.org #629] Custom error handling
I've implemented ERR_set_mark() and ERR_pop_to_mark(), which can be used for similar functionality. I'll look into ERR_disable() and ERR_enable() as well, but that requires quite a lot more work. If the implemented functions are enough for you for now, I'll resolve this ticket. [EMAIL PROTECTED] - Mon May 26 09:16:48 2003]: Hi, I would like to implement some kind of error locking function: SYSerr(x,x); ERR_disable(); //We don't want anymore error feedback from this point //call to functions that can potentialy generate some more errors ERR_enable(); //Re-enable error feedback In this exemple the last error will be the one generated by SYSerr(x,x);. I tried to implement a custom error handling function, int_thread_get_item equivalent that would return NULL, if the thread error handling was locked, but any call to ERR_clear_error destroyed the SYSerr(x,x); error. The custom error handling doesn't seem to be really supported (ERR_FNS is opaque..., etc), altough the bases are there, could it be possible to either fully support custom error handling, or to add the ERR_enable/ERR_disable. Thanks, Frédéric Giudicelli http://www.newpki.org -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
Ok. Is there a new release soon? I would like to have it implemented (ERR_disable/ERR_enable) by next release, I have no problem doing it, just want to know if I have time to do it. Frédéric Giudicelli http://www.newpki.org - Original Message - From: Richard Levitte via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, June 11, 2003 10:55 PM Subject: [openssl.org #629] Custom error handling I've implemented ERR_set_mark() and ERR_pop_to_mark(), which can be used for similar functionality. I'll look into ERR_disable() and ERR_enable() as well, but that requires quite a lot more work. If the implemented functions are enough for you for now, I'll resolve this ticket. [EMAIL PROTECTED] - Mon May 26 09:16:48 2003]: Hi, I would like to implement some kind of error locking function: SYSerr(x,x); ERR_disable(); //We don't want anymore error feedback from this point //call to functions that can potentialy generate some more errors ERR_enable(); //Re-enable error feedback In this exemple the last error will be the one generated by SYSerr(x,x);. I tried to implement a custom error handling function, int_thread_get_item equivalent that would return NULL, if the thread error handling was locked, but any call to ERR_clear_error destroyed the SYSerr(x,x); error. The custom error handling doesn't seem to be really supported (ERR_FNS is opaque..., etc), altough the bases are there, could it be possible to either fully support custom error handling, or to add the ERR_enable/ERR_disable. Thanks, Frédéric Giudicelli http://www.newpki.org -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
In message [EMAIL PROTECTED] on Wed, 11 Jun 2003 23:52:17 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups Ok. groups Is there a new release soon? I would like to have it implemented groups (ERR_disable/ERR_enable) by next release, I have no problem doing it, just groups want to know if I have time to do it. 0.9.8 isn't even in freeze, so you've got time. -- 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]
Re: [openssl.org #629] Custom error handling
Ok, I'll wait for you to tell me when the update on the error handling will be done, I'll take it from there. Frédéric Giudicelli http://www.newpki.org - Original Message - From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 12:22 AM Subject: Re: [openssl.org #629] Custom error handling In message [EMAIL PROTECTED] on Wed, 11 Jun 2003 23:52:17 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups Ok. groups Is there a new release soon? I would like to have it implemented groups (ERR_disable/ERR_enable) by next release, I have no problem doing it, just groups want to know if I have time to do it. 0.9.8 isn't even in freeze, so you've got time. -- 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] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
In message [EMAIL PROTECTED] on Thu, 12 Jun 2003 00:22:28 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups Ok, I'll wait for you to tell me when the update on the error groups handling will be done, I'll take it from there. If you mean to ask for when the new functions ERR_set_mark() and ERR_pop_to_mark() will be committed, they already are. They will be visible in tomorrow's snapshot. -- 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]
Re: Custom error handling
Ok, the code would be something like this: if(err-disable) return; On a x86 cpu: read err: 1 cycle read disable: 1 cycle if : 3/5 cycles We don't count the return since it's conditional and in any events it will be called. I think that modern CPU will be capable of handling the 5/7 extra cycles, in those 4 functions :) Frédéric Giudicelli http://www.newpki.org - Original Message - From: Rich Salz [EMAIL PROTECTED] To: Frédéric Giudicelli [EMAIL PROTECTED] Cc: Richard Levitte - VMS Whacker [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 1:33 PM Subject: Re: Custom error handling 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 Modifying all the code to check are errors enabled and then do the right thing will take more CPU and the library will be bigger, taking more RAM. Richard's idea is much better. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Custom error handling
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 Modifying all the code to check are errors enabled and then do the right thing will take more CPU and the library will be bigger, taking more RAM. Richard's idea is much better. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Custom error handling
In message [EMAIL PROTECTED] on Mon, 26 May 2003 08:57:40 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups Hi, groups I would like to implement some kind of error locking function: groups groups SYSerr(x,x); groups ERR_disable(); //We don't want anymore error feedback from this point groups //call to functions that can potentialy generate some more errors groups ERR_enable(); //Re-enable error feedback I'd like to suggest something different that could be used for the same purpose: ERR_mark() Puts a mark in the error stack ERR_pop_to_mark() Pops off errors from the error stack until a mark is found. The mark itself is popped as well. The reason for this is that there may be situations where you might want to add a mark, do something, then check for certain errors and only remove the errors upto the mark if they appear. Your example would be fulfilled like this: SYSerr(x,x); ERR_mark(); //We don't want anymore error feedback from this point //call to functions that can potentialy generate some more errors ERR_pop_to_mark(); //Re-enable error feedback The only difference is that this consumes a little more memory and CPU, temporarly... -- 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]
Re: Custom error handling
ERR_mark()Puts a mark in the error stack ERR_pop_to_mark() Pops off errors from the error stack until a mark is found. The mark itself is popped as well. Do they nest? Perhaps this is cleaner: int depth = ERR_get_depth(); void ERR_pop_to(int depth); /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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]
Re: Custom error handling
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]
