FFmpeg
Data Structures | Macros | Functions | Variables
ripemd.c File Reference
#include <string.h>
#include "attributes.h"
#include "avutil.h"
#include "bswap.h"
#include "intreadwrite.h"
#include "ripemd.h"
#include "mem.h"

Go to the source code of this file.

Data Structures

struct  AVRIPEMD
 hash context More...
 

Macros

#define rol(value, bits)   (((value) << (bits)) | ((value) >> (32 - (bits))))
 
#define ROUND128_0_TO_15(a, b, c, d, e, f, g, h)
 
#define ROUND128_16_TO_31(a, b, c, d, e, f, g, h)
 
#define ROUND128_32_TO_47(a, b, c, d, e, f, g, h)
 
#define ROUND128_48_TO_63(a, b, c, d, e, f, g, h)
 
#define R128_0
 
#define R128_16
 
#define R128_32
 
#define R128_48
 
#define ROTATE(x, y)
 
#define ROUND160_0_TO_15(a, b, c, d, e, f, g, h, i, j)
 
#define ROUND160_16_TO_31(a, b, c, d, e, f, g, h, i, j)
 
#define ROUND160_32_TO_47(a, b, c, d, e, f, g, h, i, j)
 
#define ROUND160_48_TO_63(a, b, c, d, e, f, g, h, i, j)
 
#define ROUND160_64_TO_79(a, b, c, d, e, f, g, h, i, j)
 
#define R160_0
 
#define R160_16
 
#define R160_32
 
#define R160_48
 
#define R160_64
 

Functions

struct AVRIPEMDav_ripemd_alloc (void)
 Allocate an AVRIPEMD context. More...
 
static void ripemd128_transform (uint32_t *state, const uint8_t buffer[64])
 
static void ripemd256_transform (uint32_t *state, const uint8_t buffer[64])
 
static void ripemd160_transform (uint32_t *state, const uint8_t buffer[64])
 
static void ripemd320_transform (uint32_t *state, const uint8_t buffer[64])
 
av_cold int av_ripemd_init (AVRIPEMD *ctx, int bits)
 Initialize RIPEMD hashing. More...
 
void av_ripemd_update (AVRIPEMD *ctx, const uint8_t *data, unsigned int len)
 Update hash value. More...
 
void av_ripemd_final (AVRIPEMD *ctx, uint8_t *digest)
 Finish hashing and output digest value. More...
 

Variables

const int av_ripemd_size = sizeof(AVRIPEMD)
 
static const uint32_t KA [4]
 
static const uint32_t KB [4]
 
static const int ROTA [80]
 
static const int ROTB [80]
 
static const int WA [80]
 
static const int WB [80]
 

Macro Definition Documentation

#define rol (   value,
  bits 
)    (((value) << (bits)) | ((value) >> (32 - (bits))))

Definition at line 88 of file ripemd.c.

#define ROUND128_0_TO_15 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h 
)
Value:
a = rol(a + (( b ^ c ^ d) + block[WA[n]]), ROTA[n]); \
e = rol(e + ((((f ^ g) & h) ^ g) + block[WB[n]] + KB[0]), ROTB[n]); \
n++
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
static const uint32_t KB[4]
Definition: ripemd.c:52
The exact code depends on how similar the blocks are and how related they are to the block
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
static const int ROTB[80]
Definition: ripemd.c:64
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:80
int n
Definition: avisynth_c.h:760
static const int WA[80]
Definition: ripemd.c:72
#define rol(value, bits)
Definition: ripemd.c:88
static const int ROTA[80]
Definition: ripemd.c:56

Definition at line 90 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define ROUND128_16_TO_31 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h 
)
Value:
a = rol(a + ((((c ^ d) & b) ^ d) + block[WA[n]] + KA[0]), ROTA[n]); \
e = rol(e + (((~g | f) ^ h) + block[WB[n]] + KB[1]), ROTB[n]); \
n++
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
static const uint32_t KB[4]
Definition: ripemd.c:52
The exact code depends on how similar the blocks are and how related they are to the block
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
static const int ROTB[80]
Definition: ripemd.c:64
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:80
int n
Definition: avisynth_c.h:760
static const int WA[80]
Definition: ripemd.c:72
static const uint32_t KA[4]
Definition: ripemd.c:48
#define rol(value, bits)
Definition: ripemd.c:88
static const int ROTA[80]
Definition: ripemd.c:56

