appro> > appro> Log: appro> > appro> size_t-fication of message digest APIs. We should size_t-fy more appro> > appro> APIs...
Well, I think I've worked in a different way than you.
I simply had different "excuse," introduction of fresh code, SHA-512 and co:-)
^^^^^ That's the problem with this approach. It gets so big, you start feeling insecure, don't you? Not that is's wrong approach, it just takes more guts to attack the problem... Yet I'd prefer to see changes applied in "zones," say ciphers, bio, asn1, etc., not as monolith mumbo-jumbo. It would be easier to grasp and audit. And I don't think everything has to be size_t-fied. In some situations it might be easier and in a sense more appropriate to leave API unchanged. BN and PKI stuff for example. In a cipher case there is a *remote* possibility that someone would like to take full advantage of size_t. But in BN or PKI case on the other it would/should be considered as a DoS attack. A.I started with the memory allocation functions and let the effects spread. I've also taken a look at some header files and adjusted what needed to be adjusted, then modified all C files where the compiler complained. This work is still going on...
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
