Bit Length Calculations are slightly off
premkumar-masilamani opened this issue · 7 comments
Hi team - We were using the commit 74163b455f070f8fd925955bb33911bfcd83a092 which was a few weeks old. Recently upgraded to the latest version at 3b33829178dc854e8a578ff66be7459137017391
I noticed that the bit length calculation on the request parameter is off by 3 bits (27 bits). It was 32 bits with the previous commit. However, it does show properly on the pictorial representation & the actual values in the dops, but the cumulative value in the structure seems to be off.
Unfortunately, I am not in a position to share the PDX file. I know there is not enough to debug, with just a screenshot. :(
Please let me know if you have pointers on what could have caused this. I'll update the ticket if I find something.
The highlighted lines cause a mismatch in the bit_length.
If I comment those two lines, I get the desired bit_length as 32 bits (4 bytes).
I am not able to understand the usage of byte_position in calculating the bit_length (probably I am missing some understanding). Could you please explain?. If this was not intended, I could revert in my MR. Please advise.
structs always have a length multiple of 8 according to odx standard.
if the parameters of the struct end before we get a multiple of 8 length, that means we need to add padding bits.
basically you can not send just 27bits of uds data, you send 4 bytes, thus the length of the struct is 32bits and not just 27bits
structs always have a length multiple of 8 according to odx standard.
if the parameters of the struct end before we get a multiple of 8 length, that means we need to add padding bits.
basically you can not send just 27bits of uds data, you send 4 bytes, thus the length of the struct is 32bits and not just 27bits
Thanks @kayoub5. That's what I was expecting too. But after the recent code change, I see the bit_length as 27 instead of 32.
I'm not sure if removing this is good idea: @kayoub5 introduced this code to determine the size of structures which do not declare one explicitly. He probably had a good motivation for doing so. I guess that rounding the size up to the next multiple of 8 is the way to go. (right?)
I'm not sure if removing this is good idea: @kayoub5 introduced this code to determine the size of structures which do not declare one explicitly. He probably had a good motivation for doing so. I guess that rounding the size up to the next multiple of 8 is the way to go. (right?)
yes, the serialization logic does that already.
Hi @kayoub5 - The latest commit from main branch fixed (cdb078019e41c84f4763d15d44166635b86259e4) the issues we observed with the earlier version. Thanks for fixing the errors. I'll close this ticket.