Closed ghost closed 10 years ago
@BenjaminConlan s
is native endian, we need network byte order (big endian). This works on your OS/CPU but won't on every combination.
So we need to do the same thing we do for some other data types, have two different implementations based on platform's endianness. Feel free to submit a pull request with tests.
Right you are, I'm not actually a ruby developer so don't think I'm the guy for the task of writing something like you suggest, but I'll be sure to forward this issue onto one of our more competent ruby developers whom will hopefully be able to resolve this and write the appropriate unit tests.
I'll just append some notes for implementations sake.
n | Integer | 16-bit unsigned, network (big-endian) byte order
from the aforementioned ruby documentation.
and http://stackoverflow.com/questions/4886994/reading-a-binary-16-bit-signed-big-endian-integer-in-ruby (value & ~(1 << 15)) - (value & (1 << 15))
.
Fixed by #38.
When parsing 16bit signed frames around the AMQ::Pack module incorrectly converts bytes:
specifically:
data.unpack(INT16) // INT16 'c' doesn't unpack the data correctly (only 8 bit) - from the ruby string.unpack docs:
I verified and tested this and replacing the problematic method with
data.unpack('s')
which resolved the issue.