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

[mouring at etoh.eviladmin.org]

Thanks.

On Tue, 30 Oct 2001, Lutz Jaenicke wrote:

> 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
>