Represent big integers as arrays of bytes

[barsnick]

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

• I have performed a self-review of my code
• I have made corresponding changes to the documentation
• I read the contribution documentation and made sure that my changes meet its requirements

[barsnick]

Missing:

• Separate array sizes (and possibly types) for the raw 8-bit representation and the padded 8/7-bit representation
• Documentation of this particular API
• Tests/unit tests

[SebaLukas]

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

[SebaLukas]

libcbv2g with the generated code builds without problems. Unit tests passed and EVerest SIL work as well. So happy to merge this one 👍

[SiebrenW]

If this function is static and you control the inputs, why should it have such a silent error handling of data? It will have gone wrong in exi_basetypes_convert_bytes_from_unsigned before this function is reached.

data_size makes sense of course.

[barsnick]

That's a good point. I was sort of "safe programming".

This code isn't exactly a hot path though.

[SiebrenW]

I get why we want to reverse it, but I rather see it written backwards from the get go to speed it up a bit.

Nice to have. I realise this is technically not easy.

[barsnick]

Yes, EXI internally uses the other direction, from LSB to MSB. I took a "sort of" internal vote on this:

• MSB to LSB seemed more natural to two people (YMMV though).
• OpenV2G also does a byte order reversal.

You mean by "backwards from the get" to fill the array in the opposite order, instead of reversing it after the fact. (Speaking for the decoding direction only here, obviously.)

Let me have a look at that. In the decoder, we grow the result array from the inputs. I don't us gaining much from creating a larger array, filling it from the back, and then shrinking it to size.

From the encoder point of view, you may have a point.

[barsnick]

From the encoder point of view, you may have a point.

I just realized, I already did it directly in the encoder. 😊

[SiebrenW]

Another general question then: do you want to change the generated bigint datatype too? You could just use the uint8_t array, a sign and a size struct instead of using the exi_signed thingy for instance. I initially picked the latter out of ease, but do tell what you think is better.

You can mess with alignment and pack the struct a bit more by decreasing the unneeded bits for the size;

struct {
  uint8_t data[20];
  uint8_t size : 7;
  uint8_t sign : 1; 
} SerialNumber;

I will cost some computational overhead though. Probably not worth it.

[barsnick]

I initially picked the latter out of ease, but do tell what you think is better.

I like your choice. There's not much to be gained by yet another representation, e.g. your struct SerialNumber.

As I mentioned, the internal size (for plenty of 7/8 octets) and the external size should be different anyway.