I extracted a TransactionEnvelope XDR several months ago for testing. It parses fine in the lab and the SDKs.
I've tried parsing it by hand and there's something I don't understand. After the MemoText is finished, the next item should be an int (4 bytes) count of operations. The next 4 bytes are
0, 0, 0, 0, indicating that there's zero operations. But there is actually 1 operation. As the fifth byte is
1, and the bytes that follow it decode to that single operation, it seems that there's an extra
0 byte between the Memo and the operation count.
It's not a string terminator, because the en/decoding of strings clearly uses 4 bytes to count the number of bytes in the string, followed by that quantity of bytes and no trailing bytes.
The extra weird bit is when I debug the Java SDK's parsing of this, I can see the extra
0 in the buffer, but when it comes to parse the operation count, this extra byte is "magically" skipped. I can't find the code that is reading it.
Here's the Java SDK parsing code that I used for debugging:
And this is my console output where I'm parsing the data manually, 1 field at a time:
@ s.drop(60).take(23) res128: Array[Byte] = Array(72, 105, 32, 90, 121, 44, 32, 104, 101, 114, 101, 115, 32, 97, 110, 32, 97, 110, 103, 112, 97, 111, 33) @ new String(res128) res129: String = "Hi Zy, heres an angpao!" @ s.drop(83).take(5) res130: Array[Byte] = Array(0, 0, 0, 0, 1)
You can see that after the String of the Memo is parsed, the subsequent bytes are
0,0,0,0,1 and not
0,0,0,1 as expected.
My question can be framed in a number of different ways, but the underlying question is the same. Why does this XDR parse OK when it has this extra
0? Why is there an extra
0 when the encoder doesn't write one? Why does the decoder ignore the extra