Lennart Bang wrote:
>
>
> I realize the 'reason' for using the malloc instead of Malloc in enc_writ.c
> and enc_read.c could be to lessen the spam in the CRYPTO_mem_leaks print'out.
> But if that is the reason, I suggest declaring a new set of macros for such
> use.
>
Well another reason might be that thats one of the oldest parts of the
library and it never got changed :-)
> The patch included gets rid of 4 references to malloc (also mentioned before)
> and 1 reference to free. There are still 5 references left in mem.c used for
> the static initialization of the malloc/free funcs in which I am not sure what
> you want do do with? I added 'crypto' in front of them and made a set of
> cryptoxxx stubs.
>
Hmmm, how about a NO_DEFAULT_MALLOC option that sets the default
allocation functions to something that always fails (maybe with an
abort() or assertion failure?) and doesn't reference malloc, free,
realloc at all?
It would then be the programmers responsibility to set them to something
sensible.
>
> ps: I realize you got a hectic time-schedule due to the 0.9.2 so I dont
> really expect you to enter this asap but please at least give a short
> 'ok' so I know I if I can expect them later or if I have to add them to
> my own prepare scripts (want to automate updates).
>
Well I regard the direct malloc, free references as definite bugs so
I've just checked them in. Having an option to remove the static
references in mem.c may not make it into the release: I suppose it could
count as a "new feature", albeit a very minor one.
Thanks for the report, Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
