Recent openssl is required for OPENSSL_free [Re: Please test snapshots for 3.0 release] (fwd)

[Lutz Jaenicke]

On Tue, Oct 30, 2001 at 10:12:02AM -0600, mouring at etoh.eviladmin.org wrote:
> On Tue, 30 Oct 2001, Lutz Jaenicke wrote:
> > OPENSSL_free() was introduced with OpenSSL 0.9.6, for OpenSSL 0.9.5, free()
> > is the correct way to go. In order to allow the use of 0.9.5, OPENSSL_free()
> > must be replaced (for <0.9.6 only), because we get an unresolved symbol error
> > otherwise.
> >
> 

> Still does not answer the underlying question.  if OPENSSL_free() ==
> free() why have OPENSSL_free()?  Feels like an API for the sake of an API
> unless there is plans to make OPENSSL_free() do more.  At which point this
> change will be a bad thing.

The following excerpts from the CHANGES file should explain the fundamental
idea behind using specific functions for the memory handling. Practically,
as long as no debugging routines are enabled, it comes done to malloc()
and friends...

...
 Changes between 0.9.5a and 0.9.6  [24 Sep 2000]
...
  *) Rename memory handling macros to avoid conflicts with other
     software:
          Malloc         =>  OPENSSL_malloc
          Malloc_locked  =>  OPENSSL_malloc_locked
          Realloc        =>  OPENSSL_realloc
          Free           =>  OPENSSL_free
...
 Changes between 0.9.4 and 0.9.5  [28 Feb 2000]
...
  *) Rebuild of the memory allocation routines used by OpenSSL code and
     possibly others as well.  The purpose is to make an interface that
     provide hooks so anyone can build a separate set of allocation and
     deallocation routines to be used by OpenSSL, for example memory
     pool implementations, or something else, which was previously hard
     since Malloc(), Realloc() and Free() were defined as macros having
     the values malloc, realloc and free, respectively (except for Win32
     compilations).  The same is provided for memory debugging code.
     OpenSSL already comes with functionality to find memory leaks, but
     this gives people a chance to debug other memory problems.
...

> Not arguing this is not need.  I just would like to get a sense of why.

:-)
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153