Definition at line 95 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define ROUND128_32_TO_47 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h 
)
Value:
a = rol(a + (((~c | b) ^ d) + block[WA[n]] + KA[1]), ROTA[n]); \
e = rol(e + ((((g ^ h) & f) ^ h) + block[WB[n]] + KB[2]), ROTB[n]); \
n++
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
static const uint32_t KB[4]
Definition: ripemd.c:52
The exact code depends on how similar the blocks are and how related they are to the block
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
static const int ROTB[80]
Definition: ripemd.c:64
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:80
int n
Definition: avisynth_c.h:760
static const int WA[80]
Definition: ripemd.c:72
static const uint32_t KA[4]
Definition: ripemd.c:48
#define rol(value, bits)
Definition: ripemd.c:88
static const int ROTA[80]
Definition: ripemd.c:56

Definition at line 100 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define ROUND128_48_TO_63 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h 
)
Value:
a = rol(a + ((((b ^ c) & d) ^ c) + block[WA[n]] + KA[2]), ROTA[n]); \
e = rol(e + (( f ^ g ^ h) + block[WB[n]]), ROTB[n]); \
n++
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
The exact code depends on how similar the blocks are and how related they are to the block
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
static const int ROTB[80]
Definition: ripemd.c:64
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:80
int n
Definition: avisynth_c.h:760
static const int WA[80]
Definition: ripemd.c:72
static const uint32_t KA[4]
Definition: ripemd.c:48
#define rol(value, bits)
Definition: ripemd.c:88
static const int ROTA[80]
Definition: ripemd.c:56

Definition at line 105 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define R128_0
Value:
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define ROUND128_0_TO_15(a, b, c, d, e, f, g, h)
Definition: ripemd.c:90
#define b
Definition: input.c:41

Definition at line 110 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define R128_16
Value:
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define b
Definition: input.c:41
#define ROUND128_16_TO_31(a, b, c, d, e, f, g, h)
Definition: ripemd.c:95

Definition at line 116 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define R128_32
Value:
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define b
Definition: input.c:41
#define ROUND128_32_TO_47(a, b, c, d, e, f, g, h)
Definition: ripemd.c:100

Definition at line 122 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define R128_48
Value:
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define b
Definition: input.c:41
#define ROUND128_48_TO_63(a, b, c, d, e, f, g, h)
Definition: ripemd.c:105

Definition at line 128 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define ROTATE (   x,
 
)
Value:
x = rol(x, 10); \
y = rol(y, 10); \
n++
int n
Definition: avisynth_c.h:760
#define rol(value, bits)
Definition: ripemd.c:88

Definition at line 251 of file ripemd.c.

#define ROUND160_0_TO_15 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h,
  i,
 
)
Value:
a = rol(a + (( b ^ c ^ d) + block[WA[n]]), ROTA[n]) + e; \
f = rol(f + (((~i | h) ^ g) + block[WB[n]] + KB[0]), ROTB[n]) + j; \
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
static const uint32_t KB[4]
Definition: ripemd.c:52
#define ROTATE(x, y)
Definition: ripemd.c:251
The exact code depends on how similar the blocks are and how related they are to the block
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
static const int ROTB[80]
Definition: ripemd.c:64
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:80
int n
Definition: avisynth_c.h:760
static const int WA[80]
Definition: ripemd.c:72
#define rol(value, bits)
Definition: ripemd.c:88
static const int ROTA[80]
Definition: ripemd.c:56

Definition at line 256 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define ROUND160_16_TO_31 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h,
  i,
 
)
Value:
a = rol(a + ((((c ^ d) & b) ^ d) + block[WA[n]] + KA[0]), ROTA[n]) + e; \
f = rol(f + ((((g ^ h) & i) ^ h) + block[WB[n]] + KB[1]), ROTB[n]) + j; \
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
static const uint32_t KB[4]
Definition: ripemd.c:52
#define ROTATE(x, y)
Definition: ripemd.c:251
The exact code depends on how similar the blocks are and how related they are to the block
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
static const int ROTB[80]
Definition: ripemd.c:64
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:80
int n
Definition: avisynth_c.h:760
static const int WA[80]
Definition: ripemd.c:72
static const uint32_t KA[4]
Definition: ripemd.c:48
#define rol(value, bits)
Definition: ripemd.c:88
static const int ROTA[80]
Definition: ripemd.c:56

