Bodo Moeller wrote:
>
> I have prepared a set of patches to the DES library that should solve
> the const problem. Also I have, in those places where the functions
> have arguments of type des_cblock (which really is char * as
> des_cblock is a typedef for char [8]), converted back to des_cblock *,
> which is what SSLeay used there. This makes those arguments pointers
> to an array with 8 elements of type char. These pointers will
> typically have the same representation as pointers to the first
> element, but they are something quite different as far as C types are
> concerned; and they allow the compiler to check things more thoroughly:
>
> typedef unsigned char des_cblock[8];
> typedef const unsigned char const_des_cblock[8];
> int des_set_key(const_des_cblock *key,des_key_schedule schedule);
>
> unsigned char key[7] = {...};
> unsigned char deskey[8] = {...};
> des_key_schedule ks;
>
> des_set_key(&key, ks); /* gets a warning */
> des_set_key(&deskey, ks); /* no warning */
I really don't like this. I can't quite figure out why, but it seems
messy. What happens if you use the two definitions for des_cblock and
const_des_cblock, but don't introduce the *s?
Actually, I can figure out why. &key doesn't mean anything sensible: you
can't have a pointer to key, because it is already as pointery as it can
be.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
