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, wh
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
On 7/21/06, Richard Salz <[EMAIL PROTECTED]> wrote:
> I guess I'm trying to look at this from a "guarantee-of-parameter",
> "operation", "guarantee of output integrity" contract-based
> programming view.
It might make more sense to do this with C++ classes built on top of the C
API. If you had
> I guess I'm trying to look at this from a "guarantee-of-parameter",
> "operation", "guarantee of output integrity" contract-based
> programming view.
It might make more sense to do this with C++ classes built on top of the C
API. If you had a common base class with void*,size_t, and then defin
I don't know if this is the proper place to bring this up, or if a
project fork would be more appropriate (given the investment that
exists in the current API/ABI)...
I would like to be able to determine and document what parameters of a
cryptographic object passed to any given library function m
