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]

Reply via email to