Re: Jansson

19 views
Skip to first unread message

Petri Lehtinen

unread,
Dec 9, 2009, 2:18:13 PM12/9/09
to Philip Grandinetti, jansso...@googlegroups.com
Philip Grandinetti wrote:
> Hi Petri,
>
> Wanted to write and thank you and congratulate you for the Jansson library! It took me no time to incorporate it into one of my projects.

Hello, Philip. I'm happy to hear that you like the library :)

> Also, a quick question. Is there a way to encode and decode long unsigned integers? That's the only thing that wasn't so clear in the documentation.

Jansson's json_integer() uses plain int, so there's no direct way to
encode/decode unsigned longs, but you can cast to int. If int's range
is not enough, you can use json_real(), which uses the double type,
and cast to/from unsigned long.

In the future, the integer type could perhaps be modified to use long
instead of int. A bignum implementation could also be used, but this
would probably complicate the library too much.

Petri

PS. I Cc'd this to jansson-users mailing list, as your question may be
interesting to other people as well.

philip.grandinetti

unread,
Dec 9, 2009, 2:27:14 PM12/9/09
to Jansson users
Thanks Petri, that's helpful to know. I guess it could be nice if
json_integer used long instead of plain int, just as json_real uses
double instead of float. Doesn't seem like that would cause
significant changes to the library interface?

Thanks again, Philip

Petri Lehtinen

unread,
Dec 9, 2009, 2:59:57 PM12/9/09
to jansso...@googlegroups.com
philip.grandinetti wrote:
> Thanks Petri, that's helpful to know. I guess it could be nice if
> json_integer used long instead of plain int, just as json_real uses
> double instead of float. Doesn't seem like that would cause
> significant changes to the library interface?

No it wouldn't, but the change would be backwards incompatible. And
backwards incompatible changes are inconvenient for users.

I use the following versioning policy: Version numbers are of the form
X.Y.Z where X is major, Y is minor and Z is bugfix version number. If
Z is 0, it is omitted from the version string.

When Z is incremented, only bugfixes are made, and the API doesn't
change at all. When Y is incremented, there are backwards compatible
changes (something added to the API), and Z is reset to zero. When X
is incremented, there are backwards *incompatible* changes, and Y and
Z are reset to zero. (This numbering is compatible with the libtool
interface versioning, altough not exactly the same.)

So this particular change has to wait until version 2.0. Currently I'm
preparing version 1.2.

The fact that this message got so long tells me that the Jansson
versioning policy and roadmap should be documented somewhere :)

Petri
Reply all
Reply to author
Forward
0 new messages