FFmpeg
Data Structures | Macros | Functions | Variables
ripemd.c File Reference
#include <stddef.h>
#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 89 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:117
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:53
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:65
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:81
static const int WA[80]
Definition: ripemd.c:73
#define rol(value, bits)
Definition: ripemd.c:89
static const int ROTA[80]
Definition: ripemd.c:57

Definition at line 91 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:117
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:53
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:65
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:81
static const int WA[80]
Definition: ripemd.c:73
static const uint32_t KA[4]
Definition: ripemd.c:49
#define rol(value, bits)
Definition: ripemd.c:89
static const int ROTA[80]
Definition: ripemd.c:57

Definition at line 96 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:117
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:53
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:65
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:81
static const int WA[80]
Definition: ripemd.c:73
static const uint32_t KA[4]
Definition: ripemd.c:49
#define rol(value, bits)
Definition: ripemd.c:89
static const int ROTA[80]
Definition: ripemd.c:57

Definition at line 101 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:117
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:65
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:81
static const int WA[80]
Definition: ripemd.c:73
static const uint32_t KA[4]
Definition: ripemd.c:49
#define rol(value, bits)
Definition: ripemd.c:89
static const int ROTA[80]
Definition: ripemd.c:57

Definition at line 106 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define R128_0
Value:
const char * g
Definition: vf_curves.c:117
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:91
#define b
Definition: input.c:41

Definition at line 111 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define R128_16
Value:
const char * g
Definition: vf_curves.c:117
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:96

Definition at line 117 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define R128_32
Value:
const char * g
Definition: vf_curves.c:117
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:101

Definition at line 123 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define R128_48
Value:
const char * g
Definition: vf_curves.c:117
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:106

Definition at line 129 of file ripemd.c.

Referenced by ripemd128_transform(), and ripemd256_transform().

#define ROTATE (   x,
 
)
Value:
x = rol(x, 10); \
y = rol(y, 10); \
n++
#define rol(value, bits)
Definition: ripemd.c:89

Definition at line 252 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:117
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:53
#define ROTATE(x, y)
Definition: ripemd.c:252
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:65
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:81
static const int WA[80]
Definition: ripemd.c:73
#define rol(value, bits)
Definition: ripemd.c:89
static const int ROTA[80]
Definition: ripemd.c:57
int i
Definition: input.c:407

Definition at line 257 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:117
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:53
#define ROTATE(x, y)
Definition: ripemd.c:252
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:65
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:81
static const int WA[80]
Definition: ripemd.c:73
static const uint32_t KA[4]
Definition: ripemd.c:49
#define rol(value, bits)
Definition: ripemd.c:89
static const int ROTA[80]
Definition: ripemd.c:57
int i
Definition: input.c:407

Definition at line 262 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:117
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:53
#define ROTATE(x, y)
Definition: ripemd.c:252
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:65
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:81
static const int WA[80]
Definition: ripemd.c:73
static const uint32_t KA[4]
Definition: ripemd.c:49
#define rol(value, bits)
Definition: ripemd.c:89
static const int ROTA[80]
Definition: ripemd.c:57
int i
Definition: input.c:407

Definition at line 267 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:117
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:53
#define ROTATE(x, y)
Definition: ripemd.c:252
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:65
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:81
static const int WA[80]
Definition: ripemd.c:73
static const uint32_t KA[4]
Definition: ripemd.c:49
#define rol(value, bits)
Definition: ripemd.c:89
static const int ROTA[80]
Definition: ripemd.c:57
int i
Definition: input.c:407

Definition at line 272 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:117
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:252
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:65
#define b
Definition: input.c:41
static const int WB[80]
Definition: ripemd.c:81
static const int WA[80]
Definition: ripemd.c:73
static const uint32_t KA[4]
Definition: ripemd.c:49
#define rol(value, bits)
Definition: ripemd.c:89
static const int ROTA[80]
Definition: ripemd.c:57
int i
Definition: input.c:407

Definition at line 277 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define R160_0
Value:
const char * g
Definition: vf_curves.c:117
#define ROUND160_0_TO_15(a, b, c, d, e, f, g, h, i, j)
Definition: ripemd.c:257
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
int i
Definition: input.c:407

Definition at line 282 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define R160_16
Value:
const char * g
Definition: vf_curves.c:117
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 ROUND160_16_TO_31(a, b, c, d, e, f, g, h, i, j)
Definition: ripemd.c:262
int i
Definition: input.c:407

Definition at line 289 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define R160_32
Value:
const char * g
Definition: vf_curves.c:117
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 ROUND160_32_TO_47(a, b, c, d, e, f, g, h, i, j)
Definition: ripemd.c:267
int i
Definition: input.c:407

Definition at line 296 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define R160_48
Value:
const char * g
Definition: vf_curves.c:117
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:272
#define b
Definition: input.c:41
int i
Definition: input.c:407

Definition at line 303 of file ripemd.c.

Referenced by ripemd160_transform(), and ripemd320_transform().

#define R160_64
Value:
const char * g
Definition: vf_curves.c:117
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_64_TO_79(a, b, c, d, e, f, g, h, i, j)
Definition: ripemd.c:277
#define b
Definition: input.c:41
int i
Definition: input.c:407

Definition at line 310 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 135 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 192 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 317 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 389 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 49 of file ripemd.c.

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

Definition at line 53 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 57 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 65 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 73 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 81 of file ripemd.c.