[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#487803: mldonkey: unaligned data access in CryptoPP.cc



Package: mldonkey
Version: 2.9.5-1+b1
Severity: important
Tags: patch



-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm (armv5tel)

Kernel: Linux 2.6.24-1-iop32x
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Hi all!

There is a bug in the CryptoPP.cc file, at least on ARM and probably
on any arch where data alignement matters.

The RawPokeUInt32 dereferences a void* after a cast to uint32_t*.
This should not be done on ARM (the result won't be what you expect).

My proposed fix is the same as the one used for sparc architecture.

Since almost every arch have performance penality when performing unaligned
access, I think the memcpy could be used on all arch (a recent compiler will
replace the fixed size memcopy by an optimized assembly version).

Best regards

Marc



Patch v1: fix unaligned access for ARM architecture
--- CryptoPP.cc.orig	2008-06-24 09:58:44.000000000 +0200
+++ CryptoPP.cc	2008-06-24 09:59:15.000000000 +0200
@@ -9494,7 +9494,7 @@ inline void PokeUInt8(void* p, uint8_t n
 
 inline void RawPokeUInt32(void* p, uint32_t nVal) 
 {
-#ifndef __sparc__
+#if !defined(__sparc__) && !defined(__arm__)
   *((uint32_t*)p) = nVal;
 #else
   memcpy( p, &nVal, sizeof(uint32_t) );


Patch v2: fix (or improve) unaligned access for almost all architectures
--- CryptoPP.cc.orig	2008-06-24 09:58:44.000000000 +0200
+++ CryptoPP.cc	2008-06-24 10:48:35.000000000 +0200
@@ -9494,11 +9494,7 @@ inline void PokeUInt8(void* p, uint8_t n
 
 inline void RawPokeUInt32(void* p, uint32_t nVal) 
 {
-#ifndef __sparc__
-  *((uint32_t*)p) = nVal;
-#else
   memcpy( p, &nVal, sizeof(uint32_t) );
-#endif
 }
 








Reply to: