support for unsigned int types?

[Darren Smith]

Hi,

I notice the JSON number type, for integral values, is mapped to the C type "long" or "long long" , via json_int_t typedef. 

Problem this presents me though is that I would like to write unsigned long / unsigned long long values into a jansson object.  

I'm curious as to why unsigned is not supported? And do you think it would require a substantial modification to the library to support unsigned types natively? (instead of treating them as doubles).

Darren

[Petri Lehtinen]

You can assign an unsigned integer value to a Jansson number, as long
as the unsigned integer is small enough to fit to a signed long or
signed long long. With signed integers, you only lose one bit of
precision compared to their unsigned counterparts.

Jansson's supported value types have been fixed for a long time, and
unless JSON's specification changes, adding support for unsigned
integers seems very unlikely.

Petri

[Darren Smith]

Hi,

Thanks.  Okay, now I understand the motivation.  Yep, JSON protocol does not have an unsigned number type.

The problem I have is that I'm using jansson to communicate between two applications.  The sender has a size_t value (unsigned long long), and wants to send that to the receiver (and the receiver is expected a size_t)   This can be done, but, it has to be squeezed through a double:   size_t --> double  -- jansson -- double --> size_t   

It seems to me that the receiver could, while  it parses a JSON number off the wire,  notice its an unsigned value, and then use a 64 bit unsigned to store it (size permitted).  If its signed, it would use an int. 

Anyway, I think jansson is great.   Appreciate the effort.

[Petri Lehtinen]

Darren Smith wrote:
> Hi,
>
> Thanks. Okay, now I understand the motivation. Yep, JSON protocol does not
> have an unsigned number type.
>
> The problem I have is that I'm using jansson to communicate between two
> applications. The sender has a size_t value (unsigned long long), and wants to
> send that to the receiver (and the receiver is expected a size_t) This can be
> done, but, it has to be squeezed through a double: size_t --> double --
> jansson -- double --> size_t

If you squeeze the 64-bit integer through a double, you only get 53
bits of precision and lose the 11 least signifigant bits. That's less
than when using Jansson's json_int_t (signed long long), where you get
63 bits of precision.

And actually, you get the full 64 bits if you accept the fact that
numbers >= 2^63 are just encoded as negative values in the JSON
representation. When casting to size_t (or unsinged long long), you
get the original positive value back.

Petri

[Darren Smith]

Thanks, good point ... the squeeze through a double won't work.  Neither will squeezing through a signed type, since as you point you, bits will be lost.

The approach of casting won't work either.  How will the receiving application know when to cast?   The receiver cannot assume that every negative number is an unsigned number that is in disguise.  Unless of course there is an additional field which carries a flag indicating  "your int value must be cast to unsigned";  but that's a bit clumsy.  And of course, this is hack is a non-starter once we consider the possibility of communication with other JSON applications which may have native support for 64 bit types and so will not need to use such flags when sending.

I like Jannson library, but I think a path for future enhancement could be to include proper support for 64 bit unsigned int.   The unsigned types are natural part of modern 64 bit systems -- e.g, size_t is very common,  and they are used often, so its a shame they cannot be represented in the current version.  Here's the test case message I think it would be great to handle: 

  [ x:number ]  where x is any of  -9223372036854775808, 9223372036854775807, 18446744073709551615

[Jeff on Gmail]

> On 2015 Jan 24, at 04:18, Darren Smith <darr...@gmail.com> wrote:
>
> I like Jannson library, but I think a path for future enhancement could be to include proper support for 64 bit unsigned int. The unsigned types are natural part of modern 64 bit systems -- e.g, size_t is very common, and they are used often, so its a shame they cannot be represented in the current version. Here's the test case message I think it would be great to handle:
>
> [ x:number ] where x is any of -9223372036854775808, 9223372036854775807, 18446744073709551615
>

Note: Jansson is hardly the only JSON implementation with a 2**64 signed integer limitation. The latest JSON RFC 7159 (http://rfc7159.net/rfc7159) from March 2014 discusses the issue in section 6. I think Jansson would be considered "interoperable". Here's a key paragraph:

> Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values.


I seem to remember a couple years ago there was discussion about Jansson providing "big int" support. That would be cool, but I'd hate to see a dependency on OpenSSL or GNU libmath or similar. Maybe a plug-in capability?

--
Jeff

[Deron Meranda]

Once you get to numbers beyond 53 bits you're getting into the non-portable data range.  Many JSON implementations will start failing, especially JavaScript in which all numbers are floating point.

Regarding "big int" support; many years ago I wrote some experimental patches to jansson for big-number support.  I don't think they ever went anywhere official, but if you are interested in diving into the code itself you can find those on the (retired) "bignum" branch in git:

https://github.com/akheron/jansson/tree/bignum

or from my website where there's more information and documentation:

http://deron.meranda.us/computing/c/jansson-bignum/

It supports four different "bignum" packages of your choosing, but it was based on jansson 2.2, which is quite old now.  Still, it may be useful to somebody.

Deron

--
--
Jansson users mailing list
jansso...@googlegroups.com
http://groups.google.com/group/jansson-users
---
You received this message because you are subscribed to the Google Groups "Jansson users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jansson-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Deron Meranda
http://deron.meranda.us/