[FFmpeg-devel] [PATCH] md5: consistently use uint32_t instead of unsigned int

[Giorgio Vazzana]

2012/6/15 Michael Niedermayer <michaelni at gmx.at>:
> On Fri, Jun 15, 2012 at 06:03:12PM +0200, Giorgio Vazzana wrote:
>> As in subject, 'make fate' passes, please review.
> [...]
>>  md5.c |   10 +++++-----
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>> 8cb92a43c030e7c1e82de36b8e7e6ded7b42bf4d  0001-md5-consistently-use-uint32_t-instead-of-unsigned-in.patch
>> From 48bb8ff622713ede5b978fce6cf81c39d8a2131d Mon Sep 17 00:00:00 2001
>> From: Giorgio Vazzana <mywing81 at gmail.com>
>> Date: Fri, 15 Jun 2012 17:21:36 +0200
>> Subject: [PATCH] md5: consistently use uint32_t instead of unsigned int
>
> can you explain why you change unsigned int to uint32_t, is this
> fixing a bug or some warnings or ?

Yes, sorry. Basically to make code clearer and adherent to the
standard. RFC 1321, on page 2 states

Let the symbol "+" denote addition of words (i.e., modulo-2^32
addition). Let X <<< s denote the 32-bit value obtained by circularly
shifting (rotating) X left by s bit positions.

on page 3, section 3.3 states:

A four-word buffer (A,B,C,D) is used to compute the message digest.
Here each of A, B, C, D is a 32-bit register.

so the algorithm needs to work with integers that are exactly 32bits
in length. And indeed in struct AVMD5 the MD buffer is declared as
"uint32_t ABCD[4];", while in the function that performs the block
transformation the state variables were "unsigned int"s. On
architectures where sizeof(unsigned int) != sizeof(uint32_t) this
could be a problem, although I can't name such an architecture from
the top of my head.
On a side note, both the reference implementation in RFC 1321 and the
gnulib implementation (used by md5sum program on GNU systems) use
uint32_t in the transform function.

Giorgio Vazzana