Two use cases:
1) Developer who wants to use internal OpenSSL functionality that is
not exposed via API. Said developer must, by definition, muck about
in the internals of the library to find the correct symbol and hope
that the version he's using has the same parameters.
2) Error in OpenSSL, where it performs the incorrect operation on a
piece of data but it's not caught until after QA vetting.
Don't mind me too much, I've just been looking at the "programming by
contract" model of late. Ensure preconditions are met, operate how
you're supposed to, ensure that the state is sane, and verify that the
returned data meet some "arbitrary" definition of sanity. (For
example, say, a means of passing a blob into a set of code in the
library and have that code be able to determine what that blob
actually represents, be it a secret key, private key, public key,
certificate, ASN.1 string, BIO structure, etc).
-Kyle H
On 7/21/06, Richard Salz <[EMAIL PROTECTED]> wrote:
I guess I don't understand. At one point you mention that C++ wrappers
don't meet the need because you are addressing corruption "by something
that occurred inside OpenSSL," yet later on you say you're trying to
address the library being used in the wrong way. No biggie, I'll wait
until code (fragments) are posted. But if you're trying to enforce
correctness, then again a more strongly-typed language seems to make more
sense; magic numbers in structures seem a little untrustworthy.
/r$
--
SOA Appliances
Application Integration Middleware
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
