Re: NOPROTO

Ulf Moeller wrote: > > This script parses the OpenSSL header files and prints a list of the > functions declared in the prototypes. > It seems to do a very good job. It does get a bit confused by function pointer typedefs and it doesn't like some multi line #define's in evp.h but it should be f

WIN32 DEF Missing call

Hi, I was attempting to use Borland C Builder to connect to the win 32 dlls created by Visual C 6. I have had few issues but ran into a missing Libeay32 function call, the function is: ERR_get_error_line_data and does not show up in the .def file at all. For this reason C Builder was unable to

Error codes.

Richard Levitte - VMS Whacker wrote: > > drh> Personally I'm against this. It'll just be extra baggage to > drh> install (and get working cross platform) and extra dependencies > drh> with IMHO minimal benefits. > > The dependencies is something I don't view as a problem, but I think > that avoi

Re: LP64: blowfish woes

On Tue, Apr 20, 1999 at 06:14:36PM +0100, Dr Stephen Henson wrote: >> proposal to include the .err files instead of copying them in. > Personally I'm against this. It'll just be extra baggage to install (and > get working cross platform) and extra dependencies with IMHO minimal > benefits. Hoew

Re: NOPROTO

> Err what script? func.pl

Re: LP64: blowfish woes

drh> Personally I'm against this. It'll just be extra baggage to drh> install (and get working cross platform) and extra dependencies drh> with IMHO minimal benefits. The dependencies is something I don't view as a problem, but I think that avoiding to have .err files installed is a valid reason.

Re: NOPROTO

Ulf Moeller wrote: > > This script parses the OpenSSL header files and prints a list of the > functions declared in the prototypes. > Err what script? > Would someone who is more familiar with mkdef.pl and err_genc.pl care > to integrate it in those scripts? > Sure, when I see it I'll check

Re: LP64: blowfish woes

Ulf Moeller wrote: > > (And I support Richard's > proposal to include the .err files instead of copying them in. > Is there any reason for not doing that?) > Personally I'm against this. It'll just be extra baggage to install (and get working cross platform) and extra dependencies with IMHO mini

NOPROTO

This script parses the OpenSSL header files and prints a list of the functions declared in the prototypes. Would someone who is more familiar with mkdef.pl and err_genc.pl care to integrate it in those scripts? __ OpenSSL Projec

Re: LP64: blowfish woes

> > #if !defined(BF_PTR) && !defined(BF_PTR2) > > #define BF_PTR > > #endif > i.e. the comment is effectively *disregarded*, isn't it? This is autogenerated in Configure. My vote is for generating just one file config.h and include it where necessary, to avoid this confusion. (And I support Rich

Re: s2_pkt.c

On Tue, Apr 20, 1999 at 11:51:48AM +1000, Clifford Heath wrote: >> You won't get non-blocking behaviour... The SSL 2 version... The selet() >> result is valid only for the first iteration, the second interation >> may block despite of what select() said. > I'm aware of these behaviours, but we a

Solaris 7/64 config line

Hi! For those who dare:-) With all my "LP64 woes" patches applied drop following into Configure and experience the power of 64 bits computing with UltraSPARC. "solaris64-usparc-cc","cc:-xtarget=ultra -xarch=v9 -Xa -xO5 -xdepend -xstrconst -DB_ENDIAN:\ -lsocket -lnsl:\ SIXTY_FOUR_

RE:

Andrea -   > where is the best place to take value to compose a correct OCSP request > and response, during client authentication and how ? > (values like X_509_NAME*, STACK*, EVP_MD*, EVP_PKEY* ) >  I think to take them in function get_client_certificates in module s3_srvr.c and >  I'm trying

2000 secure?

Hi all! I wonder if SSLeay0-9-0b is year 2000 secured considering certification and runtime? Further i wonder if there is a way to generate certificates that never expires (valid an infinite number of days), and if not what is the max? Any help would be great! /Regards Paul ___

LP64: sha woes

Hi! Me again:-) Ready for more LP64 woes? T-d... Turn for sha this time. Well, I suppose you've already figured with out from the subject, huh? Same *damn* problem as with blowfish. Namely traversing array of ints as array of longs. Check it out... >From sha.h: > #define SHA_CBLOCK64

Re: LP64: blowfish woes

Hello again! I wrote: > > #elif defined(BF_PTR) > > > > /* This is normally very good */ > > > > #define BF_ENC(LL,R,S,P) \ > > LL^=P; \ > > LL^= (((*(BF_LONG *)((unsigned char *)&(S[ 0])+((R>>BF_0)&BF_M))+ \ > > *(BF_LONG *)((unsigned char *)&(S[256])+((R>>BF_1)&BF_M))