Hello.

With 0.9.6j and today's 0.9.6 snapshot (20030605), I get
many UMRs when running our applications with Purify.

I am compiling these builds with -DPURIFY.

I have attached two patches that I would like you to
consider.

I know I can (and I do) filter these UMRs in Purify, but
the large amount of generated warnings (100000's) seems
to upset it and make it (Purify) crash/freeze more often.

asn1_mac.h:
  The inf and eos fields of ASN1_CTX are not initialized,
  causing this test:

  if ((c->inf == (1|V_ASN1_CONSTRUCTED)) && (!c->eos))

  ..in asn1_lib.c:266 to work with stack garbage. It
  might not be fatal, but should probably be looked into.

rand_win.c:
  PROCESSENTRY32 and MODULEENTRY32 structures are
  filled in by the OS, but the structures contain
  null-terminated (MAX_PATH long) string variables.
  The unused bits of these strings are left
  uninitialized, causing [MAX_PATH - strlen - 1]
  UMR warnings.


I considered using OPENSSL_cleanse instead of memset
to initialize the arrays, but came to the conclusion
that OPENSSL_cleanse probably was not intended
primarily for this purpose (feel free to disagree).

I don't mind putting the memsets in #ifdef PURIFY
blocks, but don't really see the need to it in this
case.


The snapshot initially failed to compile on VC-WIN32
due to the following warning:
.\crypto\bn\bn_mul.c(379) : warning C4018: '<' : signed/unsigned mismatch

I haven't looked into this, and merely compiled
without /WX (treat warnings as errors).


Lastly, I would like to apologize in advance if this
information is obsolete, wrong or in any way improperly
delivered.



Best Regards,


�ivind Hardy Danielsen

Attachment: rand_win.c.patch
Description: Binary data

Attachment: asn1_mac.h.patch
Description: Binary data

Reply via email to