Fix alignment on Win32 and Solaris Sparc (PR #709)

These fixes were interesting in a morbid sort of way. I thought the FixedSizeAllocatorWithCleanup specializations faithfully reproduced semantics but I was wrong on Win32 and Sparc. Also see Commit e054d36dc88d.

It seems there was another requirement or dependency that we missed, but it was not readily apparent. If I am parsing results correctly (which I may not be), it appears the bit twiddling using 8 byte alignment had more influence on alignment than I originally thought based on use of CRYPTOPP_BOOL_ALIGN16 and T_Align16. Or maybe the alignment attributes specified by CRYPTOPP_ALIGN_DATA are not being honored like they should for stack allocations.

This check-in avoids some uses of x86 movdqa (aligned) in favor of movdqu (unaligned). The uses were concentrated on memory operands which were 8-byte aligned instead of 16-byte aligned. It is not clear to me how the specializations lost 8-bytes of alignment. The check-in also enlists CRYPTOPP_ASSERT to tell us when there's a problem so we don't need to go hunting for bugs.

1 files changed, 2 insertions, 2 deletions

diff --git a/iterhash.h b/iterhash.h
index edaa18e2..f642ab47 100644
--- a/iterhash.h
+++ b/iterhash.h
@@ -152,8 +152,8 @@ public:
 	{

 		CRYPTOPP_ASSERT(in != NULLPTR);

 		CRYPTOPP_ASSERT(out != NULLPTR);

-		CRYPTOPP_ASSERT(IsAligned<T_HashWordType>(in));

-		CRYPTOPP_ASSERT(IsAligned<T_HashWordType>(out));

+		CRYPTOPP_ASSERT(IsAligned<T_HashWordType*>(in));

+		CRYPTOPP_ASSERT(IsAligned<T_HashWordType*>(out));

 

 		ConditionalByteReverse(T_Endianness::ToEnum(), out, in, byteCount);

 	}