Re-implement md32_common.h [make it simpler!] and eliminate code rendered

redundant as result.

2 files changed, 1 insertions, 137 deletions

diff --git a/crypto/md4/md4_dgst.c b/crypto/md4/md4_dgst.c
index d4c7057f13..e5b08f3fce 100644
--- a/crypto/md4/md4_dgst.c
+++ b/crypto/md4/md4_dgst.c
@@ -72,89 +72,14 @@ const char *MD4_version="MD4" OPENSSL_VERSION_PTEXT;
 
 int MD4_Init(MD4_CTX *c)
 	{
+	memset (c,0,sizeof(*c));
 	c->A=INIT_DATA_A;
 	c->B=INIT_DATA_B;
 	c->C=INIT_DATA_C;
 	c->D=INIT_DATA_D;
-	c->Nl=0;
-	c->Nh=0;
-	c->num=0;
 	return 1;
 	}
 
-#ifndef md4_block_host_order
-void md4_block_host_order (MD4_CTX *c, const void *data, size_t num)
-	{
-	const MD4_LONG *X=data;
-	register unsigned MD32_REG_T A,B,C,D;
-
-	A=c->A;
-	B=c->B;
-	C=c->C;
-	D=c->D;
-
-	for (;num--;X+=HASH_LBLOCK)
-		{
-	/* Round 0 */
-	R0(A,B,C,D,X[ 0], 3,0);
-	R0(D,A,B,C,X[ 1], 7,0);
-	R0(C,D,A,B,X[ 2],11,0);
-	R0(B,C,D,A,X[ 3],19,0);
-	R0(A,B,C,D,X[ 4], 3,0);
-	R0(D,A,B,C,X[ 5], 7,0);
-	R0(C,D,A,B,X[ 6],11,0);
-	R0(B,C,D,A,X[ 7],19,0);
-	R0(A,B,C,D,X[ 8], 3,0);
-	R0(D,A,B,C,X[ 9], 7,0);
-	R0(C,D,A,B,X[10],11,0);
-	R0(B,C,D,A,X[11],19,0);
-	R0(A,B,C,D,X[12], 3,0);
-	R0(D,A,B,C,X[13], 7,0);
-	R0(C,D,A,B,X[14],11,0);
-	R0(B,C,D,A,X[15],19,0);
-	/* Round 1 */
-	R1(A,B,C,D,X[ 0], 3,0x5A827999L);
-	R1(D,A,B,C,X[ 4], 5,0x5A827999L);
-	R1(C,D,A,B,X[ 8], 9,0x5A827999L);
-	R1(B,C,D,A,X[12],13,0x5A827999L);
-	R1(A,B,C,D,X[ 1], 3,0x5A827999L);
-	R1(D,A,B,C,X[ 5], 5,0x5A827999L);
-	R1(C,D,A,B,X[ 9], 9,0x5A827999L);
-	R1(B,C,D,A,X[13],13,0x5A827999L);
-	R1(A,B,C,D,X[ 2], 3,0x5A827999L);
-	R1(D,A,B,C,X[ 6], 5,0x5A827999L);
-	R1(C,D,A,B,X[10], 9,0x5A827999L);
-	R1(B,C,D,A,X[14],13,0x5A827999L);
-	R1(A,B,C,D,X[ 3], 3,0x5A827999L);
-	R1(D,A,B,C,X[ 7], 5,0x5A827999L);
-	R1(C,D,A,B,X[11], 9,0x5A827999L);
-	R1(B,C,D,A,X[15],13,0x5A827999L);
-	/* Round 2 */
-	R2(A,B,C,D,X[ 0], 3,0x6ED9EBA1);
-	R2(D,A,B,C,X[ 8], 9,0x6ED9EBA1);
-	R2(C,D,A,B,X[ 4],11,0x6ED9EBA1);
-	R2(B,C,D,A,X[12],15,0x6ED9EBA1);
-	R2(A,B,C,D,X[ 2], 3,0x6ED9EBA1);
-	R2(D,A,B,C,X[10], 9,0x6ED9EBA1);
-	R2(C,D,A,B,X[ 6],11,0x6ED9EBA1);
-	R2(B,C,D,A,X[14],15,0x6ED9EBA1);
-	R2(A,B,C,D,X[ 1], 3,0x6ED9EBA1);
-	R2(D,A,B,C,X[ 9], 9,0x6ED9EBA1);
-	R2(C,D,A,B,X[ 5],11,0x6ED9EBA1);
-	R2(B,C,D,A,X[13],15,0x6ED9EBA1);
-	R2(A,B,C,D,X[ 3], 3,0x6ED9EBA1);
-	R2(D,A,B,C,X[11], 9,0x6ED9EBA1);
-	R2(C,D,A,B,X[ 7],11,0x6ED9EBA1);
-	R2(B,C,D,A,X[15],15,0x6ED9EBA1);
-
-	A = c->A += A;
-	B = c->B += B;
-	C = c->C += C;
-	D = c->D += D;
-		}
-	}
-#endif
-
 #ifndef md4_block_data_order
 #ifdef X
 #undef X
