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.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Other parts of FFmpeg use NE (native endian) rather than ME (machine).
This makes it consistent.
Originally committed as revision 24169 to svn://svn.ffmpeg.org/ffmpeg/trunk
This reduces the number of false dependencies on header files and
speeds up compilation.
Originally committed as revision 22407 to svn://svn.ffmpeg.org/ffmpeg/trunk
md5.c:150: warning: passing argument 2 of 'av_md5_update' from incompatible pointer type
Originally committed as revision 11665 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Carl Eugen Hoyos cehoyos chez ag or at
original thread: [FFmpeg-devel] [PATCH] attribute_unused -> av_unused
date: 05/29/2007 01:23 PM
Originally committed as revision 9155 to svn://svn.ffmpeg.org/ffmpeg/trunk
depending on CONFIG_SMALL this can either be compiled to a fully unrolled kernel / rfc reference style md5 routine
or a single loop similar to what mplayer uses
Originally committed as revision 5565 to svn://svn.ffmpeg.org/ffmpeg/trunk