Need 128bit unsigned. (supported by GCC)

[cfrademan]

Greetings,

Is there a plan to support uint128_t? GCC has native 128bit unsigned integer support via __int128. I can try add it, but will need it to be upstreamed for good reasons. My use case is NETFLOW 9+ protocol can send 16byte length values in fields which I need to process into JSON. An example is IPV6 Address which needs stay in numeric form.

Thank you in advance.

[baylesj]

I don't think we have any current plans for uint128_t, but would happily take a patch if it updated config.h's LargestInt/LargestUint types appropriately.

I'm also curious if you could massage the data coming from NETFLOW 9+ into an array of uint32_ts, or uint8_ts.

[cfrademan]

Thanks baylesj, if time permits, I will attend to this but it isn't urgent at this point. The IPv6 Address which is a 128bit unsigned integer for example is converted to string format now as solution. However all our API(s) are developed in Python3 which supports uint128_t sized numbers with JSON serialisation natively. Counters etc are my biggest concern. Yes you can easily split the 16 bytes of data up from netflow, the trick is how to present it as a integer value in JSON using jsoncpp. I am not a fan of hacks, I am sure you will agree, since if we can encode 128bit values, we should be able to decode it as-well. Id rather have jsoncpp check if uint128_t is available, and if not use uint64_t for largest for example. However for people that already use jsoncpp, wont be expecting a sudden change of largest being 128bit when supported by compiler. This is a change in interface. Yet largest does say it all, the native __int128 in gcc if detected when used does not work with other std::libs yet and interfaces such as std::cout breaks... unsigned 128bit numbers is newish, but also needed with to present IPV6 addresses in integer form. Also counters in networks heavily depend on 64bit so far, however protocols allow the vendors to specify a new length. Yet I have not seen a 128bit counter, but if one does, I wont be able translate the data from packet format to JSON. One option would be to format that bit of json myself as a quick fix.

I think if JSONCPP has to introduce the 128bit integer type, it should not default for the largest as of current. Whats are your thoughts?

[baylesj]

I definitely agree that if we roll out 128-bit support, it should be behind a flag until we determine the impact of 128-bit default on compilers that support it. Clients shouldn't assume our defines, like LargestInt, are going to stay the same forever and are tied to a specific value, but I'm sure that some of them likely do.