Is that what happens or is just the rest of the parameter being set to 0?
In the case of a promoted scalar value, it only sets up to the remaining 3 bytes of the promoted type. I.e. If there is more than 3 bytes remaining in the given parameter, then only those 3 bytes are set to zero and everything else is left intact.
How should they be fixed? I'm still assuming that SetRawValue() more or less does what it says i.e. it just sets the value of parameters by mere byte-for-byte copy, without any kind of conversion or fixup. Do we have evidence that's not the case?
According to the current tests, fixups or conversions are performed when: 1. The given parameter is a boolean type. OR 2. The parameter is a numeric type AND the argument IS a single scalar. I.e. bytes == sizeof(DWORD)
That last one is particularly a pain because when the given parameter is a matrix, it _changes_ the meaning / behavior of the byte_offset argument.
As the test I just pushed shows, for matrices byte_offset can only shift the copied values up to 3 times. This is because SetRawValue() will treat byte_offset as an array index keyed on multiples of 4 (sizeof(DWORD)). I.e. Given a byte_offset of 3 with a parameter of int44, SetRawValue() will start writing to the first int (array[0]) but shift all bytes over by 3. A byte_offset of 5 however, will cause SetRawValue() to start writing at the _fifth_ int (array[4]) and shift all bytes over by 1.
I assume that this also applies to booleans, but due to the boolean fixups the remaining byte shift is effectively ignored.
It might make sense to clear them to a non-zero value (e.g. some variation of the usual 0xdeadbeef marker) to make those results more evident.
OK, will do.