64-bit Int

[own2pwn]

Is there any hack to quickly add support for these? I use swift version and double representation of value is almost precise. Maybe I can cast payload somehow to Swift's Int? I've tried combinations of bit pattern and simple constructor casting but no success. Is it C++ library's engine limitation?

[chadaustin]

Hi @own2pwn. sajson itself does not support 64-bit integers, but it would be possible to add support for it. The reason I haven't is that many (most?) people shy away from putting 64-bit integers in JSON since JavaScript cannot handle them. I ran a little straw poll and it seemed that most people put 64-bit integers in JSON strings instead.

That said, I'm not inherently opposed to adding 64-bit int support to sajson.

What are you trying to encode? Where are the 64-bit integers coming from?

If you are trying to store timestamps, note that the 53 bits provided by Double suffices.

[own2pwn]

I'm mapping an API response which have several fields with big ints in them. And the main problem is that they're mostly greater than 2^53. (415712305605158664 for ex.) Sadly, they're not presented as strings and I can't do anything neither with response format nor API itself.

[chadaustin]

Got it. I can look into adding 64-bit into support to sajson, but I probably won't have time for a bit. If you or someone else wants to take a crack at it, I can provide guidance. :) I think it might require a source-incompatible sajson API change.

On Wed, Oct 18, 2017 at 12:18 PM own2pwn notifications@github.com wrote:

I'm mapping an API response which have several fields with big ints in them. And the main problem is that they're mostly greater than 2^53. ( 415712305605158664 for ex.) Sadly, they're not presented as strings and I can't do anything neither with response format nor API itself.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/chadaustin/sajson/issues/39#issuecomment-337699283, or mute the thread https://github.com/notifications/unsubscribe-auth/AADqU54OL85-qsyDXrZTycIAS2AwYMKFks5stk7mgaJpZM4P90sd .

-- Chad Austin http://chadaustin.me

[chadaustin]

Do you care about 32-bit platforms? 64-bit only would make the change easier.

On Wed, Oct 18, 2017 at 12:20 PM Chad Austin caustin@gmail.com wrote:

Got it. I can look into adding 64-bit into support to sajson, but I probably won't have time for a bit. If you or someone else wants to take a crack at it, I can provide guidance. :) I think it might require a source-incompatible sajson API change.

On Wed, Oct 18, 2017 at 12:18 PM own2pwn notifications@github.com wrote:

I'm mapping an API response which have several fields with big ints in them. And the main problem is that they're mostly greater than 2^53. ( 415712305605158664 for ex.) Sadly, they're not presented as strings and I can't do anything neither with response format nor API itself.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/chadaustin/sajson/issues/39#issuecomment-337699283, or mute the thread https://github.com/notifications/unsubscribe-auth/AADqU54OL85-qsyDXrZTycIAS2AwYMKFks5stk7mgaJpZM4P90sd .

-- Chad Austin http://chadaustin.me

-- Chad Austin http://chadaustin.me

[own2pwn]

Can't we use for now #define style way? E.g. use defines to add breaking changes and pass them while compiling?

No, I don't care about 32-bit platforms.

I haven't seen internal source yet, but if we have almost exact values when using Double/Float64 (loss is around 3 digits) doesn't that mean that we have right bits stored somewhere in memory?

[chadaustin]

Double gives you 53 bits of precision of in the mantissa, but if you need the full 64 bits, it's not good enough. The way sajson encodes its AST has 3 tag bits per value (8 tag values: null, false, true, int, string, double, array, object). We can either:

1. upgrade int to int64 on all platforms (makes 32-bit platforms like Emscripten slower),
2. only upgrade int to int64 on 64-bit platforms,
3. or add a new int64 tag by merging true and false into a general "boolean" tag.

The 3rd option is the one that involves source changes for users of SCons. A #define would be pretty hard to maintain there.

I'm inclined to try the 2nd option since it's easy, though it does make the library a bit more confusing and the caller is responsible for verifying they don't care about 64-bit ints on 32-bit platforms.

[denghongcai]

ping @chadaustin if there is any progress about adding 64bit number support 😁