On 14.04.2010, at 15:35, Stephen Henson via RT wrote: >> [[email protected] - Wed Apr 14 12:08:30 2010]: >> >> In my opinion the patch is also not necessary, because >> dtls1_buffer_message() requires a pointer to some 64 bit data to be >> used as the priority for the queue. However, s->s3->rrec.seq_num >> already is a pointer, since it is an array. Using &(s->s3- >>> rrec.seq_num) usually returns the same value, i.e. the pointer to >> the first value of the array, but I'm not sure if that's always the >> case. >> > > Err it is of type PQ_64BIT in 0.9.8 and not an array.
Yes, but the dtls1_buffer_message() function uses a PQ_64BIT pointer to pass a PQ_64BIT struct, which is accessed directly. However, passed is just the pointer to the array which holds the sequence number. This is not very elegant but seems to work. The patch recently submitted only changed s->s3->rrec.seq_num to &(s->s3->rrec.seq_num) when passing it to the buffering function. Since seq_num is an array and therefore interpreted as a pointer to the first element this was ok. It was simply used as if it were a pointer to an PQ_64BIT struct. Changing it to &(s->s3->rrec.seq_num) only results in passing the very same pointer to the buffering function. This is because the compiler also interprets this as a pointer to the first element of the array. However, I don't know if this is the case with every compiler because we didn't find this construct in the C specification, i.e. referencing an array pointer. I expected it to be the pointer to the pointer to the first element of the a rray, which it is not for some reason. So I still recommend not to change it and revert the patch for 0.9.8 as well to be sure it keeps working or change it to create a real PQ_64BIT struct which is then passed to the buffering function. Regards, Robin ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
