There's a similar problem that I ran into when I wanted to use the debug dll
version of the runtime library: Things like file handles will also be different.
So this following piece of code will crash:
fp=fopen(cert_file,"rb");
b=BIO_new_fp(fp,0);
cert=d2i_X509_bio(b,0); <== This will crash in NTDLL.DLL
Replacing the first two with BIO_new_file(cert_file,"rb") works, but what
I really wanted to do was to use _fsopen to get thread-safe access to a file
that might get updated any time by another thread.
So I propose that a new function be added to OpenSSL:
BIO_new_shared_file(char *filename,char *mode)
where mode can contain sharing modes as well as the normal r/w modes etc.
Of course if I have missed that there is something I could use to achieve
what I wanted someone will surely point it out...
/Per
----- Original Message -----
From: Per Nilsson <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 05, 2000 1:18 PM
Subject: RE: CRYPTO_malloc_init undefined in latest snapshot
> It needs to be a macro so malloc etc will be the ones from the program,
> and not the ones linked into the DLL. This makes a difference if the DLL
> and the program are linked against different runtime libs. Precisely the
> reason why CRYPTO_set_mem_functions should be used in those cases.
>
> /Per
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte - VMS
> > Whacker
> > Sent: Wednesday, January 05, 2000 10:50 AM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: CRYPTO_malloc_init undefined in latest snapshot
> >
> >
> > jaltman> If the LIBEAY32.DLL is linked to the MSVCRT.DLL library
> > and the app
> > jaltman> is linked to MSVCRTD.DLL it is necessary for
> > CRYTPO_malloc_init() to
> > jaltman> be executed by the app so that the proper memory
> > jaltman> allocation/deallocations routines are used.
> >
> > CRYPTO_malloc_init() did the following:
> >
> > CRYPTO_set_mem_functions(malloc,realloc,free)
> >
> > This in turn initialises five function pointers in mem.c. However,
> > those variables are already initialised with exactly those values.
> > Logically, this makes the CRYPTO_malloc_init() macro redudant and
> > needless.
> >
> > Is this possibly some kind of glitch in Win32 when it links things in
> > runtime, or is it some other mystery?
> >
> > --
> > Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
> > Redakteur@Stacken \ S-161 43 BROMMA \ T: +46-8-26 52 47
> > \ SWEDEN \ or +46-708-26 53 44
> > Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
> >
> > Unsolicited commercial email is subject to an archival fee of $400.
> > See <http://www.stacken.kth.se/~levitte/mail/> for more info.
> > ______________________________________________________________________
> > OpenSSL Project http://www.openssl.org
> > Development Mailing List [EMAIL PROTECTED]
> > Automated List Manager [EMAIL PROTECTED]
> >
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
smime.p7s