Definition at line 261 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define ROUND160_32_TO_47 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h,
  i,
 
)
Value:
a = rol(a + (((~c | b) ^ d) + block[WA[n]] + KA[1]), ROTA[n]) + e; \
f = rol(f + (((~h | g) ^ i) + block[WB[n]] + KB[2]), ROTB[n]) + j; \
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
static const uint32_t KB[4]
Definition: ripemd.c:52
#define ROTATE(x, y)
Definition: ripemd.c:251
The exact code depends on how similar the blocks are and how related they are to the block
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
static const int ROTB[80]
Definition: ripemd.c:64
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:80
int n
Definition: avisynth_c.h:760
static const int WA[80]
Definition: ripemd.c:72
static const uint32_t KA[4]
Definition: ripemd.c:48
#define rol(value, bits)
Definition: ripemd.c:88
static const int ROTA[80]
Definition: ripemd.c:56

Definition at line 266 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define ROUND160_48_TO_63 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h,
  i,
 
)
Value:
a = rol(a + ((((b ^ c) & d) ^ c) + block[WA[n]] + KA[2]), ROTA[n]) + e; \
f = rol(f + ((((h ^ i) & g) ^ i) + block[WB[n]] + KB[3]), ROTB[n]) + j; \
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
static const uint32_t KB[4]
Definition: ripemd.c:52
#define ROTATE(x, y)
Definition: ripemd.c:251
The exact code depends on how similar the blocks are and how related they are to the block
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
static const int ROTB[80]
Definition: ripemd.c:64
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:80
int n
Definition: avisynth_c.h:760
static const int WA[80]
Definition: ripemd.c:72
static const uint32_t KA[4]
Definition: ripemd.c:48
#define rol(value, bits)
Definition: ripemd.c:88
static const int ROTA[80]
Definition: ripemd.c:56

Definition at line 271 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define ROUND160_64_TO_79 (   a,
  b,
  c,
  d,
  e,
  f,
  g,
  h,
  i,
 
)
Value:
a = rol(a + (((~d | c) ^ b) + block[WA[n]] + KA[3]), ROTA[n]) + e; \
f = rol(f + (( g ^ h ^ i) + block[WB[n]]), ROTB[n]) + j; \
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define ROTATE(x, y)
Definition: ripemd.c:251
The exact code depends on how similar the blocks are and how related they are to the block
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
static const int ROTB[80]
Definition: ripemd.c:64
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:80
int n
Definition: avisynth_c.h:760
static const int WA[80]
Definition: ripemd.c:72
static const uint32_t KA[4]
Definition: ripemd.c:48
#define rol(value, bits)
Definition: ripemd.c:88
static const int ROTA[80]
Definition: ripemd.c:56

Definition at line 276 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define R160_0
Value:
ROUND160_0_TO_15(a,b,c,d,e,f,g,h,i,j); \
const char * g
Definition: vf_curves.c:115
#define ROUND160_0_TO_15(a, b, c, d, e, f, g, h, i, j)
Definition: ripemd.c:256
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define b
Definition: input.c:41

Definition at line 281 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define R160_16
Value:
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define b
Definition: input.c:41
#define ROUND160_16_TO_31(a, b, c, d, e, f, g, h, i, j)
Definition: ripemd.c:261

Definition at line 288 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define R160_32
Value:
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define b
Definition: input.c:41
#define ROUND160_32_TO_47(a, b, c, d, e, f, g, h, i, j)
Definition: ripemd.c:266

Definition at line 295 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define R160_48
Value:
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define ROUND160_48_TO_63(a, b, c, d, e, f, g, h, i, j)
Definition: ripemd.c:271
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define b
Definition: input.c:41

