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]

Reply via email to