3 ms·
> 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
by simcop2387 13y ago
> 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.
Which is right?
[1] http://kentonv.github.io/capnproto/language.html http://kentonv.github.io/capnproto/language.html
- kentonv 13y agoText 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.) The encoding page describes this a bit better: http://kentonv.github.io/capnproto/encoding.html#blobs http://kentonv.github.io/capnproto/encoding.html#blobs
- simcop2387 13y agoI 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?
- kentonv 13y agoYes. 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.