Comment 1:

I have started to work on this issue. It fails on zeros in arrays. Also, there is a 
separate issue with arrays (they could not be encoded directly; only in structs)

Comment 2:

The second issue is known issue and I will not resolve it now. I'm working on fixing 
first.

Comment 3:

The problem is in the encoder. It encodes int array 1 0 1 and 1 1 0 equally.
Here is a chunk for the array 6 78 1 3 2 2 0
6 - number of bytes in the rest of chunk
78 - type
1 - type
3 - array length
2 - 1
2 - 1
0 - end of array
Zeros are just not encoded. Here is 1 0 1 0 1 0 1 chunk:
8 78 1 7 2 2 2 2 0
Actually, decoder just can't guess where zeros are.

Comment 4:

Ok, the problem is obvious but I don't know how to fix it. encode.go states:
func encInt32(i *encInstr, state *encoderState, p unsafe.Pointer) {
    v := int64(*(*int32)(p))
    if v != 0 {
        state.update(i)
        encodeInt(state, v)
    }
}
Similar condition (v != 0) exists for all types. So, we just miss array elements! 
Since this condition was introduced with some (unknown for me) intention, I'd like to  
hear rationale for this from authors of this code.

Comment 5:

My current understanding it was a premature optimization to avoid storing default 
values of struct fields. It's probably a good idea for some cases, but the 
implementation leads to a number of failed tests with arrays.
I have create a quick fix: http://golang.org/cl/183060

Comment 6:

The quick fix is too brutal.

Owner changed to r...@golang.org.

Status changed to Accepted.

Comment 7:

Suggestions?

Comment 8 by soniakeys:

I'm thinking run-length encoding in the value encoding would be nice.  maybe a
positive number could mean that many different values would follow and a negative
number could mean repeat the following value -n times.  0 0 0 0 87 3 2 2 2 could be
encoded as -4 0 2 87 3 -3 2.  I'm no where near ready to propose code for this
though.  I'm still studying the existing code, trying to figure out how it all works.

Comment 9:

I have a fix out for review http://golang.org/cl/181073
It's just a trivial bug: defaults need to be sent for array elements.  The encoding
could be cleverer but I don't think it's necessary.
The code is not easy to follow.  I might rewrite it once the design is shaken down
some more.

Comment 10:

This issue was closed by revision 33311a7.

Status changed to Fixed.

Merged into issue #-.