When you speak of breaking existing applications, I guess you mean
applications based on the s_server code (or those that use sockets). As
someone who has written code based on BIOs and not sockets, I am somewhat
concerned that BIO reference counts are broken. Apparently I cannot make my
code robust!
We're still not at release 1.0. Please, can something be done?
> -----Original Message-----
> From: Dr Stephen Henson [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, 10 November 1999 8:19
> To: [EMAIL PROTECTED]
> Subject: Re: X509 reference counts
>
> Geoff Thorpe wrote:
> >
> > Hi,
> >
> > On Tue, 9 Nov 1999, Dr Stephen Henson wrote:
> >
> > > Yes horrible isn't it?
> > >
> > > I've also noticed wildly inconsistent behaviour. When you call
> something
> > > like XXX_get_YYY() you might get something which will last only as
> long
> > > as the parent and it shouldn't be freed at all or something which will
> > > persist by virtue of the upped reference count.
> >
> > sure is horrible ... I played around with this quite a bit yesterday and
> > the further in I looked the weirder it got. I'd ask why it is this way
> but
> > I'm not sure I want to know. :-)
> >
>
> Well I don't know the reason myself but from looking at the code I'd
> guess that those functions that return an object with an upped reference
> count tend to be those where its likely the application will want to
> keep the object around. This things like X509_get_version() will return
> an internal pointer because you are more likely to just check the value
> and do nothing else whereas with other examples you might want to keep
> the object afterwards.
>
> Of course having said that this isn't consistent and I changed the
> X509_get_pubkey() behaviour myself to up the public key reference count.
> Tracing and fixing all the memory leaks this caused was not an easy task
> :-(
>
> Changing the logic is problematical not just because of the effort
> involved. Many programs will expect the old behaviour. In the example of
> a multithreaded server its memory requirements will grow steadily if
> they don't free things up: this is one case where a multithreaded server
> is at a disadvantage compared to a fork() + exit() kind.
>
> 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]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
