-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Represent big integers as arrays of bytes #87
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Moritz Barsnick <[email protected]>
Signed-off-by: Moritz Barsnick <[email protected]>
…tet array Signed-off-by: Moritz Barsnick <[email protected]>
…tet array Signed-off-by: Moritz Barsnick <[email protected]>
For code readability. Signed-off-by: Moritz Barsnick <[email protected]>
When adding the final byte or octet, skip it when its value is zero. Trailing 0-octets are meaningless in both cases and shouldn't be provided. Signed-off-by: Moritz Barsnick <[email protected]>
Found by review, confirmed by cppcheck. Also reorder the code lines to a more logical order. Signed-off-by: Moritz Barsnick <[email protected]>
Signed-off-by: Moritz Barsnick <[email protected]>
Signed-off-by: Moritz Barsnick <[email protected]>
Missing:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Maybe I have found one small thing.
But I have not yet generated the code and tested it against the libcbv2g unit tests
} | ||
if (dummy_count > 0) { | ||
*(current_octet-1) |= EXI_BASETYPES_OCTET_SEQ_FLAG_MASK; | ||
if (dummy_count > 0 && dummy != 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is dummy != 0
here necessary?
It's relevant, I just read dummy_count
twice...
libcbv2g with the generated code builds without problems. Unit tests passed and EVerest SIL work as well. So happy to merge this one 👍 |
Describe your changes
In PR #65, support for proper coding of large integer (xs:integer) was added, aiding in the proper handling of X509SerialNumber.
Yet the API presented those numbers in the same style as EXI internally, i.e. with 8/7 padding, adding an indicator MSB to each octet for understanding whether the sequence continues.
This change now expects those numbers as arrays of bytes (still within an
exi_unsigned_t
), representing the integer, without any padding. The byte order is big-endian, i.e. leading bytes in the array have the most significant meaning.Issue ticket number and link
Relates to issue #54
Amends PR #65
Checklist before requesting a review