> >I would modify it as such:
> >
> > volatile unsigned char *
> > CRYPTO_cleanse(volatile void *ptr, size_t len) {
> > volatile static unsigned char foo = 0;
> > volatile unsigned char *p = ptr;
> > size_t loop = len;
> > while(loop--) {
> > *(p++) = foo++;
> > foo += (17 + (unsigned char)(p & 0xF))
> > }
> > if(memchr(ptr, foo, len))
> > foo += 63;
> > return(&foo);
> > }
> >
> >
> i know that probably this is not conern for now but doesn't this code is
> not thread safe ,
> meaningly this could be even better , because erased buffer will be
> filled partially with values from several threads
> or this code could be worse , cause it will require some sort of lock
> before getting to function ??
> or i'm wrong about this one ???
Its perfectly ok for this function to be called as written from
multiple threads. It is the fact that there is a buffer that is read
and written that is not entirely predictable that ensures the function
cannot be optimized out.
Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!!
The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP
http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and
[EMAIL PROTECTED] OpenSSL.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
