I believe that the serialized bytes should not depend on the CPU
architecture that ran the program.
UnicodeEncoding (which means UTF-16) has endianness information (i.e.
UTF-16LE vs. UTF-16BE) which is specified at constructor or
Unicode/BigEndianUnicode differencein Encoding static properties.
So probably those classes generates bytes in some unexpected order?
Though some of those crypto stuff is regressing (regardless of CPU arch)
in recent referencesource porting, so that problem might just be temporary.
Atsushi Eno
On 2015年04月29日 03:40, Neale Ferguson wrote:
The following test fails on s390x as the string that is encoded from the
decrypted block ends is in little endian order:
public void FullRoundtripRead ()
{
byte[] encrypted;
using (DebugStream mem1 = new DebugStream ()) {
byte[] toEncrypt =
Encoding.Unicode.GetBytes ("Please encode me!");
using (CryptoStream crypt = new
CryptoStream (mem1, aes.CreateEncryptor (), CryptoStreamMode.Write)) {
crypt.Write (toEncrypt, 0,
toEncrypt.Length);
crypt.FlushFinalBlock ();
}
encrypted = mem1.ToArray ();
}
using (DebugStream mem2 = new DebugStream
(encrypted)) {
byte[] buffer = new byte [1024];
CryptoStream cr = new CryptoStream (mem2,
aes.CreateDecryptor (), CryptoStreamMode.Read);
int len = cr.Read (buffer, 0,
buffer.Length);
cr.Close ();
Assert.AreEqual (34, len, "Full Length
Read");
Assert.AreEqual ("Please encode me!",
Encoding.Unicode.GetString (buffer, 0, len), "Full Block Read");
}
}
The question is at what point should byte swapping be performed? Should
all Encoding.Unicode.GetBytes(string) do the swap to little ending and
Encoding.Unicode.GetString(bytes) do the reverse?
Neale
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
