JSON Marshalling of Pointers

2,901 views
Skip to first unread message

Carlisle Perera

unread,
Jan 3, 2010, 11:30:19 AM1/3/10
to golan...@googlegroups.com
Is there a reason why json.Marshall does not marshall pointer values? I have added a json.writePtr function to the package and it works well enough for me. Is this an oversight or are there deeper issues involved?

Cheers,
C.P.

P.S. I think json.writeStruct should not ignore the return value of json.writeValue.


struct.go.diff

Carlisle Perera

unread,
Jan 5, 2010, 10:29:27 AM1/5/10
to golang-nuts
On Jan 3, 5:30 pm, Carlisle Perera <carlisle.per...@googlemail.com>
wrote:

cperera@localhost ~/go/src/pkg/json $ hg log -l 1 .
changeset: 4519:73da0cb12dc6
user: Rob Pike <r...@golang.org>
date: Tue Jan 05 11:33:06 2010 +1100
summary: Check for errors when writing fields of a struct.

Nice. If I would now also receive an answer to my main question I
would be more than happy ;)

Jake

unread,
Jan 5, 2010, 10:28:44 PM1/5/10
to golang-nuts
On Jan 5, 7:29 am, Carlisle Perera <carlisle.per...@googlemail.com>
wrote:

Deserializing pointers is an excellent way to corrupt memory and cause
segfaults. Maybe even the best. Without deserialization,
serialization is not very useful.

(why do you need to serialize something? so you can send it to
another process. what will the pointer point to in that process? god
only knows.)

-jake

Carlisle Perera

unread,
Jan 6, 2010, 7:39:25 AM1/6/10
to golang-nuts
On Jan 6, 4:28 am, Jake <jaekmcgu...@gmail.com> wrote:
> Deserializing pointers is an excellent way to corrupt memory and cause
> segfaults.  Maybe even the best.  Without deserialization,
> serialization is not very useful.
>
> (why do you need to serialize something?  so you can send it to
> another process.  what will the pointer point to in that process?  god
> only knows.)

Sorry for not being clear enough, but I didn't meant to serialize the
pointer itself, but what it points to. If you look into the patch I
have attached to my original posting, you will find, that it writes
either "null" for nil pointers or it dereferences the pointer and
writes the resulting value.

Cheers,
C.P.

Carlisle Perera

unread,
Jan 6, 2010, 8:47:51 AM1/6/10
to golang-nuts
I have submitted Issue 499 regarding this: http://code.google.com/p/go/issues/detail?id=499

Ostsol

unread,
Jan 6, 2010, 10:24:34 PM1/6/10
to golang-nuts
Take the following example:

type A struct {
b *B
}

type B struct {
a *A
}

Now create an instance of A, 'obj', that points to a B, which points
back to the original A -- circular references. How is json supposed
to know that obj.b.a simply points to obj? The result is an infinite
recursive loop.

Now this could be avoided if the implementation also gave each object
a unique id, but I lack sufficient knowledge of the json spec and the
potential security issues to comment further along that thought.

-Ostsol

On Jan 6, 5:39 am, Carlisle Perera <carlisle.per...@googlemail.com>
wrote:

Russ Cox

unread,
Jan 7, 2010, 12:10:21 AM1/7/10
to Ostsol, golang-nuts
On Wed, Jan 6, 2010 at 19:24, Ostsol <ost...@gmail.com> wrote:
> Take the following example:
>
> type A struct {
>    b *B
> }
>
> type B struct {
>    a *A
> }
>
> Now create an instance of A, 'obj', that points to a B, which points
> back to the original A -- circular references.  How is json supposed
> to know that obj.b.a simply points to obj?

Json can't know, because it only describes trees. One could
introduce a map to keep track of all the written pointers and
return an error when the same node is encountered multiple times
during the process, but I think that's overkill.

> The result is an infinite recursive loop.

Same problem:

func f() { f() }

Same solution: don't do that. ;-)

Russ

Reply all
Reply to author
Forward
0 new messages