From: Bill Rebey <[EMAIL PROTECTED]>
Bill.Rebey> 1) Building with 'no-rsa' (compiler: -DNO_RSA) causes
Bill.Rebey> link errors on UNIX. I "fixed" the problem, but my fix
I just tested with just no-rsa no a Solaris machine using GNU c, and
it went through with no errors.
Bill.Rebey> Specifical
Ulf Möller wrote:
>
> I posted a note about an error in the config file regarding Linux 1
> and a bug in rand/randfiles.c on Debian Linux a few days ago. Did
> anybody notice, or should I send mail to some other address
> ([EMAIL PROTECTED] or so)?
I noticed. They're in my list...
Cheers,
Ben.
I posted a note about an error in the config file regarding Linux 1
and a bug in rand/randfiles.c on Debian Linux a few days ago. Did
anybody notice, or should I send mail to some other address
([EMAIL PROTECTED] or so)?
__
OpenSS
There's a bug in the config file:
--- config~ Mon Dec 21 11:58:38 1998
+++ config Sat Jan 9 01:18:01 1999
@@ -300,7 +300,7 @@
case "$GUESSOS" in
alpha-*-linux2) OUT="alpha-gcc" ;;
*-*-linux2) OUT="linux-elf" ;;
- *-*-linux) OUT="linux-aout" ;;
+ *-*-linux1) OUT="linux-aout" ;;
In article <[EMAIL PROTECTED]> you wrote:
> [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
> I can't see the problem here. The check is:
>
> if ((s->s2->wpend_tot > (int)len) || (s->s2->wpend_buf != buf))
sorry, once again i did not check the latest source carefully enough. i
still use 0.8.1 and there the check readed:
if ((s->s2->wpend_tot != (int)len) || (s->s2->wpe
[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
>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
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
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
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
[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
>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$
___
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
>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
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
> 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
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
> > 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
Arne Ansper wrote:
>
> hi!
>
> i would like to report some bugs in ssleay. unfortunately i don't have
> diffs against latest openssl source, but the fixes are really small, so i
> hope it's not too much trouble to incorporate them.
>
> 1) crypto/bio/b_printf.c uses static buffer for vsprintf wh
20 matches
Mail list logo
