Dj Browne wrote:
>
> On Tue, 11 Jan 2000, Richard Levitte - VMS Whacker wrote:
>
> [edit]
>
> ->
> ->Otherwise, I must say that I personally would like things to Become
> ->Right rather than keeping Bug Compatibility, if one has to choose. So
> ->I'd choose to put correctly updated and used reference counters
> ->everywhere (or at least where it's relevant).
> ->
> ->Yes, there will be some struggle with old code that will break, but I
> ->think that the future will look better with better consistency.
>
> I usually keep my mouth shut on this list but this is something
> important! :)
>
> Richard is completely and utterly correct. Make the changes to get this
> done right the first time instead of propagating these problems forward
> into a growing install base. Do it now rather than later!
>
> I believe it is more important to have a consistent API going into
> version 1.0.0 and to break binary compatibility now than to have to
> constantly watch out for (and explain to every new developer) the quirks
> in the code.
>
The problem here is what is right?
Its not that clear cut.
If we decide that all the get/set/add functions should up reference
counts then you have to add reference counts to all manner of things or
Malloc() copies.
Any code that relies on the old behaviour will end up leaking memory all
over the place.
Alternatively if we decide that nothing should up reference counts then
anything which assumes that the structure is persistent will crash when
one of them gets freed.
Doing either will break lots of existing code need major rewrites and
probably get several of us lynched :-)
So the alternative is to have a naming convention and just say the old
functions are retained for backwards compatibility. Any future
documentation might not even document the old functions to encourage the
use of the new versions.
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]
