> > 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
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
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
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
> 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
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,
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
>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
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
>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$
___
[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
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
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
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
>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
[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
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
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
18 matches
Mail list logo