On Mon, Nov 11, 2002 at 05:50:18PM +0100, [EMAIL PROTECTED] wrote:
The aCC is a C++/ANSI C combination compiler. The cc in our machine is
an old-style c compiler. Unfortunately, we do not have gcc on our
machine.
To my knowledge aCC is C++ only. At least it is at HP-UX 10.20.
gcc is available
On Mon, Nov 11, 2002 at 07:31:15PM +0100, [EMAIL PROTECTED] wrote:
I think that is a bug. look at the following lines from mem_dbg.c
253 static int app_info_cmp(APP_INFO *a, APP_INFO *b)
...
258 static unsigned long app_info_hash(APP_INFO *a)
...
321 if
I just committed a change for this, can you try it please?
[bodo - Mon Nov 4 12:59:15 2002]:
The AES library (0.9.7-dev, 0.9.8-dev) abuses assert() to check
for invalid function parameters.
For aes_cbc.c, this includes the case where 'length' is not
a multiple of AES_BLOCK_SIZE. For
Hi,
Situation:
==
1.) Call: pCipher=EVP_get_cipherbyname(RC2-CBC)
2.) Call: EVP_CIPHER_CTX_init(ec_ctx)
3.) Call: EVP_CipherInit(ec_ctx,pCipher,byKey,byIV,1)
byKey contains 16 octets (128bit RC2 key)
4.) Call: VP_CIPHER_CTX_ctrl(ec_ctx,EVP_CTRL_SET_RC2_KEY_BITS,40,0L);
to set
On Tue, Nov 12, 2002, Developer via RT wrote:
Hi,
Situation:
==
1.) Call: pCipher=EVP_get_cipherbyname(RC2-CBC)
2.) Call: EVP_CIPHER_CTX_init(ec_ctx)
3.) Call: EVP_CipherInit(ec_ctx,pCipher,byKey,byIV,1)
byKey contains 16 octets (128bit RC2 key)
4.) Call:
I will try to explain what goes on again.
OpenSSL uses ZLIB compression in the following manner:
On each block of data transmitted, compress() is called.
It's equivalent to deflateInit() + deflate() + deflateEnd().
On a reliable continuous stream of data you can use it in the
Here are some patches for MSDOS and djgpp using Watt-32 tcp/ip stack.
Patch against snapshot 11-Nov 2002.
1. sock_init() renamed to ssl_sock_init() in ./apps/s_socket.c due
to name-clash with Watt-32.
2. rand() renamed to Rand() in ./crypto/bn/divtest.c due to name-clash
with stdlib.h
3.
I am trying to understand why ZLIB is being used that way. Here is what
gives better results on a continuous reliable stream of data:
1) You create a z_stream for sending, and another z_stream for
receiving.
2) You call deflateInit() and inflateInit() on them, respectively,
when
Here are some patches for MSDOS and djgpp using Watt-32 tcp/ip stack.
Patch against snapshot 11-Nov 2002.
1. sock_init() renamed to ssl_sock_init() in ./apps/s_socket.c due
to name-clash with Watt-32.
2. rand() renamed to Rand() in ./crypto/bn/divtest.c due to name-clash
with stdlib.h
3.
Well IETF didn't answer...
I'm guessing that M$ is wrong, that would not be the first time, howerver
the real question now, is how do you contact M$, the report the bug, the guy
I was in contact with, is:
krish shenoy[MS] [EMAIL PROTECTED]
He claims that M$ is right, I guess I'll let you big guys
RFC2246 mentions compression state in their list of
connection states.
It also says the following:
6.2.2. Record compression and decompression
[snip snip] The compression
algorithm translates a
TLSPlaintext
structure into a TLSCompressed structure.
Compression
functions are
6.2.2. Record compression and decompression
[snip snip] The compression algorithm translates a
TLSPlaintext structure into a TLSCompressed structure. Compression
functions are initialized with default state information whenever a
connection state is made active.
The connection
On Wed, 2002-11-06 at 15:50, Richard Levitte via RT wrote:
I assume you're talking about the following, which has a hard-coded
call to gcc.
DETECT_GNU_LD=${CC} -v 21 | grep '^gcc' /dev/null 21 \
my_ld=`gcc -print-prog-name=ld 21` \
[ -n $$my_ld ] \
$$my_ld -v 21 |
The ticket is now resolved.
[[EMAIL PROTECTED] - Wed Nov 13 04:39:14 2002]:
On Wed, 2002-11-06 at 15:50, Richard Levitte via RT wrote:
I assume you're talking about the following, which has a
hard-coded
call to gcc.
DETECT_GNU_LD=${CC} -v 21 | grep '^gcc' /dev/null 21 \
14 matches
Mail list logo