@@ -240,19 +165,3 @@ void md4_block_data_order (MD4_CTX *c, const void *data_, size_t num)
 		}
 	}
 #endif
-
-#ifdef undef
-int printit(unsigned long *l)
-	{
-	int i,ii;
-
-	for (i=0; i<2; i++)
-		{
-		for (ii=0; ii<8; ii++)
-			{
-			fprintf(stderr,"%08lx ",l[i*8+ii]);
-			}
-		fprintf(stderr,"\n");
-		}
-	}
-#endif
diff --git a/crypto/md4/md4_locl.h b/crypto/md4/md4_locl.h
index 625b587fde..c8085b0ead 100644
--- a/crypto/md4/md4_locl.h
+++ b/crypto/md4/md4_locl.h
@@ -65,44 +65,13 @@
 #define MD4_LONG_LOG2 2 /* default to 32 bits */
 #endif
 
-void md4_block_host_order (MD4_CTX *c, const void *p,size_t num);
 void md4_block_data_order (MD4_CTX *c, const void *p,size_t num);
 
-#if defined(__i386) || defined(__i386__) || defined(_M_IX86) || defined(__INTEL__) || \
-    defined(__x86_64) || defined(__x86_64__) || defined(_M_AMD64) || defined(_M_X64)
-# if !defined(B_ENDIAN)
-/*
- * *_block_host_order is expected to handle aligned data while
- * *_block_data_order - unaligned. As algorithm and host (x86)
- * are in this case of the same "endianness" these two are
- * otherwise indistinguishable. But normally you don't want to
- * call the same function because unaligned access in places
- * where alignment is expected is usually a "Bad Thing". Indeed,
- * on RISCs you get punished with BUS ERROR signal or *severe*
- * performance degradation. Intel CPUs are in turn perfectly
- * capable of loading unaligned data without such drastic side
- * effect. Yes, they say it's slower than aligned load, but no
- * exception is generated and therefore performance degradation
- * is *incomparable* with RISCs. What we should weight here is
- * costs of unaligned access against costs of aligning data.
- * According to my measurements allowing unaligned access results
- * in ~9% performance improvement on Pentium II operating at
- * 266MHz. I won't be surprised if the difference will be higher
- * on faster systems:-)
- *
- *				<appro@fy.chalmers.se>
- */
-# define md4_block_data_order md4_block_host_order
-# endif
-#endif
-
 #define DATA_ORDER_IS_LITTLE_ENDIAN
 
 #define HASH_LONG		MD4_LONG
-#define HASH_LONG_LOG2		MD4_LONG_LOG2
 #define HASH_CTX		MD4_CTX
 #define HASH_CBLOCK		MD4_CBLOCK
-#define HASH_LBLOCK		MD4_LBLOCK
 #define HASH_UPDATE		MD4_Update
 #define HASH_TRANSFORM		MD4_Transform
 #define HASH_FINAL		MD4_Final
@@ -113,21 +82,7 @@ void md4_block_data_order (MD4_CTX *c, const void *p,size_t num);
 	ll=(c)->C; HOST_l2c(ll,(s));	\
 	ll=(c)->D; HOST_l2c(ll,(s));	\
 	} while (0)
-#define HASH_BLOCK_HOST_ORDER	md4_block_host_order
-#if !defined(L_ENDIAN) || defined(md4_block_data_order)
 #define	HASH_BLOCK_DATA_ORDER	md4_block_data_order
-/*
- * Little-endians (Intel and Alpha) feel better without this.
- * It looks like memcpy does better job than generic
- * md4_block_data_order on copying-n-aligning input data.
- * But frankly speaking I didn't expect such result on Alpha.
- * On the other hand I've got this with egcs-1.0.2 and if
- * program is compiled with another (better?) compiler it
- * might turn out other way around.
- *
- *				<appro@fy.chalmers.se>
- */
-#endif
 
 #include "md32_common.h"