Re: some bugs

1999-01-05 Thread Arne Ansper
> > 3) crypto/bio/bf_buff.c buffer_gets does not insert final '\n' into > > buffer. so it is not semanticaly equivalent with fgets. this is my version > > of buffer_gets: > > My reading of the current OpenSSL source says this is fixed. It'd be > nice if you could confirm that. sorry i did not

Shared Libraries

1999-01-05 Thread Niels Poppe
Here is a small patch to Makefile.org to build shared libraries, at least for linux/alpha (RedHat) and linux/mips (a Cobalt Qube, also derived from RedHat): Index: Makefile.org === RCS file: /usr/src/rsync/openssl//openssl/Makefile.o

Re: openssl binary

1999-01-05 Thread John Saylor
Hi Even though I haven't contributed a line of code, I do use the library and apps every day. So I'll vote anyway- you can always just ignore it. > "RSE" == Ralf S Engelschall <[EMAIL PROTECTED]> writes: [x] RSE> So, I want to cleanup apps/ as following: RSE> 1. No generation of links. y

Re: some bugs

1999-01-05 Thread Ben Laurie
Arne Ansper wrote: > > > 5) crypto/err/err.c ERR_get_state has static variable fallback. this > > > should be initalized before returning pointer to it. > > > > As far as I can see it is only used when allocation fails. In this case, > > what should it be initialised to? > > at least top and bott

Re: some bugs

1999-01-05 Thread Arne Ansper
> Since it is a static, they will already be clear. you are right. arne __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated Lis

Re: Shared Libraries

1999-01-05 Thread Ng Pheng Siong
On Jan 5, Niels Poppe wrote: > Here is a small patch to Makefile.org to build > shared libraries, at least for linux/alpha (RedHat) > and linux/mips (a Cobalt Qube, also derived from RedHat): What's wrong with shlib/linux.sh? (I haven't tried it myself, not having (re)installed Linux.) Anyways,

Re: some bugs

1999-01-05 Thread Ralf S. Engelschall
In article <[EMAIL PROTECTED]> you wrote: >> Since it is a static, they will already be clear. > you are right. Nevertheless it's clean coding style to initialize the stuff explicitly IMHO. Because this "ANSI C requires static's to be initialized to 0" rule one often forgets when you read thro

RE: some bugs

1999-01-05 Thread salzr
>Nevertheless it's clean coding style to initialize the stuff explicitly IMHO. For what it's worth, I strongly disagree. It gets particularly cumbersome when the static is some big struct or array. __ OpenSSL Project

Re: some bugs

1999-01-05 Thread Ben Laurie
Ralf S. Engelschall wrote: > > In article <[EMAIL PROTECTED]> you wrote: > > >> Since it is a static, they will already be clear. > > > you are right. > > Nevertheless it's clean coding style to initialize the stuff explicitly IMHO. > Because this "ANSI C requires static's to be initialized to

RE: some bugs

1999-01-05 Thread salzr
>BTW, it isn't ANSI, its just C. This brings up another question. How important is 16bit and K&R C support? I claim it's feasible to leave those platforms dead-ended with SSLeay0.9.b. I'd really like to see us move to prototypes, const, etc. /r$ ___

Re: some bugs

1999-01-05 Thread Ben Laurie
[EMAIL PROTECTED] wrote: > > >BTW, it isn't ANSI, its just C. > > This brings up another question. > > How important is 16bit and K&R C support? > > I claim it's feasible to leave those platforms dead-ended with SSLeay0.9.b. > > I'd really like to see us move to prototypes, const, etc. So wo

Re: some bugs

1999-01-05 Thread Ben Laurie
Arne Ansper wrote: > > > 8) ssl/s2_pkt.c and ssl/s3_pkt.c write_pending and > > > ssl3_write_pending have unnecessary check at the beginning which stops > > > me from moving data around in my buffers between calls to SSL_write. > > > this data is already copied to internal buffers and there is no

Re: some bugs

1999-01-05 Thread Ralf S. Engelschall
In article <[EMAIL PROTECTED]> you wrote: >>Nevertheless it's clean coding style to initialize the stuff explicitly > IMHO. > For what it's worth, I strongly disagree. It gets particularly cumbersome > when the static is some big struct or array. For large structures this maybe the case, yes

Re: some bugs

1999-01-05 Thread Ralf S. Engelschall
In article <[EMAIL PROTECTED]> you wrote: > [EMAIL PROTECTED] wrote: >> >> >BTW, it isn't ANSI, its just C. >> >> This brings up another question. >> >> How important is 16bit and K&R C support? >> >> I claim it's feasible to leave those platforms dead-ended with SSLeay0.9.b. >> >> I'd reall

RE: some bugs

1999-01-05 Thread salzr
>For large structures this maybe the case, yes. But even there you either >already use some sort of constructors or at least just can initialize it with >a memcpy(ptr, 0, sizeof(ptr)) explicitly. Ugh, no. I don't want to turn this list into comp.lang.c, but From the beginning of time, C

Re: some bugs

1999-01-05 Thread Ben Laurie
[EMAIL PROTECTED] wrote: > > >For large structures this maybe the case, yes. But even there you either > >already use some sort of constructors or at least just can initialize it > with > >a memcpy(ptr, 0, sizeof(ptr)) explicitly. > Note that the memcpy idea is wrong for two reasons: > It

Re: Shared Libraries

1999-01-05 Thread Niels Poppe
Ng Pheng Siong wrote: > > On Jan 5, Niels Poppe wrote: > > Here is a small patch to Makefile.org to build > > shared libraries, at least for linux/alpha (RedHat) > > and linux/mips (a Cobalt Qube, also derived from RedHat): > > What's wrong with shlib/linux.sh? (I haven't tried it > myself, not

Re: Shared Libraries

1999-01-05 Thread Niels Poppe
Sorry to reply on my on mail. I might have misunderstood your message - are you saying this patch does not work on BSD? Niels Poppe wrote: > > Ng Pheng Siong wrote: > > > > On Jan 5, Niels Poppe wrote: > > > Here is a small patch to Makefile.org to build > > > shared libraries, at least for lin