Issue 1 in versaplex: Unit test failure in versaplex.test.cs
codesite...@google.com
http://code.google.com/p/versaplex/issues/detail?id=1
Comment #6 by peter.mccurdy:
And the answer to the question above is (d), none of the above. The
Versaplex unit
tests weren't reading the alignment padding bytes that occurred after structure
elements in an array - DBus structs are 8-byte aligned, and a certain structure
element was 260 bytes long. This threw off dbus-sharp for reading the
next element.
The unit tests were already reading some of the alignment padding
(before the first
element in the array), but it needs to be done between each structure
element in an
array. Really, it's not super-great to have to remember to do this
one's self (I
don't think WvDBus has this problem), but at least it's manageable.
This was fixed
in r260.
However, when this is fixed, dbus-sharp later chokes on some long
packets, so we're
not done quite yet. At least I've enabled the first few tests, so
we're making progress.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
codesite...@google.com
codesite...@google.com
http://code.google.com/p/versaplex/issues/detail?id=1
Comment #7 by peter.mccurdy:
And dbus-sharp is indeed a pile of junk. It was calling
Stream.Read(large array),
and not looping if the stream returned less than the requested number
of bytes right
away. Fixed in r264.
Also, there were a few last lingering problems with the unit tests
themselves. For
some reason, a test started failing due to the padding call I moved in
r260. I don't
know why it was passing for me before, but anyway, the DBus message
header is indeed
supposed to be 8-byte aligned, so I guess we still need that call in
its old location
(in addition to making sure we deal with the padding around structure
members). And
finally, calling LEN() or DATALENGTH() in MSSQL returns either an int
or a bigint,
depending on the column type. So when reading the result of those
functions, we
might get a Decimal instead of an int from Versaplex. Both these were
fixed in r265.
Issue attribute updates:
Status: Fixed
codesite...@google.com
codesite...@google.com
http://code.google.com/p/versaplex/issues/detail?id=1
Comment #8 by apenwarr:
I don't think we should be treating a bigint as Decimal, should we?
Issue attribute updates:
Status: Started