> Off the top of my head, I remember that multiple people suggested that text should be allowed to contain NUL characters (not just at the end), which I agreed to. That's not terribly significant, though.
This seems contrary to what the docs[1] say:
> Text is always UTF-8 encoded and NUL-terminated.
Text is still NUL-terminated, it's simply allowed to contain NUL bytes in the middle as well. It's up to applications how they want to interpret this, but enforcing the NUL byte at the end is important for apps that want to pass a char* pointer around and don't want buffer overruns if they forget to validate the NUL terminator themselves. (It's a key design goal for the Cap'n Proto implementation to protect the app from security issues as much as possible.)
I see. I haven't gotten to the encoding page yet, but that sounds perfectly reasonable to me.
Small question before I get there, I imagine that such things are tagged with a length so that you can actually determine where the text field really ends then?
Yes. The actual getter for a Text field returns StringPtr, which is a simple pointer-length pair. If you want to pass that on to a C-style function you call .cStr(), with the caveat that the content is effectively truncated at the first NUL char.
This seems contrary to what the docs[1] say: > Text is always UTF-8 encoded and NUL-terminated.
Which is right?
[1] http://kentonv.github.io/capnproto/language.html