Jeffrey Altman wrote:
>
>
> So in other words you plan to implement two versions of every single
> function? And then leave it up to the caller to determine what the
> behavior should be? This is going to be a nightmare.
>
I'm not sure what you mean by that. What we could have is one "official"
version in the cases where it isn't apparent what is returned from
context.
For example when a pointer is returned it isn't obvious if it is
persistent. If (for example) an int is returned or used then there is no
ambiguity.
The older versions could be retained for now but no guarantee that they
always will be.
Nothing is certain yet. I'm beginning to think the whole idea should be
scrapped in favour of retaining the ambiguity but documenting it.
I'd love to have the freedom to break existing code all over the place.
The first thing I'd dump would be EVP probably followed closely behind
by the ASN1 stuff.
Unfortunately there is quite a large code base dependent on the current
behaviour. Minor changes to the API can be accommodated: something that
forces all existing code to be rewritten would be IMHO hard to justify.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
