Thanks for the reply. Option 1 seems pretty reasonable for me. I would
probably go as far as to frame the messages with magic + message size, that
way I can verify that when there's another magic (or end of file) at
current position + message size It's probably correct.
On Friday, April 14,
Hi Stepan,
No, there's no easy way to detect the corruption your describe. In fact,
for most serialization formats, there's no solution to this problem. Once
you've lost track of message boundaries, it's impossible to tell the
difference between the start of a new message vs. data in the previous
I have a message that serializes into 24 bytes. I write two messages to a
file resulting in a file thats 48 bytes long. Now I truncate the file to 40
bytes and write one message, so the file now looks like this: 1 full
message, one broken, 1 full message. Is there any way to iterate over the
Oh it's on the dev branch of github.com/sjmackenzie/sputnikvm
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to capnproto+unsubscr...@googlegroups.com.
Visit this
Greetings,
I have a executable binary and a shared object (implemented in rust) with a
C ABI.
I'm passing a capnp message from the binary through the C ABI.
This is what the schema looks like:
@0xc98fff04bdc3a38a;
struct Input {
gas @0 :Int32;
code @1 :List(Data);
data @2 :List(Data);
}
