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]