Definition at line 302 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define R160_64
Value:
const char * g
Definition: vf_curves.c:115
The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
Definition: undefined.txt:36
#define f(width, name)
Definition: cbs_vp9.c:255
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
Definition: undefined.txt:32
#define i(width, name, range_min, range_max)
Definition: cbs_h2645.c:259
#define ROUND160_64_TO_79(a, b, c, d, e, f, g, h, i, j)
Definition: ripemd.c:276
#define b
Definition: input.c:41

Definition at line 309 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

Function Documentation

static void ripemd128_transform ( uint32_t *  state,
const uint8_t  buffer[64] 
)
static

Definition at line 134 of file ripemd.c.

Referenced by av_ripemd_init().

static void ripemd256_transform ( uint32_t *  state,
const uint8_t  buffer[64] 
)
static

Definition at line 191 of file ripemd.c.

Referenced by av_ripemd_init().

static void ripemd160_transform ( uint32_t *  state,
const uint8_t  buffer[64] 
)
static

Definition at line 316 of file ripemd.c.

Referenced by av_ripemd_init().

static void ripemd320_transform ( uint32_t *  state,
const uint8_t  buffer[64] 
)
static

Definition at line 388 of file ripemd.c.

Referenced by av_ripemd_init().

Variable Documentation

const uint32_t KA[4]
static
Initial value:
= {
0x5a827999, 0x6ed9eba1, 0x8f1bbcdc, 0xa953fd4e
}

Definition at line 48 of file ripemd.c.

const uint32_t KB[4]
static
Initial value:
= {
0x50a28be6, 0x5c4dd124, 0x6d703ef3, 0x7a6d76e9
}

Definition at line 52 of file ripemd.c.

const int ROTA[80]
static
Initial value:
= {
11, 14, 15, 12, 5, 8, 7 , 9, 11, 13, 14, 15, 6, 7, 9, 8,
7 , 6, 8, 13, 11, 9, 7, 15, 7, 12, 15, 9, 11, 7, 13, 12,
11, 13, 6, 7, 14, 9, 13, 15, 14, 8, 13, 6, 5, 12, 7, 5,
11, 12, 14, 15, 14, 15, 9, 8, 9, 14, 5, 6, 8, 6, 5, 12,
9, 15, 5, 11, 6, 8, 13, 12, 5, 12, 13, 14, 11, 8, 5, 6
}

Definition at line 56 of file ripemd.c.

const int ROTB[80]
static
Initial value:
= {
8, 9, 9, 11, 13, 15, 15, 5, 7, 7, 8, 11, 14, 14, 12, 6,
9, 13, 15, 7, 12, 8, 9, 11, 7, 7, 12, 7, 6, 15, 13, 11,
9, 7, 15, 11, 8, 6, 6, 14, 12, 13, 5, 14, 13, 13, 7, 5,
15, 5, 8, 11, 14, 14, 6, 14, 6, 9, 12, 9, 12, 5, 15, 8,
8, 5, 12, 9, 12, 5, 14, 6, 8, 13, 6, 5, 15, 13, 11, 11
}

Definition at line 64 of file ripemd.c.

const int WA[80]
static
Initial value:
= {
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
7, 4, 13, 1, 10, 6, 15, 3, 12, 0, 9, 5, 2, 14, 11, 8,
3, 10, 14, 4, 9, 15, 8, 1, 2, 7, 0, 6, 13, 11, 5, 12,
1, 9, 11, 10, 0, 8, 12, 4, 13, 3, 7, 15, 14, 5, 6, 2,
4, 0, 5, 9, 7, 12, 2, 10, 14, 1, 3, 8, 11, 6, 15, 13
}

Definition at line 72 of file ripemd.c.

const int WB[80]
static
Initial value:
= {
5, 14, 7, 0, 9, 2, 11, 4, 13, 6, 15, 8, 1, 10, 3, 12,
6, 11, 3, 7, 0, 13, 5, 10, 14, 15, 8, 12, 4, 9, 1, 2,
15, 5, 1, 3, 7, 14, 6, 9, 11, 8, 12, 2, 10, 0, 4, 13,
8, 6, 4, 1, 3, 11, 15, 0, 5, 12, 2, 13, 9, 7, 10, 14,
12, 15, 10, 4, 1, 5, 8, 7, 6, 2, 13, 14, 0, 3, 9, 11
}

Definition at line 80 of file ripemd.c.