What do these casts accomplish?

[Steven T. Hatton]

I am looking at the C++ MD5 implementation found on this site:
http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html. I'm a bit unsure as to
the necessity and/or effect of the various casts appearing in the
following:

typedef unsigned int uint4;
uint4 count[2]; // number of *bits*, mod 2^64

void MD5::update (uint1 *input, uint4 input_length) {

uint4 input_index, buffer_index;
uint4 buffer_space; // how much space is left in buffer
/...

// Compute number of bytes mod 64
buffer_index = (unsigned int)((count[0]>>3) & 0x3F);

// Update number of bits
if ((count[0]+=((uint4)input_length<<3)) < ((uint4)input_length<<3))
count[1]++;

count[1] += ((uint4)input_length >> 29);

//etc...
}

Firstly, I'm wondering if there could be any functional advantage to not
using the typedef in the first cast.

buffer_index = (unsigned int)((count[0]>>3) & 0x3F);

My guess is the programmer simply overlooked it when converting from using
builtin names to using the typedef.

More significantly, I'm unsure of what those typedefs might accomplish, or
the consequences -if any- of omitting them. Does anybody see functional
value in having them in the code? What might that be?

 

[loufoque]

Steven T. Hatton a écrit :

Does anybody see functional
value in having them in the code?

I don't see any.

 

[Dave (from the UK)]

I am looking at the C++ MD5 implementation found on this site:
http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html. I'm a bit unsure as to
the necessity and/or effect of the various casts appearing in the
following:

typedef unsigned int uint4;
uint4 count[2]; // number of *bits*, mod 2^64

void MD5::update (uint1 *input, uint4 input_length) {

uint4 input_index, buffer_index;
uint4 buffer_space; // how much space is left in buffer
/...

// Compute number of bytes mod 64
buffer_index = (unsigned int)((count[0]>>3) & 0x3F);

Pointless as far as I can see, since both are unsigned ints.

Firstly, I'm wondering if there could be any functional advantage to not
using the typedef in the first cast.

buffer_index = (unsigned int)((count[0]>>3) & 0x3F);

My guess is the programmer simply overlooked it when converting from using
builtin names to using the typedef.

More significantly, I'm unsure of what those typedefs might accomplish, or
the consequences -if any- of omitting them. Does anybody see functional
value in having them in the code? What might that be?

I think the reason people do it to 'future proof' code. He is saying
that 'int' is 4 bytes. This is not so on all processors. The Cray X-MP has

sizeof(short)=8;
sizeof(int)=8
sizeof(long)=8.

I've always felt 'short', int and long were silly names, and something
like int8, int16, int32, int64 would have been more logical from the
beginning. But hay, that breaks too, as I have used a processor which
had 24 bits!! The most (or it might have been the least) significant
byte was in the middle, so it was never big or little Endian.

--
Dave K

Minefield Consultant and Solitaire Expert (MCSE).

Please note my email address changes periodically to avoid spam.
It is always of the form: month-year@domain. Hitting reply will work
for a couple of months only. Later set it manually.