I can't reproduce this outputting a 0x0; my example is below, and
outputs 22-0A-12-08-73-6F-6D-65-43-69-74-79 - the null nested message is
simply completely omitted; the contents are:
- 2 bytes field-header and length-prefix for the "location" member
- 2 bytes field-header and length-prefix for the "city" member
- 8 bytes payload for the text "someCity"
Happy to investigate, but a repro would really help. To clarify: it is
incorrect to emit an 0x0 at the point of a field-header; that is never
valid.
As a random shot-in-the-dark guess, is it possible that you're actually
using a `MemoryStream` with `GetBuffer` but without the `Length`? if so,
there will be trailing garbage (which will default to 0x0) in the buffer,
precisely because `GetBuffer` returns the *oversized* backing buffer. To
get a right-sized array from `MemoryStream`, use `ToArray` instead (but
note that this involves an extra allocation / copy).
Marc
using ProtoBuf;
using System;
using System.IO;
static class Program
{
static void Main()
{
var a = new A {
location = new Location {
city = "someCity",
coordinate = null
}
};
var ms = new MemoryStream();
Serializer.Serialize(ms, a);
var hex = BitConverter.ToString(
ms.GetBuffer(), 0, (int)ms.Length);
Console.WriteLine(hex);
// outputs: 22-0A-12-08-73-6F-6D-65-43-69-74-79
}
}
[ProtoContract]
class A
{
[ProtoMember(2)]
public string someField { get; set; }
[ProtoMember(4)]
public Location location { get; set; }
}
[ProtoContract]
class Location
{
[ProtoMember(1)]
public Coordinate coordinate { get; set; }
[ProtoMember(2)]
public string city { get; set; }
}
[ProtoContract]
class Coordinate
{
//...
}
On 14 October 2014 18:55, Johannes Elgh <johannes.e...@tink.se> wrote:
> Hello everyone,
>
> Firstly I need to apologize for any misuse or misunderstand of terms and
> concepts. I'm mostly familiar with the Protocol Buffer implementations
> protostuff and protobuf-net.
>
>
> I have a case that two different implementations (the C# one: protobuf-net
> and the Java one: protostuff) do differently and I'd like to know which way
> is the correct according to the Protocol Buffers specification.
>
> I have these messages:
>
> message A {
> optional string someField = 2;
> optional Location location = 4;
> }
>
> message Location {
> optional Coordinate coordinate = 1;
> optional string city = 2;
> }
>
> message Coordinate {
> ...
> }
>
>
> In the following case we have an object A, with a populated Location with
> coordinate
> = null and city = "someCity".
>
> When protobuf-net (a client) sends this object A (populated as described
> above) to protostuff (the backend) it sends 0x0 in the place of the
> coordinate.
> This results into that protostuff reads a 0 whilst populating Location,
> and therefore thinks that Location is done. When protostuff then reads
> the next field number it finds 2, city, which has the same number as
> someField in A and populates that field instead (city overwrites someField
> ).
>
> So the problem is that protobuf-net sends 0x0 for a null nested messages
> whereas protostuff doesn't even expect it to be there (since it's null).
>
> Best regards,
> Johannes
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at http://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>
--
Regards,
Marc
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
